continuous-discovery
Continuous Discovery
I help product teams build the habits needed to continuously discover products that create customer value and business value. Discovery is not a phase — it is a sustained practice of weekly touchpoints with customers, conducted by the product trio, using small research activities, in pursuit of a desired outcome.
Essential Principles
Discovery Is Continuous, Not a Phase
Discovery doesn't happen before delivery — it happens alongside it, every week. Teams that treat discovery as a phase front-load research and then stop learning. Continuous teams sustain weekly customer contact throughout the life of the product.
Outcomes Over Outputs
Shipping features is not the goal. Creating value is. Start with the business outcome, map it to a product outcome you can influence, and let the outcome drive what you build. If you can't connect a feature to an outcome, you shouldn't build it.
The Product Trio Decides Together
Product managers, designers, and software engineers make discovery decisions as a trio — not sequentially, not in silos. The trio brings complementary perspectives: business viability, usability, and feasibility. If one voice is missing, you're making incomplete decisions.
Opportunities, Not Solutions
More from rohanpatriot/product-skills
shape-up
Applies Ryan Singer's Shape Up methodology to help product teams ship meaningful work on a fixed cycle. Use when shaping raw ideas into pitches, setting appetite, running a betting table, tracking progress with hill charts, scope hammering, or when user mentions pitches, cool-down, building period, appetite, breadboards, fat marker sketches, betting table, hill charts, scopes, or cycle planning.
6story-mapping
Applies Jeff Patton's User Story Mapping to help teams build shared understanding, decompose work, and plan releases. Use when creating story maps, mapping user activities, writing user stories, slicing releases, planning walking skeletons, decomposing backlogs, breaking down features, facilitating discovery sessions, identifying MVPs, or when user mentions backbone, user journey mapping, release slicing, or flat backlog problems.
6jobs-to-be-done
Applies Bob Moesta's demand-side thinking and Jobs-to-be-Done framework to help product teams understand why customers switch, hire, and fire products. Use when conducting switch interviews, drawing forces diagrams, writing job statements, mapping demand timelines, understanding the struggling moment, analyzing why customers hire or fire your product, exploring passive or active looking behavior, researching JTBD, or when user mentions Bob Moesta, demand-side thinking, big hire, little hire, push/pull/anxiety/habit, or the four forces of progress.
6