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 post:
- Why do we need Product Discovery?
- What is Continuous Product Discovery?
- What is Initial Product Discovery?
- JIRA Product Discovery
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.
„The first truth is that at least half of your ideas are just not going to work” – Marty Cagan, Inspired
According to Marty, 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 Product Delivery using 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 do not work. This is agile “learning by delivering.” Unfortunately, this approach results in a 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. You can read more about Initial Product Discovery below.
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 stopped using the term “Dual-track Agile” because the phrase made people focus far too much on the process. 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.
Continuous Discovery and Continuous Delivery
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 deliver 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
There is a common misconception. Some say that the Product 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
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. Google Analytics).
- Learning from data analytics (analyzing large datasets to uncover trends, patterns, and relationships, e.g., Amplitude).
- 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
3. What is Initial Product Discovery?
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
It helps you create a Now-Next-Later roadmap, which is a perfect choice for organizations who are transforming to the product model. For more advanced teams, Productboard still remains as the best pick.
At the same time, JIRA Product Discovery 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.
I haven’t played around the tool long enough to have a deeper opinion – you might expect this section to be updated once I become more proficient.