Subscribe
Your product discovery is probably fluffy and unhelpful
Reach for the stars—at the very least, you’ll fall at the top of the world.
Published
18 December 2023
Are you doing discovery theater? Product Management Mentor and Founder of the Prod MBA Henry Latham is here to change that.
Too many product managers and designers complain their companies should take product discovery more seriously:
“We should be more product-led.” 
“If only we listened to our users more.” 
“Why don’t my stakeholders listen to our customer insights?!” 
They complain, complain, complain.
But rarely take responsibility for not just how they do product discovery but how they package that product discovery work in a way stakeholders value.
In this article, I will address why most product discovery is fluffy and unhelpful before outlining three specific principles you can follow to ensure your product discovery work delivers results.
What is fluffy product discovery?
To understand some of the mistakes around product discovery, let’s start by defining the term correctly.
“Product discovery” refers to the process used in business and marketing to identify and understand the potential products or services that can be offered to meet market demands or solve customer problems — a ChatGPT definition. 
When I refer to “fluffy” product discovery, I mean there are no clear, actionable insights within that discovery work to act upon. It’s all mixed up together. Hard to separate different threads, obfuscating the key, unique insights.
Because the key insights are hard to identify and act upon, that product discovery work is simply unhelpful. It doesn’t help you make better product decisions as a product team or product org.
Whether your product team does that discovery work or you work with an independent UX Research team uncovering those insights, the root cause of why product discovery work gets fluffy is usually the same. 
A misunderstanding (or wilful ignorance) of what product discovery really entails.
Specifically, not just “to identify and understand” within your product team—but to help the rest of the organization and, specifically, key decision-makers identify and understand the insights that will drive the products and services you offer. 
Because it is all a waste of time—it’s product discovery theater—if you cannot translate unique insight into making better product decisions across the organization. 
That means you must take responsibility not just for the identification of insights but how those insights are packaged and communicated to your stakeholders.
How to Make Product Discovery Un-Fluffy 
Taking responsibility for your product discovery work delivering value means making it as actionable as possible for your stakeholders. 
Specifically, there are three key principles to follow to make that happen:
  1. Understand your internal target audience
  2. Quantify qualitative data
  3. Business value > user value 
Let’s dive into each one (or should I say, Dovetail in).
Principle #1: Understand your internal target audience
Every product should have a clear target audience. Everything from your website copy down to our feature decisions should be with our specific target market in mind.
The same is true for product discovery work.
You should have a clear target audience in mind and a clear outcome you want to achieve when communicating with that audience.
With product discovery, that usually means you want to influence that audience to listen to the insights you have uncovered—and make product decisions based on those insights. 
Nothing new there, right?
However, the big mistake discovery teams make?
Not really understanding their target audience. 
When presenting discovery work, you will usually pitch to senior business leaders. In a small startup, that might be the CEO. In a large org, maybe a senior product leader, someone from sales, another from finance, etcetera.
That audience probably doesn’t want to hold an hour-long chit-chat about the interesting psychology of your target market. Or the intricate details of the usability challenges you’ve uncovered.
Instead, they want clear, concise, actionable insights to help them make better decisions.
Rather than a long, generic presentation you present to all your stakeholders, you should customize that presentation to what the audience needs to know and what helps you achieve the outcome you defined for that audience.
Example: If presenting to your CFO, focus on insights that will impact the company’s finances. If presenting to your CPO, focus on insights that might affect other product teams and highlight new product opportunities those teams are not addressing.
This requires work.
Summarize your work, customize it, and enrich it with quantitative data sprinkled with a few concrete, memorable qualitative stories to help you make your point—rather than lazily sharing every detail of every user interview.
Principle #2: Quantify qualitative data
Another big mistake teams make when sharing insights with stakeholders is not quantifying their qualitative user interactions.
Some teams share entire user interview transcripts with their stakeholders, expecting them to read through pages of notes! 
Others expect their stakeholders to sit through a 30-minute recording of each user interview!
What happens?
Stakeholders simply ignore this info—or switch off if you share it in a live presentation.
And rightly so! 
Who’s got time for that?!
Instead, take responsibility for “quantifying your qualitative data.”
Take the example of sharing user interview insights.
With the Product Managers I coach, I suggest using the following template for this (rather than sharing pages of interview transcripts):
How to find themes in your data.
Download the full template here.
Here are the key elements of this template: 
  1. Use the same questions for every interview: This means you will have notes from every interview for each question. This, in turn, means you can visually identify trends across the interviews (for example, common challenges preventing these users from solving their problems. This means we can start quantifying those challenges). Don’t read the questions off a script like a robot. Just make sure you thread them into the interview in some form at some point
  2. For each interview, only add three to four important notes per question: It’s unrealistic to review pages of notes after each interview. Better to focus on key points you can quickly identify and aggregate into themes after a batch of interviews. Color-code the notes for each person (e.g., John = dark blue).
  3. Once you’ve conducted the interviews:
    1. For each question, identify the common themes that came up and aggregate these by dragging related notes over to the board on the right-hand side (for example, if three people complained about “struggling to find motivation” in some form, group these notes together)
    2. Count how often each frustration came up (for example, say we interview fitness enthusiasts about their health. We could write “struggling to find motivation” came up in seven out of ten interviews)
    3. Rate the perceived acuteness of the frustration from one to five (for example, “Four out of five because we believe this is something they worry about every day and prevents them achieving their fitness goals”)
This gives you a clear, visual overview of your user interviews with minimal work. More importantly, it also means you can quantify those qualitative data (quotes, notes, summarized points that came up) in clear, easy-to-share themes. '
For example: “The problem of ‘struggling to find motivation’ came up in seven of the ten interviews. This acute (rated four out of five) problem represents a big opportunity for our business…”
Nowadays, you don’t need to do all of this manually. 
If you have access to Dovetail to transcribe, analyze, and uncover themes from your user interviews, then great. This will save you a lot of time. 
The tool doesn’t matter. 
The outcome does: moving from sharing masses of notes to clear, quantified insights to share with your stakeholders.
Principle #3: Business Value > User Value
In product, we love talking about the user. 
“Let’s be ‘user-centric’! We need to ‘build for the user’!”
But this is only part of our job.
The role of any product person is to, yes, deliver value for the user. By doing so, we hope to build something they actually get value from—hopefully, something they love—and, therefore, stick around to use it.
But we also need to capture some of that value for the business in the form of revenue and, ideally, get enough revenue to be profitable.
Unfortunately, product people tend to forget the second part. 
So when they share product discovery insights with stakeholders, they just share the raw insights, thinking only of why they are important to the user.
For example: “We’ve discovered that seven out of ten fitness enthusiasts struggle to motivate themselves, even when they hire a personal trainer”.
Great. 
Why should I care as a stakeholder?
Instead, try to reframe that insight in business terms.
For example“We’ve discovered that seven out of ten fitness enthusiasts struggle to motivate themselves, even when they hire a personal trainer. Consider they spend ~$100 per session, which means ~$400 per month per target customer. We’ve uncovered that most are actively looking for an alternative, so we can capture at least $400/month per user if we position ourselves as a better alternative. Even more, if we are really able to solve that user need more effectively than the existing solution.”
Here’s an example prompt you can put into ChatGPT to get these figures: 
“How much is our target customer of [insert target market] spending per month on solving [insert problem]? List specific solutions they currently use and the amount spent (in dollars) per solution.” 
Or see if you can pull exact figures from your user interviews!
You don’t need an MBA to add concrete monetary figures to these insights. The more you can understand and provide logical figures for important business terms like expected revenue per user, lifetime value, cash flow, etc., the better.
But to start, add a ballpark figure to show you understand that product is not just about the user but also about the business.
This will build trust, meaning your stakeholders are more likely to translate your insights into action.
Conclusion
Complaining that nobody takes your insights seriously or that “we should be more customer-centric” won’t help you, your career, or your organization.
Fluffy product discovery is why product discovery has a bad name in many organizations.
Because it’s vague. It’s unhelpful. It’s not leading to better business results.
Instead, make product discovery as actionable as possible by:
  1. Understanding your internal target audience
  2. Quantifying qualitative data
  3. Understanding business value > user value 
You’ll quickly see stakeholders respect you more, trust you more, and ultimately, make more decisions based on your insights. 

Hungry eyes?

Subscribe and get inspiring content delivered straight into your inbox