Why That’s Not Discovery (And How to Do It Right)**
At one of my past startups, a founder walked into the room excited.
“We’ve heard from three customers—they all hate onboarding. Let’s build a wizard. Should take a week. Let’s go!”
Everyone nodded. We built it fast.
Two sprints later, usage didn’t budge. In fact, onboarding completion dropped.
That’s when it hit me:
We hadn’t done discovery.
We had done assumption with urgency—a very expensive version of guessing.
Discovery Is the Hardest Part of Product Management
Most PMs are great at roadmapping, sprint planning, or shipping features.
But the best PMs I’ve worked with obsess over one thing:
Are we solving the right problem for the right user in the right way?
That’s discovery.
It’s not a kickoff phase.
It’s not a one-week research sprint.
It’s an ongoing habit of listening, learning, and testing—before building.
⚠️ Signs You’re Skipping Discovery
- Features are shipped, but no one uses them
- You hear “Let’s build this quickly and test it” — but never talk to a user
- Priorities change weekly, based on internal opinions
- You realize too late that the customer’s actual pain was elsewhere
Been there. Lived it. Learned the hard way.
🛠️ Real Discovery Is a Cycle, Not a Step
Think of product discovery as a loop, not a checklist. The most common framework I use is the Double Diamond:
1. Discover the Problem
- User interviews
- Support tickets, reviews, NPS comments
- Shadowing and observations
- Analytics (funnels, drop-offs, rage clicks)
🎯 Goal: Understand the real pain—not just the symptoms.
2. Define the Problem Clearly
- What’s the job to be done?
- Who exactly has this problem (segment)?
- What are the consequences of not solving it?
Tip: If your team can’t align on the problem statement in one sentence, don’t build yet.
3. Explore Many Solutions
- Sketch multiple ideas with your designer and engineers
- Use Crazy 8s, storyboards, journey mapping
- Consider no-code experiments, concierge models, prototypes
🎯 Goal: Avoid falling in love with the first idea. You need options, not a favorite.
4. Test Solutions Before Writing a Line of Code
- Figma prototypes
- User interviews with mockups
- Email copy tests or fake doors
- Landing pages with signups
Real story:
One time, we tested 3 onboarding flows using a simple Typeform. One version got 70% more “I’d try this” reactions—before we designed anything.
🧠 Discovery Habits of Great PMs
- They block time weekly to talk to users
Not just during “research months.” Weekly. Even 2 calls a week changes how you think. - They write Problem Briefs—not just Feature Specs
- Who’s the user?
- What’s their pain?
- How are they solving it today?
- Why now?
- They bring designers and engineers into discovery
This builds shared context—and better ideas.
Plus, your team becomes emotionally invested in solving the right thing.
🛑 Discovery Is Not…
- A survey with 50 questions
- A UX researcher’s responsibility alone
- Building an MVP and hoping for the best
- A meeting to decide “what feels right”
Discovery is talking less, listening more, and learning before investing.
🔄 From Gut Feel to Insight-Driven Roadmaps
After that onboarding failure, we went back to users.
We didn’t ask, “Do you like the wizard?”
We asked, “When you signed up, what confused you the most?”
The real issue?
They didn’t understand how our product integrated with their current tools.
We added a “Connect your tools” step before onboarding.
Completion rate went up 40%.
Users actually stuck around.
That’s the power of real discovery.
Final Thoughts: Learn Before You Build
In product management, your job isn’t to ship features.
Your job is to:
- Uncover pain
- Frame it clearly
- Test your way into confidence
So the next time someone says,
“I think this will work.”
Smile and say,
“Let’s go find out—before we commit the sprint.”
Because discovery isn’t a delay.
It’s what separates busy teams from breakthrough products.
product.guru 
Leave a comment