One of the hardest lessons I learned as a Product Manager came from a feature that everyone believed would be successful.
The customer requests were there.
Stakeholders were excited.
The team was confident.
When we started product discovery, I wasn’t really trying to understand the problem. If I’m honest, I was trying to prove that our solution was the right one.
Looking back, I wasn’t doing discovery.
I was doing validation.
There’s an important difference.
Discovery is about learning. Validation is about proving.
The moment I understood that distinction, the quality of my product decisions changed dramatically.
We Naturally Look for Evidence That Supports Our Ideas
Every product manager gets excited about certain ideas.
It’s human nature.
The danger is that once we become attached to a solution, we unconsciously begin collecting evidence that confirms it.
We ask leading questions.
We highlight positive feedback.
We ignore conflicting signals.
Psychologists call this confirmation bias.
In product management, it quietly leads teams toward expensive mistakes.
Discovery should challenge our assumptions, not protect them.
Customers Are Not There to Approve Your Roadmap
Early in my career, I would meet customers hoping to hear one sentence:
“Yes, that’s exactly what we need.”
Now I approach those conversations differently.
Instead of presenting solutions, I spend most of the discussion exploring problems.
Questions like:
- Tell me about the last time this happened.
- What made that difficult?
- How are you solving it today?
- What frustrates you most about the current process?
I’ve found that customers often reveal problems I wasn’t even looking for.
Those discoveries are far more valuable than hearing someone agree with my original idea.
Discovery Begins With Curiosity
The best product managers I’ve worked with share one habit.
They genuinely enjoy being proven wrong.
Not because failure is enjoyable, but because every incorrect assumption removes uncertainty.
Imagine discovering before development that your biggest feature idea isn’t actually important to customers.
That might feel disappointing.
But imagine discovering the same thing six months after launch.
One outcome costs a conversation.
The other costs months of engineering effort.
Learning early is always cheaper.
Separate Problems From Solutions
One habit I’ve developed is deliberately separating customer problems from proposed solutions.
Customers often request features.
Stakeholders often suggest enhancements.
Instead of immediately discussing implementation, I ask:
“What problem is this trying to solve?”
That single question often changes the conversation.
Sometimes multiple proposed solutions point toward the same underlying problem.
Other times, the requested feature isn’t the best solution at all.
Discovery should uncover problems.
Solutions come later.
Data Should Raise Questions
Analytics are incredibly valuable.
But I no longer treat dashboards as answers.
I treat them as starting points.
If activation suddenly drops, I don’t immediately decide what to build.
Instead I ask:
Why?
What changed?
What assumptions are we making?
What aren’t we seeing?
Good discovery transforms data into questions rather than conclusions.
The Best Outcome Isn’t Always Validation
One of the biggest mindset shifts I’ve experienced is redefining what success looks like.
A successful discovery phase isn’t one where every hypothesis is confirmed.
It’s one where the team learns something meaningful.
Sometimes that learning says:
Don’t build this.
At first, that can feel like failure.
In reality, it’s one of the most valuable outcomes product discovery can produce.
Every unnecessary feature you avoid building creates more time for something customers genuinely need.
Create a Team That Challenges Ideas
I’ve also learned that discovery improves when disagreement is encouraged.
Some of my best product decisions came from engineers, designers, or researchers asking uncomfortable questions.
Questions like:
- What evidence supports this?
- Are we solving the right problem?
- What if our assumption is wrong?
Healthy debate strengthens discovery.
Agreement without evidence weakens it.
Learning Never Stops
One misconception is that discovery ends once development begins.
I don’t believe that anymore.
Every release teaches something.
Customers behave differently than expected.
Features find unexpected use cases.
Some ideas exceed expectations.
Others quietly disappear.
The best product teams treat launch as another discovery milestone rather than the end of discovery.
Final Thought
Looking back, I realize that my biggest product mistakes didn’t happen because I lacked good ideas.
They happened because I became too committed to those ideas before truly understanding the problem.
Today, I remind myself of one simple principle before every discovery effort:
I’m not here to prove that I’m right. I’m here to learn what’s true.
That shift has made me a better product manager.
Because discovery isn’t about collecting evidence that supports your roadmap.
It’s about uncovering insights that lead to a better one.
Leave a Reply