The Ultimate Guide to Product Discovery
Product Discovery is by far the most critical area for a Product Manager.
But, it is largely misunderstood. Teams waste time and energy delivering ideas that fail to drive the outcomes they expect.
Too often, teams spend months building features that fail to meet user needs or drive business impact. If you’ve ever launched something that barely got used, you already know why Product Discovery matters.
In this Product Discovery 101 guide, you’ll learn:
What Product Discovery is
Why Product Discovery is important
The difference between Continuous and Initial Product Discovery
How to apply Product Discovery: techniques, frameworks, and tools
Pros and cons of Jira Product Discovery
Where to find Product Discovery courses, templates, and resources
1. Why do We Need Product Discovery?
1.1 Managing risks
Let me tell you a secret: In product management, most ideas won’t work as expected. As Marty Cagan says in Inspired:
„The first truth is that at least half of your ideas are just not going to work”
Good teams assume at least three-quarters of their ideas won’t perform as they hope.
But why does it happen?
Product management is, at its heart, about managing risk. And for every product, 5 essential risks can materialize:
Value Risk: Will this idea truly create value for customers?
Usability Risk: Will users figure out how to use it?
Viability Risk: Can our business support it?
Feasibility Risk: Can we build it with our current technology?
Ethical Risk: Should we build it at all? Are there ethical considerations?
Addressing these questions before you code helps avoid the costly trap of building the wrong thing.
1.2 Learning by delivering
Many teams adopt Agile frameworks to deliver software iteratively and adapt quickly.
For example, in Scrum, we have a Sprint Review. During this workshop, we discuss the progress with the stakeholders and decide how to adapt:
But what will happen if we throw random ideas into the Product Backlog?
Some might work, but most won’t. This is “learning by delivering.” Unfortunately, this approach results in waste and rework.
Some might say it’s not a problem, as the Sprint is often 1-2 weeks long.
But this will happen every Sprint. Every Sprint, the product team selects ideas, implements them, and delivers a production-ready increment to discover those were not good ideas.
And the best ideas might not even be on the list.
So, we’d like to understand:
How can we come up with better ideas?
How can we test those ideas before the implementation?
And the answer is Product Discovery.
2. What is Continuous Product Discovery?
Continuous Product Discovery is a special type of Product Discovery for an existing product. It’s all about regularly exploring opportunities and identifying and testing your assumptions.
Instead of a single, upfront research phase, you keep the discovery going in parallel with delivery.
2.1 Continuous Discovery and Continuous Delivery
You might have heard about Dual-Track Development or Dual-Track Agile. It simply means having two streams running in parallel:
Continuous Discovery: Discover and validate what product to build.
Continuous Delivery: Implement and deliver the validated product to the market
What’s important here is that this is not a waterfall. Some team members talk to the customers, explore people’s problems, brainstorm solutions, identify assumptions, and perform experiments. At the same time, the team implements and delivers validated ideas to the market.
By testing ideas early, you dramatically reduce waste and rework. Product Discovery results in a validated Product Backlog. In particular, high-risk assumptions are tested upfront.
2.2 The Product Trio
There is a common misconception. Some say that the Product Manager decides what to build, and Engineers and designers should focus on how to build it.
Have you heard that before?
It hurts my ears because Product Discovery is not a task for a single person. I deeply believe that instead of building those silos and stage gates, we should embrace a collaborative approach.
In Continuous Discovery Habits, Teresa Torres introduced the concept of a Product Trio: Product Manager, Product Designer, and Engineer working together. This will help you build a shared understanding and stay open to different perspectives.
In particular, I have repeatedly found that the best ideas often come from my engineers. They know what’s technically possible.
Tip: Please remember that the Product Trio is not a rigid framework. It’s the default recommendation that can expand and contract. For example, you might include a Product Marketing Manager or exclude a Product Designer for an API product.
2.3 Inside Continuous Product Discovery
Think of Continuous Product Discovery as a series of iterative cycles, often visualized with the Double Diamond model:
Tip: Critically, Product Discovery is not a linear process. For example, you can loop back at any time if an experiment fails or you need more research.
Here, we explore the problem space to understand and define opportunities (problems, needs, desires) that, when solved, will drive the desired outcomes.
The two stages of divergent and convergent thinking:
Stage 1: Explore
Performing customer interviews (e.g., weekly)
Interviewing stakeholders
Learning from usage analytics (collecting and analyzing data on how users interact with a product or service, e.g., Pendo.io)
Exploring data analytics (analyzing large datasets to uncover trends, patterns, and relationships, e.g., Microsoft Power BI)
Leveraging other sources of insights in Product Discovery: surveys, market trends, SEO, and SEM reporting
Stage 2: Define
Mapping opportunities (e.g., Opportunity Solution Tree by Teresa Torres)
Prioritizing opportunities (e.g., Opportunity Score by Dan Olsen, ICE score)
The Right Diamond
Here, we explore the solution space to identify the right ideas to build.
The two stages of divergent and convergent thinking:
Stage 3: Ideate
Brainstorming solutions to identified opportunities
Formulating testable assumptions related to those ideas
Stage 4: Test
Perform experiments to prove or disprove identified assumptions
Continuous Product Discovery Example
In this example, we started with the desired outcome of increasing customer engagement for a video streaming platform by 20%. The team decided to map their steps with the Opportunity Solution Tree.
Stage 1, Stage 2: Explore and Define
After interviewing customers, analyzing product analytics, and talking to support and customer success, the Product Trio identified opportunities and child opportunities related to the desired outcome, e.g.:
I can’t find anything to watch,
I can’t figure out how to search for a specific show).
Next, they prioritized opportunities that are important for the users, where their satisfaction with their ability to achieve a specific outcome was low.
Stage 3: Ideate
After prioritizing opportunities, everyone on the Product Trio brainstormed individually. The team members met to discuss their ideas.
They immediately rejected a few ideas for one of the opportunities (“I can’t figure out how to search for a specific show”). The two most promising ideas left were:
Displaying a search box,
Displaying recommended shows.
Stage 4: Test
The team used User Story Mapping to identify assumptions related to value, usability, and feasibility. They identified some as risky and planned experiments to test those assumptions.
For example, they created a user prototype in Figma to test whether users understand how a search box works. They gave selected users a task to accomplish, tracked every user’s click, and assumed the assumption was correct if at least 70% of the users would complete their task on the first attempt.
The test was successful, so there was no need to consider alternative solutions or talk to the users again.
Previously, the Product Manager ensured with the stakeholders the the solution would also work for the business (she talked to CSM, Marketing, and Sales).
A few days later, the engineers selected this idea for implementation.
3. What is Initial Product Discovery?
Initial Product Discovery comes into play when creating a new product.
In this phase, you define your Product Vision, draft a Business Model, and identify the right market. You’re not worrying yet about continuous iteration.
You’re trying to figure out if there’s a market at all.
Initial Product Discovery follows a very similar workflow with different activities possible in each stage:
Again, there is no “Product Discovery Process,” but rather a series of iterative cycles.
4. Jira Product Discovery: Pros & Cons
If you work with Jira, you might have heard about Jira Product Discovery. It offers some handy features like a Now-Next-Later roadmap, which is a perfect choice for visualizing big-picture plans:
But JIRA Product Discovery misses the critical aspects of Continuous Product Discovery and encourages some bad practices:
No built-in way to map opportunities
No straightforward way to plan experiments
Some try to hack it, but I have a strong opinion: it’s not a Continuous Product Discovery tool. You will do much better creating the Opportunity Solution Tree in tools like Miro, Notion, or FigJam.
Recommended Books on Product Discovery
The two most important titles every product person should read:
Inspired by Marty Cagan
Continuous Discovery Habits by Teresa Torres
Final Thoughts
Product Discovery doesn’t have to be complicated. The key is to stay curious about your users, test ideas early, and collaborate with your team to build solutions people actually want.
About the Author
One Response
This is good information. Thanks for sharing!