The hardest part about product discovery isn't talking to customers.
It's admitting you don't know what to build.
Everyone expects you to be the customer expert with perfect intuition about user needs.
This creates an impossible tension. Here's how to resolve it: 🍺
It's admitting you don't know what to build.
Everyone expects you to be the customer expert with perfect intuition about user needs.
This creates an impossible tension. Here's how to resolve it: 🍺
1/ Here's the paradox that breaks most PMs:
Your job title suggests you should know what customers want.
Your stakeholders expect you to have the answers.
Your roadmap implies you've figured it out.
But the entire purpose of discovery is admitting you haven't figured it out yet.
Your job title suggests you should know what customers want.
Your stakeholders expect you to have the answers.
Your roadmap implies you've figured it out.
But the entire purpose of discovery is admitting you haven't figured it out yet.
2/ This cultural expectation creates fake discovery.
You talk to customers, but you ask leading questions that confirm your existing ideas.
You cherry-pick feedback that supports your roadmap.
You treat user research as validation, not investigation.
You're going through the motions without actually learning.
You talk to customers, but you ask leading questions that confirm your existing ideas.
You cherry-pick feedback that supports your roadmap.
You treat user research as validation, not investigation.
You're going through the motions without actually learning.
3/ Real discovery starts with a different mindset.
Instead of "I need to validate this feature idea," think "I need to understand this problem space."
Instead of "Do customers want X?" ask "What are customers actually trying to accomplish?"
The shift from solution-focused to problem-focused changes everything.
Instead of "I need to validate this feature idea," think "I need to understand this problem space."
Instead of "Do customers want X?" ask "What are customers actually trying to accomplish?"
The shift from solution-focused to problem-focused changes everything.
4/ Why is this so hard? Because discovery feels slow when everything feels urgent.
Stakeholders want features delivered.
Customers want problems solved.
Engineering wants clear requirements.
Leadership wants predictable timelines.
Nobody says "Please spend more time figuring out what to build."
Stakeholders want features delivered.
Customers want problems solved.
Engineering wants clear requirements.
Leadership wants predictable timelines.
Nobody says "Please spend more time figuring out what to build."
5/ But here's what I've learned after years of rushing into building the wrong things:
Discovery isn't about slowing down development.
It's about speeding up learning.
The goal isn't perfect certainty.
It's rapid reduction of uncertainty about the things that matter most.
Discovery isn't about slowing down development.
It's about speeding up learning.
The goal isn't perfect certainty.
It's rapid reduction of uncertainty about the things that matter most.
6/ Framework #1: The Assumption Mapping Exercise
Before any customer conversation, list your assumptions:
Who has this problem?
When do they experience it?
How do they solve it today?
What would make a solution valuable to them?
What would make them switch from their current approach?
Before any customer conversation, list your assumptions:
Who has this problem?
When do they experience it?
How do they solve it today?
What would make a solution valuable to them?
What would make them switch from their current approach?
7/ Now rank these assumptions by:
- How critical they are to your solution working
- How uncertain you are about them
Focus your discovery on high-criticality, high-uncertainty assumptions first.
This gives you a systematic way to prioritize what to learn about.
- How critical they are to your solution working
- How uncertain you are about them
Focus your discovery on high-criticality, high-uncertainty assumptions first.
This gives you a systematic way to prioritize what to learn about.
8/ Framework #2: The Problem Interview Structure
Stop asking "Would you use a feature that does X?"
Start with open exploration:
"Tell me about the last time you experienced [problem space]"
"Walk me through how you currently handle [situation]"
"What's most frustrating about your current approach?"
Stop asking "Would you use a feature that does X?"
Start with open exploration:
"Tell me about the last time you experienced [problem space]"
"Walk me through how you currently handle [situation]"
"What's most frustrating about your current approach?"
9/ Listen for:
- Frequency (how often does this happen?)
- Intensity (how painful is the current experience?)
- Alternatives (what else have they tried?)
- Context (when does this matter most?)
You're mapping the problem landscape, not testing solutions.
- Frequency (how often does this happen?)
- Intensity (how painful is the current experience?)
- Alternatives (what else have they tried?)
- Context (when does this matter most?)
You're mapping the problem landscape, not testing solutions.
10/ Framework #3: The Learning Sprint
Discovery doesn't have to take months.
Week 1: Assumption mapping & interview planning
Week 2: 8-10 customer conversations
Week 3: Synthesis & hypothesis refinement
Week 4: Quick prototype testing with 5 customers
If you hustle, "weeks" could easily be "days".
Discovery doesn't have to take months.
Week 1: Assumption mapping & interview planning
Week 2: 8-10 customer conversations
Week 3: Synthesis & hypothesis refinement
Week 4: Quick prototype testing with 5 customers
If you hustle, "weeks" could easily be "days".
11/ Common objection: "We don't have time for discovery"
Translation: "We don't have time to learn before we build"
But you'll spend time either way - either learning upfront or fixing mistakes later.
Discovery de-risks development time, it doesn't compete with it.
Translation: "We don't have time to learn before we build"
But you'll spend time either way - either learning upfront or fixing mistakes later.
Discovery de-risks development time, it doesn't compete with it.
12/ Common objection: "Customers don't know what they want"
True! That's why you don't ask them what to build.
You ask them about their current experience:
- What they're trying to accomplish
- Where they get stuck
- What workarounds they've created
- What outcomes matter to them
True! That's why you don't ask them what to build.
You ask them about their current experience:
- What they're trying to accomplish
- Where they get stuck
- What workarounds they've created
- What outcomes matter to them
13/ Common objection: "Our customers tell us everything is a priority"
This usually means you're asking about solutions instead of problems.
When you understand the underlying jobs customers are trying to do, priorities become clearer based on frequency, intensity, and business impact.
This usually means you're asking about solutions instead of problems.
When you understand the underlying jobs customers are trying to do, priorities become clearer based on frequency, intensity, and business impact.
14/ Framework #4: The Discovery Synthesis Method
After customer conversations, don't just collect quotes.
Map patterns:
- What problems appear across multiple customers?
- What solutions do customers consistently praise or criticize?
- What contexts make problems more or less painful?
- What outcomes do customers measure success by?
After customer conversations, don't just collect quotes.
Map patterns:
- What problems appear across multiple customers?
- What solutions do customers consistently praise or criticize?
- What contexts make problems more or less painful?
- What outcomes do customers measure success by?
15/ Look for the unexpected insights:
- Problems you didn't know existed
- Solutions customers built themselves
- Workarounds that reveal real needs
- Contexts where your assumptions break down
These insights are often more valuable than confirmation of what you expected.
- Problems you didn't know existed
- Solutions customers built themselves
- Workarounds that reveal real needs
- Contexts where your assumptions break down
These insights are often more valuable than confirmation of what you expected.
16/ The goal of discovery isn't consensus.
It's clarity about what bet you're making and why.
You'll never have perfect information.
But you can have systematic confidence that you're solving a real problem for real people in a way that creates real value.
It's clarity about what bet you're making and why.
You'll never have perfect information.
But you can have systematic confidence that you're solving a real problem for real people in a way that creates real value.
17/ I use structured approaches for discovery conversations constantly.
Some of the most effective frameworks I've found are in AI Prompts for Product Work - specifically the ones that help structure problem interviews and assumption mapping sessions.
Having a systematic approach removes the guesswork.
Some of the most effective frameworks I've found are in AI Prompts for Product Work - specifically the ones that help structure problem interviews and assumption mapping sessions.
Having a systematic approach removes the guesswork.
18/ Discovery gets easier when you treat it as a skill to develop rather than intuition you're supposed to have.
I've collected systematic discovery frameworks in because I got tired of reinventing approaches every time I faced a new product challenge.prodmgmt.world/products/produ…
I've collected systematic discovery frameworks in because I got tired of reinventing approaches every time I faced a new product challenge.prodmgmt.world/products/produ…
19/ Here's your homework:
Pick one feature on your roadmap.
Write down your top 5 assumptions about the problem it solves.
Rank them by criticality and uncertainty.
Design 3 questions to test your highest-risk assumption.
Find one customer to test it with this week.
Pick one feature on your roadmap.
Write down your top 5 assumptions about the problem it solves.
Rank them by criticality and uncertainty.
Design 3 questions to test your highest-risk assumption.
Find one customer to test it with this week.
20/ The difference between good and great product managers isn't intuition about customers.
It's systematic approaches to learning when you don't have the answers yet.
Discovery is a skill.
Uncertainty is data.
Questions are more valuable than assumptions.
It's systematic approaches to learning when you don't have the answers yet.
Discovery is a skill.
Uncertainty is data.
Questions are more valuable than assumptions.
What's your biggest discovery challenge right now?
Is it getting time to do it properly, structuring conversations effectively, or synthesizing insights into actionable decisions?
Let me know below - I'm curious what holds most PMs back from doing discovery well 👇
Is it getting time to do it properly, structuring conversations effectively, or synthesizing insights into actionable decisions?
Let me know below - I'm curious what holds most PMs back from doing discovery well 👇
• • •
Missing some Tweet in this thread? You can try to
force a refresh
