Product Discovery is by far the most critical area for a Product Manager.
But, it is still largely misunderstood. Teams waste time and energy delivering ideas that do not work and do not drive the expected outcomes.
In this issue:
Why do we need Product Discovery?
What is Continuous Product Discovery?
What is Initial Product Discovery
JIRA Product Discovery
Continuous Product Discovery Course
1. Why do we need Product Discovery?
1.1 Managing risks
Let me tell you a secret. In product, the simple truth is that most of your ideas are not going to work.
According to Marty Cagan,
„The first truth is that at least half of your ideas are just not going to work” - Inspired
According to Inspired, good teams assume at least three-quarters of their ideas won’t perform as they hope.
Why does it happen?
I’d argue that Product Management is, at its heart, about managing risk. And for every product, there are 5 risks that can materialize:
Value. Will it create value for the customers?
Usability. Will users figure out how to use it?
Viability. Can our business support it?
Feasibility. Can it be done (technology)?
Ethics. Should we do it? Are there any ethical considerations?
In most cases, one of those risks materializes.
1.2 Learning by delivering
Now, let’s look at the diagram below. You might recognize it. It’s the Scrum Framework.
Agile did a fantastic job when it came to delivering software in small iterations, inspecting, and adapting. And asking the question, “Are we building the right thing”? It allows you to deliver value faster and adjust the direction.
So, for example, in Scrum, we have a Sprint Review. This should be a workshop. This is not a presentation. During the Sprint Review, together with the stakeholders, we discuss the progress, we decide on how to adjust, and we can adapt to the changes in the business environment.
But what will happen if we throw random ideas into the Product Backlog?
Some ideas may have potential, but others won't be good ideas because most don't work. This is agile "learning by delivering." Unfortunately, this approach results in waste and rework.
And some might say it’s not a problem, as the Sprint is 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.
Think about it. In every Sprint, you select some ideas, implement them, and figure out that those are not good. And the best ideas might not even be on the list!
So, we would like to understand:
How can we come up with better ideas?
How can we validate those ideas before the implementation?
And the answer is Product Discovery.
2. What is Continuous Product Discovery?
In this point, I focus on Continuous Product Discovery, which is Product Discovery for an existing product.
2.1 Continuous Discovery and Continuous Delivery
Jeff Patton and others in the Agile/product space have been big proponents of an approach called Dual-Track Development or Dual-Track Agile.
Starting with the publication of INSPIRED V2, Marty Cagan stopped using the term “Dual-track Agile.” Instead, he proposed to call it “Continuous Discovery and Continuous Delivery.”
In this setup, there are two streams that run in parallel:
The goal of Product Discovery is to discover the product to build.
The goal of Product Delivery is to deliver that product to the market.
What's important here is that this is not a waterfall. So, some team members talk to the customers, explore people's problems, ideate how to solve them, and plan and perform experiments. At the same time, the team implements some of the ideas and delivers those ideas to the market.
This significantly limits waste and rework.
Product Discovery results in a validated Product Backlog. In particular, high-risk assumptions are tested before the implementation.
2.2 The Product Trio
![The Product Trio, as defined in Continuous Discovery Habits by Teresa Torres The Product Trio, as defined in Continuous Discovery Habits by Teresa Torres](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd3ea5229-8775-4900-a471-011fd71924ea_1046x500.png)
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.
So make sure that a Product Designer and at least one Engineer are included. This will help you build a shared understanding and stay open to different perspectives.
And if we believe that customers don't know how to solve their problems, why should a Product Manager know it? Product Managers may be tech-literate, but they are not tech experts.
In particular, I have repeatedly found that the best ideas often come from my engineers. They know what is possible and how to leverage technology.
2.3 What’s inside Continuous Product Discovery?
What’s inside Continuous Product Discovery?
![Continuous Product Discovery and the Double Diamond Continuous Product Discovery and the Double Diamond](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff9db3e59-0e5c-49c7-881b-2802312b34a9_1126x673.png)
There are two groups of activities:
Exploring the Problem Space to understand and define opportunities (problems, needs, desires):
Performing customer interviews (e.g., weekly, as defined by Teresa Torres).
Learning from usage analytics (collecting and analyzing data on how users interact with a product or service, e.g., Pendo.io).
Learning from data analytics (analyzing large datasets to uncover trends, patterns, and relationships, e.g., Microsoft Power BI).
Leveraging other tools: customer surveys, market trends, and benchmarking.
Mapping opportunities (e.g., Opportunity Solution Tree, as defined by Teresa Torres).
Exploring the Solution Space:
Explore possible solutions to those problems (ideas).
Formulate testable assumptions related to those ideas.
Run experiments to prove or disprove those assumptions.
![Opportunity Solution Tree, as defined in Continuous Discovery Habits by Teresa Torres Opportunity Solution Tree, as defined in Continuous Discovery Habits by Teresa Torres](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7a924cac-e0f0-40e4-8eb7-c3b331b9282a_1326x561.png)
3. What is Initial Product Discovery?
![Initial Product Discovery and the Double Diamond Initial Product Discovery and the Double Diamond](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F6d2d729c-dfd8-4e41-ba89-6d5614d1d878_1108x677.png)
The Initial Product Discovery runs without Product Delivery. Its goal is to discover the product that can achieve Product-Market Fit.
The Initial Product Discovery may result in a Product Vision, Product Strategy, and initially validated Business Model that can serve as a base for investment decisions.
4. JIRA Product Discovery
JIRA Product Discovery is like a Frankenstein:
It helps you create a Now-Next-Later roadmap, which is a perfect choice.
But at the same time, JIRA Product Discovery misses the critical aspects of Continuous Product Discovery and encourages some bad practices:
It doesn't allow you to map Opportunities.
It doesn’t allow you to plan Experiments.
It uses the ICE scoring, which is more suitable for growth product teams. It’s unclear whether the Impact results from the number of customers, Importance, and Satisfaction.
In short, it’s not a Continuous Product Discovery tool. I do not recommend performing Continuous Product Discovery in Jira.
5. Continuous Product Discovery Certification Course
All premium subscribers can take the Continuous Product Discovery Certification Course, 2nd edition, for free.
It will allow you to:
Easily discover and validate the best product ideas.
Learn how to prioritize opportunities to maximize the outcomes.
Know best practices and how to avoid common mistakes.
Easily identify hidden assumptions and plan experiments.
Demonstrate your skills with digital, verifiable credentials.
You will:
Combine top product discovery techniques: Opportunity Solution Tree, Opportunity Score, and Strategyzer cards (©Paweł Huryn).
Access dedicated tools and templates to easily implement Continuous Product Discovery in your organization.
Get a digital, verifiable credential (example) you can easily demonstrate after passing the exam.
Read more: Continuous Product Discovery Certification Course
Recommended posts
Assumption Prioritization Canvas: How to Identify And Test The Right Assumptions
Testing Business Ideas: The Ultimate Validation Experiments Library
Recommended books
Inspired by Marty Cagan
Continuous Discovery Habits by Teresa Torres
BONUS: Product Discovery Cheat Sheet (PDF)
Experiment: Product Discovery Cheat Sheet Video
Thanks for reading The Product Compass!
Consider subscribing or upgrading your account, if you haven’t already, for the full experience:
My full archive and all PM resources
Continuous Product Discovery Certification Course (worth $149)
Closed Slack community + get my help anytime (1:1)
Clone my Notion collection to your Notion account
30-days money-back guarantee
Let’s learn and grow together 🚀
Take care, Paweł
@Pawel
Thanks for the article! FYI, there is a small typo towards the end, "Product-Makret Fit"
What would be the difference between an "opportunity" and a "problem?" Going off of Torres's definition of an opportunity as a customer need, pain point or desire, I'm having trouble seeing what would be added to the opportunity during the discover phase that would result in something different. In my mind, it feels like the "problem" would just be a re-wording of the "opportunity."