Breaking Product Discovery into First Principles
Hey I’m Ant and welcome to my newsletter where you will find practical lessons on building Products, Businesses and being a better Leader
You might have missed these recent posts:
- OKRS ≠ Strategy
- Building Effecive Product Roadmaps
- Dual Track: Continuous Discovery & Delivery
My day job is helping companies shift to a Product Operating Model.
My evening job is helping product people master their craft with Product Pathways.
If you haven’t watched it already, I published a video earlier in the week that dives into product discovery, its core components, and a simple process to get you started.
I want to extend on the video in this weeks post.
Below, you’ll find:
What is product discovery?
The 3 Core Components of Product Discovery
What the definition of done is for discovery
Why product discovery should help you STOP ideas
And who does product discovery
Whilst I recap a few things in the post, I’d encourage you to watch the video, as it covers a lot that isn’t in this post.
Let’s get into it!
What is Product Discovery?
To put it simply product discovery is about derisking through learning.
When we start a new idea or opportunity, there are many unknowns and, therefore, high risk and uncertainty.
In product discovery, we apply research techniques to learn more before we start building anything.
This is the essence of product discovery:
We reduce risk by doing research so that we have confidence that we’re solving meaningful problems in the best way.
Product Discovery is about reducing risk by doing research before building. So we have confidence that we’re solving meaningful problems in the best way.
So what type of risk are we trying to reduce, and how?
3 Core Components of Product Discovery
1) Reducing risk by testing our assumptions
We reduce risk by making sure we're:
solving a meaningful problem (desirable)
it works and makes sense for our business (viable)
and we can technically do it (feasible)
This is also known as DVF (Desirability, Viability & Feasibility) and by now you likely have seen this venn diagram a million times.
3 big risks: Desirability, Viability and Feasibility
Broadly speaking, these are the 3 ‘headline’ risk categories.
Others, like SVPG, like to divide it into four categories: Valuable, Usable, Feasible, and Viable.
And some break out what I would call sub-categories, like usability, ethical, sustainable, etc.
All are fine. The point is that we’re looking at it from a business, customer, and technology perspective.
As mentioned before, product discovery is about de-risking through research.
So, we want to ensure that we’re learning as much as possible in these buckets through the discovery process.
And we want to do all this as cheaply as possible BEFORE committing to building anything.
“The most expensive way to learn if your product idea will be successful is to build it”
2) PROBLEM + SOLUTION SPACE
The next core component of product discovery is that we must do 1) across both the problem and solution space.
I personally like to visualize the problem and solution space as two wedges, not as a double diamond (I’ll get more into this in the next section).
Because they’re not mutually exclusive.
Problem vs Solution space
I don’t believe there’s a point in discovery where we can '‘check off’ the problem and move to the solution.
I also think it is highly inefficient to do so.
Remember that there are 3 big risks, and one of those is feasibility.
If you don’t de-risk feasibility until halfway through discovery you’ve potentially wasted a lot of time before finding out that something key wasn’t feasible.
Now, of course, this is still better than spending months building it and then finding out, but we can be smarter.
We should start to look at feasibility (all risks) as early as possible.
That is why I don’t subscribe to notions (which you might have encountered) that say things like start with Desirability, then Viability, and Feasibility last. Essentially, turning discovery into a three-phase waterfall process isn’t how it works.
So how does this work if it’s not a clean-cut problem and then solution?
The way to think about this mental model is that early on in discovery, you’re more focused on the problem space. This is different from being exhaustively focused on the problem. And later in the process you’re more focused on the solution.
But again, this isn’t exclusive.
To make this tangible, this looks like:
Customers interviews,
Market research,
Gathering data
Investigating possible solutions
Early proof of concepts
Early on and more, User testing, higher fidelity prototypes, AB testing, etc later.
Example activities and how they change as we move from majority problem to majority solution
It’s important to note that the quality of the solution is proportional to the outcome.
Delivering a bad solution to a problem won’t give you much, no matter how well you’ve nailed the problem.
Equally, a great solution that solves no problem won't either.
3) Diverging and Converging
Ok, so here is where the double diamond comes in, but it’s more nuanced than that.
The problem with the double diamond (or triple diamond… or the 8-diamond discovery process!?) is that it’s misleading.
It illustrates that discovery is just x sets of diverging and converging on the problem and another on the solution.
But product discovery is much more messy than that.
Rather, we go through a series of divergence and convergence.
At different levels, too - both macro and micro.
So it’s more like many overlapping diamonds.
But without getting too deep into this, what the double diamond does have right is the importance of diverging and converging.
Much research has shown how divergence and avoiding premature convergence aids creativity and innovation.
So what we want to make sure we’re doing is spending adequate time diverging and converging during discovery.
And avoid any moment where you may be prematurely converging.
Ask yourself if you’ve spent enough time exploring the problem and ideating different solution options.
Who does Product Discovery?
Product discovery is not done by a separate team.
The same team that is responsible for building the product should be the one responsible for discovery, too.
However, I see companies split this all the time.
The problem with splitting up discovery and delivery is that information and knowledge is lost between handoffs.
It also makes continuous discovery and continuous delivery hard to achieve.
More often than not, splitting discovery and delivery up means doing big discovery projects and big-bang solutions.
It’s hard to iterate quickly and learn when there are handoffs between teams
The final reason separating discovery and delivery isn’t ideal is that those building and maintaining the product are the ones who know it best.
They know what’s feasible vs not.
One of my most popular articles is on this topic and how this looks in practice: 🔗 ‘Product vs Design vs Tech’: A Partnership, not a Battlefield
Now, with that said, I recognize that there are constraints.
And I know some of you probably don’t have enough designers or other roles to embed them into every product team.
There may also be a capability gap, with only a handful of people in the company well-versed in product discovery.
I see these constraints all the time, particularly with my clients.
So, I empathize. I’m not dogmatic on this.
My position is that some discovery is better than no discovery.
So if that means having a ‘discovery team’ and doing this split that I just tried explained was a bad idea. If that’s the only way you can get discovery going in your org, then do it - it’s better than no discovery!
Product Trios
Now, the part about all this that people get caught up in is: how does that work if the team has to also deliver? Who is doing discovery in the team? Is it everyone?
Haivng a cross-functional team means that you have many different people in the team with various skills.
Usually, there are people in the team with skills that lend themselves more towards discovery than delivery.
For example, designers, especially UXR and product managers, typically lean more toward discovery, while engineering and UI design lean more toward delivery.
But at a minimum, we want at least one:
Product Manager
Designer
and Engineer
To be involved in discovery.
This construct is called the product trio.
Typically, the Product Manager, Design Lead, and Tech Lead make up the product trio. But if you don’t have lead roles it’s often the most senior designer or engineer who make up the trio.
The product trio is NOT a separate team.
They’re still part of the team and they contribute to delivery as well but their main focus is on discovery.
There’s also no reason why you can’t include other roles, like another designer, data scientists, BAs, additional engineers, and subject matter experts, too, but at a minimum, it’s these 3 roles.
The reason for that is that we need to remember that we have 3 big risks we need to discover in discovery: desirability, viability, and feasibility.
Each of these roles covers one of these risks:
Product = Viability
Design = Desirability
Engineering = Feasibility
The product trio ensure we have cover, desirability, viability and feasibility
Definition of Done for Discovery
I’m often asked, “How do I know I’ve done enough discovery?”
One of the things I covered in the video and have written about before is the value of timeboxing discovery.
A framing to help with time boxing from Jeff Patton: high risk/low certainty = high investment into discovery = longer timebox
Timeboxing helps us avoid discovery dragging on.
The intent is to have a checkpoint where we take a step back and ask ourselves whether we have enough confidence to proceed.
Remember that the output of discovery is confidence, and therefore, the end state of product discovery is making a decision.
A decision to proceed, pivot, or kill the idea.
This is why it’s really hard to come up with specific criteria for when discovery is done - it’s super contextual.
It depends on:
your risk appetite
how much confidence you’ve gained
your ability to deliver quickly and iteratively,
whether you feel it’s a ‘one-way’ door decision or a ‘two-way’ door one (in other words, can the decision be reversed? Can we pivot later?)
etc…
This is why I love creating assumption maps.
Assumptions Mapping: assumptions in the top right are your 'Riskiest Assumptions'
For those who aren’t faimiliar with assumptions mapping. It’s a technique by David J Bland from his book 'Testing Business Ideas'.
Essentially it’s a 2x2 matrix with importance is along the y-axis and the amount of evidence we have along the x-axis.
We then map our assumptions relative to each other along this matrix.
What the matrix helps us do is prioritize our assumptions.
Those in the top right are your riskiest assumptions.
By tackling these assumptions first and timeboxing, it means one of the following will happen:
We get through our riskest assumptions and learn enough to make a decision.
We get to the end of our timebox but since we worked on our riskest assumptions first we know enough to make a decision.
We get to the end of our timebox and still have some really big assumptions that we still need to test so we extend the timebox.
We get to the end of our timebox or have worked through our riskiest assumptions, but we’ve uncovered more assumptions that we need to test. New assumptions map and extend the timebox.
Continuous Product Discovery loop
So, as abstract as it may be, the definition of done for discovery is really, “Do I have enough confidence to make a decision?”
You might decide to:
do more discovery
or proceed with building the first iteration or version
or pivot
or ditch the idea altogether.
Which is why I like the framing of confidence.
Throughout the discovery process, we should be asking ourselves:
How much confident am I that this will be successful?
How confident am I that this problem is worth solving?
How confident am I that we’re best suited to solve this problem?
How confident am I with this solution?
That it’s feasible?
Viable?
and solves the problem in a usable and effective way?
Why Discovery should STOP most ideas
This brings me to perhaps the most overlooked aspect of product discovery.
Since product discovery is about gaining confidence in an idea - the opposite is also true. You may lose confidence (I share a real example of this happening to me in the youtube video).
There are many reasons for this.
you may find out that the idea is not worth pursuing
you may realize that the problem isn’t as big as you first thought
you may find out that your solution isn’t feasible
or perhaps you realize it’s not a viable opportunity
Therefore an underrated aspect of product discovery is avoiding bad ideas.
I say underrated because I tend to find most of the focus (and discussion) on discovery is about discovering high-quality solutions, not on avoiding the bad ideas.
To put this into perspective, considering that anywhere from 70-90% of ideas and startups fail, this would suggest that discovery should help us stop more ideas than we proceed with.
Or if we don’t stop them, they should have gone through a major pivot.
There’s a danger of seeking out data during discovery that confirms our beliefs, turning discovery into an expensive confirmation exercise.
There's a great mantra that I don't remember where I heard it, which was:
“come up with ideas like you're right but test them like you're wrong.”
I love this mindset because it’s not about finding evidence that supports your idea. It's about challenging it!
Product discovery is not a ‘silver bullet’
Of course, this doesn’t mean product discovery is a silver bullet.
Product discovery can’t guarantee success.
But what it can do is help you improve your chances of success.
That’s what discovery is all about.
It’s about reducing risk, avoiding bad ideas, and using data to shape your solution.
You still need to work incrementally and iteratively.
BONUS: More on discovery…
If this really long post on discovery wasn’t enough - here’s some more post and free templates to binge on!
Improve your craft through self-paced courses on:
Each course contains several hours of content, templates, and workshops to help you drive more impact.
"If you have to deal with competing priorities to put a lot of energy in pitching the work, this course is for you. Realistic examples and practical advice on how to tackle. I can now say I've begun to develop trust and credibility and land a strategic narrative that resonates with high-interest and high-influence stakeholders."
- Oliver (Stakeholder Management Essentials course)
Preview of the Stakeholder Management Essentials course on Product Pathways
Top Posts
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…