What is Product Discovery?

What is Product Discovery?

If you're in product management, you've heard the term "Product Discovery."

Let's cut the fluff. It’s not some mystical process. It’s the disciplined work of figuring out what to build by validating which problems are worth solving.

Discovery is what stops you from wasting six months of engineering time on a feature nobody needs. It’s the formal process of separating good ideas from bad ones before you commit to building them. Its entire purpose is to find evidence of a real problem that, if solved, will create significant value for your customers and your business.

Why Bother? Why Not Just Build It?

These are the right questions. Why add a "process" when you could be shipping?

The term "Discovery" grew from user-centered design and was supercharged by the Lean Startup movement. It’s the practical application of "learning" before you "build" and "measure."

You do discovery because it fills your backlog and roadmap with ideas that are vetted, not just guesses. It helps you understand the gaps in your customer's workflow. What problems do they face every day that they've just accepted as "normal"?

Discovery gives you the evidence to find those gaps and solve them.

Discovery in the Wild: My Real-World Example

This isn't theoretical.

We had a potential client (a new lead) request a complicated feature. They wanted to "mark" transactions each time a report was generated so they wouldn't lose anything when creating an invoice.

On the surface, it seemed logical. But it felt... wrong. It was a complex solution for one client's specific invoicing problem. It was flawed.

So, we started discovery.

We met with several of our existing clients and asked them about their processes. Did they have this problem? Did they see value in the proposed solution?

The meetings took time, but they were worth it.

Our clients did have a massive issue worth solving. Just not the one the first lead described.

We found they were drowning in a manual ordering process that involved multiple Excel files, their ERP, separate invoicing systems, and endless email chains. It was a clunky, error-prone mess of cogs.

That’s how our Ordering Module came to life.

Today, our system streamlines that entire process. But here’s the key: our long-term clients never asked for it. To them, the Excel-and-email chaos was just "how systems work." It was normal life. They didn't see how we could improve it, so they never said a word.

Without that first lead’s (flawed) idea and the (correct) discovery process, we would have never found this opportunity.

How to Actually Do Discovery

So, how do you run it? As with everything: it depends.

But you can't go wrong with these principles.

1. Frame the Problem, Not the Solution. Start with a hypothesis. "We believe our users are struggling with X, which causes Y." Don't start with "We need to build a 'Mark as Invoiced' button."
2. Talk to Humans. Talk to your users. Talk to your non-users. Talk to the sales team. Talk to support. Ask open-ended questions about their process. "Walk me through how you do X." "What's the hardest part of Y?" "What spreadsheets are you using that you hate?"
3. Find the Pattern. One user asking for a feature is an anecdote. Five users describing the same underlying problem (even if they ask for different solutions) is a pattern. That's what you're looking for.
4. Prototype, Don't Build. Before you write a single line of code, test your solution. Use a Figma mockup, a PowerPoint slide, even a sketch on paper. Does this solve the problem you found? Is it usable?
5. Iterate or Kill It. The prototype will give you your answer. You either found the right track and can start refining it, or you were wrong. Being wrong is a success for discovery—you just saved your company a fortune.

Warning: The "Golden Egg" Trap

The most dangerous scenario is when discovery isn't discovery at all—it's a hunt for validation.

This often comes as a "brilliant idea" from the CEO or a "golden egg" from the sales team. "This one client will sign a huge contract if we just build this one function!"

Would you go for it?

Trust me, there's a lot to think about. Even if the key concept is good, it's still just one client.

A "golden egg" isn't a build order. It's a fantastic starting point for discovery.

Your job is to take that idea and check it against the market. Call other users. Do they have this problem? Can we solve it in a way that helps most of our customers?

The ideal scenario? The golden egg really is gold, and it solves a problem for everyone. More often, the real gold is the problem behind the request—just like in my example.

---

Final Thoughts

My mission is to spread practical knowledge about product management. I want to see these skills taught just like programming.

If this was useful, sign up for my newsletter and follow me on socials for more product insights.