Product Discovery Unbundled Part 1: What is Product Discovery, and why should you care
A structured guide to understanding the fundamentals and importance of Product Discovery
Spending the last years driving and scaling Product Innovation, at big tech companies, company builders, or scale-ups, I’ve found myself quite often explaining the fundamentals and importance of Product Discovery.
I’ve reflected and summarized some of my personal learnings, slides, best practices, tools, and frameworks in a 3 part series “Product Discovery Unbundled”:
- Part 1: What is Product Discovery, and why should you care
- Part 2: The approach and mindset of Product Discovery
- Part 3: Leveraging opportunity solution trees, to drive product discovery at scale
This is the first part, which covers the basics of what Product Discovery really means, and why you should care.
So tell me, what does Product Discovery mean in a simplified manner?
I spend quite some time on exactly that. And if you are a Product Manager who gets started and trying to look up the definition of Product Discovery, you will likely get flooded with interpretations and definitions…
In a simplified manner, it’s an approach to develop a deep understanding of our customers, and to use this understanding, to ensure we have the right solution, for the right problem.
Coming up with the right solution for the right problem — isn’t that common sense for everyone?
I would argue we would all wish for that, but truth is, this stage is unfortunately quite often neglected, rushed, or misunderstood in the product development process. Which leads to poorly articulated opportunities, and solutions that fail to address a real user need.
Lots of teams are spending a bit of time on product strategy, but then rush too swiftly straight into product delivery.
Intercom has published a highly interesting article on how 100 units of work are spent across a typical product development process in a startup:
As we clearly see from the above, a typical startup spends roughly 10% of its capacity on ensuring they understand the problem space properly (prioritizing gathering insight about the problem and defining it clearly).
Some startups even completely skip this part and jumped straight into building a solution -> more on that in part 2.
Intercom on the other hand, deliberately dedicates 40% of its 100 units to the problem space, before they have started designing anything. They become truly obsessed about problem prioritization and problem definition:
“We do it, because a solution can only be as good as your understanding of the problem you’re addressing. This is non-controversial. Like an irrefutable fact. And yet most software teams fly right through the problem definition part Link to their article. “
Great companies know, that they have to care about Product Discovery to create sustainable value for both, their users and their business.
Why should we care?
According to CB Insights, the #1 reason why startups fail is that they are tackling the wrong problem.
Product Discovery can significantly reduce the risk that we are becoming part of this list.
Let’s take a look at an example, and for that bear our definition of Product Discovery in mind
- Addressing the right problem
- With the right solution
Some of you might still remember the Silicon Valley Juicero Product?
Guardian summarizes it as a WiFi-enabled juicing system, app and chopped-fruit-and-vegetable delivery service, if you are too busy to cut carrots.
After a bit, Juicero users figured out that they can simply squeeze those bags with their hands, without the need for an expensive high-end device. Link to bloomberg tech review
Remember our definition of product discovery in terms of “the right solution, for the right problem”?
Truth is, Product Discovery can’t give you 100% certainty that you are addressing the right problem with the right solution. However, it can
“fundamentally de-risk your most critical assumptions, and provide you with early signals if you are on the right path or not”
Let’s assume you start to work on this net new product idea of your organization and after 6 weeks you come back to your manager and need to tell them that it was not successful — BRAVO!
This does not mean you have failed in Product Discovery. You have just saved your organization time, money and resources! And thanks to you, they can dedicate those resources to explore other opportunities which might resonate better with your users and market.
In some ways, the learning that comes from the unexpected failure is maybe more valuable than the success might have been. Tim Brown , Chair of IDEO
De-risk our most critical assumptions
Truth is, no one of us is Saruman, and in possession of a Palantir which predicts the future, hence we need to put on our hats as scientists, and systematically de-risk our most critical assumptions.
Starting to validate our assumptions at a very late stage when releasing a product, goes hand in hand with tremendous costs if we fail….
We spent months, resources, time, $ costs etc. building sth, just to figure out
- It does not work as intended
- Users simply don’t care
- It does not return the expected value to the business
- The list goes on….
On the other hand, continuously validating if we are on the right path/ track, fundamentally increases the likelihood that we are shipping something of value for our users and the business.
How to approach Product Discovery — there is no silver bullet
How Marty Cagan puts it nicely in “Inspired”:
“People are always searching for a silver bullet to create products, and there is always a willing industry — ready and waiting to serve with books, coaching, training, and consulting. But there is no silver bullet, and inevitably people figure this out.” — Marty Cagan
A very simple, but fundamental concept which stayed with me since I’ve read “change by design” years ago , is the concept of “constraints” when building a product.
In a highly simplified manner, we need to get 3 things right
- Desirability: Does the solution makes sense to our users? Do they care?
- Feasibility: Can we build it? Is this “technically/ functionally” possible?
- Viability: Is the solution commercially viable?
Product Discovery starts with the user — period!
Why are we not starting with a business case (viability) or technical solution architecture (feasibility)? Isn’t that equally important?
Of course, those 2 aspects matter. Truth is though, that “no early business case has survived the first contact with real customers”. And your solution likely will change and evolve significantly over time.
Also, spending time to finetune a highly complex business case/ model in the early stages of a product is frankly quite useless if you figure out later that no customer cares about your solution in the first place.
We need to start with the user (desirability) — understood.
Are there any tactics/ frameworks I can recommend?
I would stress that there is definitely no “silver bullet”, and I would question the people who claim to have one.
What really worked well for me personally, is to use the double diamond outline conceptually, which we know from product design and design thinking, and leverage a couple of frameworks and tools along this structure.
In the next part, I will break this process down into details, and share some of my personal best practices, learnings, and frameworks from running product discovery in established organizations, startups, as well as scale-ups.
Part 2: How to approach Product Discovery (step-by-step guide)
Key takeaways
- There are too many definitions flying around about what Product Discovery truly means. For me, it’s an approach to develop a deep understanding of our customers, and to use this understanding, to ensure we have the right solution, for the right problem.
- If you are not Saruman and don’t own a Palantir to predict the future, you can’t afford to skip product discovery
- There is no silver bullet and we need to understand that no course, book, process, article, podcast, coach etc. can change that. Each product and organization comes with its own unique constraints, challenges, customer profiles etc. Make sure you understand the fundamentals, and use this as your guiding Northstar
- If you need to start somewhere, start with the user (Desirability)
- Finding out that something does not work — does not mean you have failed in Product Discovery. You have put on our hats as a scientist, and systematically de-risked the most critical assumptions about a new product idea for your organization — bravo! You saved them time and money, building sth which no one needs
References and additional readings
- Book change by design
- Marty Cagan — Inspired
- A recommended read to better understand the basics of the “double diamond” design process is the article by Dan Nessler— Link
- Problem & Solution space understood by Nikhil Gupta https://medium.com/@nikhilgupta08/problem-space-vs-solution-space-f970d4ace5c
- Discovery vs Design https://www.svpg.com/discovery-vs-design/
- Board of Innovation (experimentation)
- Dan Olsen https://www.slideshare.net/dan_o/mastering-the-problem-space-to-achieve-productmarket-fit-by-dan-olsen-at-mind-the-product-sf?from_action=save
- 6 Guiding principles for effective product discovery https://www.producttalk.org/2018/08/effective-product-discovery/
- IntercomGreat PMs don’t spend time on solutions https://www.intercom.com/blog/great-product-managers-dont-spend-time-on-solutions
- CB Insights— why startups fail — https://s3-us-west-2.amazonaws.com/cbi-content/research-reports/The-20-Reasons-Startups-Fail.pdf
