Most product teams I've worked with confuse user research with product discovery. They interview users, build prototypes, run usability tests—and call it discovery. But that's validation, not discovery. Real discovery happens earlier, messier, and with much less certainty.
Discovery is about invalidating assumptions, not validating ideas
The Problem with Traditional Discovery
Teams spend weeks building detailed prototypes to 'test' with users. But by the time you have a prototype, you've already made dozens of assumptions about the solution. You've decided what features matter, how they should work, and what the user journey looks like. The prototype locks you into a direction before you've validated the problem is worth solving.
I've seen this pattern repeatedly: A PM has an idea. They build a clickable prototype. They show it to 10 users. 8 say it's 'interesting' or 'could be useful.' The team celebrates and starts building. Six months later, no one uses the product.
"Discovery isn't about validating your idea. It's about invalidating your assumptions fast."
A Better Framework for Discovery
If I were restructuring discovery as a CPO, here's how I'd do it differently:
1. Start with the Problem, Not the Solution
Before any wireframes or prototypes, spend time understanding whether the problem actually exists and matters to users. Not whether they like your solution—whether they have the problem at all. Interview users without showing them anything. Watch them work. Understand their current workarounds. If there's no existing workaround, the problem might not be painful enough.
Observe users in their natural environment
2. Test Assumptions, Not Solutions
List out every assumption your idea depends on. Not 'users will like this feature' but 'users currently spend >30min/week on this task' or 'users are willing to pay for this.' Then design cheap, fast tests to invalidate those assumptions. Can you test an assumption with a landing page? A fake door test? A one-pager? Do that instead of building a prototype.
- Assumption testing is faster than prototype testing
- Failed assumption tests save months of wasted development
- You can test 10 assumptions in the time it takes to build one prototype
- Assumptions are binary: true or false. Prototypes give you ambiguous feedback
3. Make Discovery Continuous, Not a Phase
Discovery shouldn't be a phase you complete before development starts. It should run continuously, in parallel with development. While engineers build feature A, PMs should be discovering and validating feature B. This creates a continuous pipeline of validated opportunities, not a stop-start cycle of 'discover then build.'
What This Looks Like in Practice
On a recent project, we were considering building AI-powered search for our product. Instead of prototyping the feature, we:
- Interviewed 20 users about how they currently find information (most used simple filters, not search)
- Looked at search analytics from our competitors (low usage, high abandonment)
- Created a fake 'AI Search' button in our product to see if anyone clicked it (12% click rate)
- For those who clicked, showed a survey: 'What were you trying to find?' (answers revealed they wanted filters, not AI)
Total time: 1 week. Total cost: Effectively zero. Result: We didn't build AI search. We improved our filters instead. Shipped in 3 weeks. Usage up 40%.
"The best discovery is the feature you don't build because you learned it wouldn't work."
Common Pushback and How I'd Address It
'But users don't know what they want!' True. That's why you don't ask them what features to build. You understand their problems and current behavior, then design solutions they can't imagine.
'We need to move fast, we can't spend weeks on discovery!' Discovery done right moves faster than building the wrong thing. A week of good discovery saves months of bad development.
'Our leadership expects us to deliver features, not run experiments!' Then educate leadership. Show them the cost of shipping unused features. Make discovery experiments visible and celebrate the things you decided not to build.