Product Discovery: Know What to Build Before You Code

You know how to build. So when an idea hits, your reflex is to open the editor and ship a version. But one statistic kills that reflex: according to Pendo's 2019 report, roughly 80% of the features in a software product are rarely or never used. In other words, four times out of five, the code you write serves no one. Product discovery is the discipline that keeps you out of that statistic.

It is not one more agile ritual. It is the ongoing work of deciding what goes into the product, for whom, and in what order, based on evidence instead of your gut. For a founder still looking for first users, it is the difference between six months of well-placed dev and six months wasted.

Product discovery: what it actually is

Product discovery answers a single question: "what deserves to be built?" It comes before the delivery phase (the dev work), and it never fully stops. As long as you keep adding things to the product, you are doing discovery, consciously or not. The choice is whether to do it well.

The trap when you can code is to confuse "I can build it" with "it is worth building." You see the architecture, you feel the solution, you code. But feeling that something would be useful is not proof that anyone will adopt or pay for it. Discovery replaces that gut feeling with concrete signals: what people already do, what they work around by hand, what they spend time or money on.

The numbers all point to the same lesson. Pendo puts rarely or never used features at 80%. In parallel, CB Insights' analysis of post-mortems ranks "no market need" as the top cause of failure, at 42%, ahead of running out of cash. Discovery attacks exactly that risk, and it does so for the price of a few conversations, not a quarter of code.

The danger is not coding a feature badly. It is coding a feature perfectly that nobody wants.

Product discovery or idea validation: do not confuse them

People often mix the two, and it gets expensive. Idea validation is a moment: you test whether a problem is worth a product, at the very start. Product discovery is a continuous process: once the idea is validated, it tells you what to build next, feature after feature, for as long as the product lives. The first opens the door, the second guides every step once you are inside.

Concretely, idea validation happens with customer interviews and a handful of market signals. Discovery takes over as soon as you have the start of a product: it turns the flood of ideas (yours, your users', the ones you copy from competitors) into decisions. Without it, you build the newest feature or the one shouted by whoever cried loudest, not the most useful one.

The four risks to clear before writing code

Marty Cagan, in his work at SVPG, frames discovery around four risks to test before committing to dev. It is the most useful grid for a solo founder, because it forces you to name what you do not yet know.

Cagan says it plainly: good teams assume at least half of their ideas will not work, and the best bet on three out of four. That is not pessimism, it is the reality of product. All of discovery is about finding those dead ideas before you have coded them, not after you have shipped them.

Your product discovery loop in practice

You do not need a product team or complicated tools. A solo founder's discovery fits in a short loop you repeat at every important decision. The goal: spend as little time as possible between an idea and proof that it is (or is not) worth it.

1. Collect problems, not requests. A user asking for a button gives you their solution, not their need. Dig: "why do you want this, what does it save you?" You are after the problem behind the request, often solvable another way.
2. Frame with jobs to be done. Rephrase each need as the progress the person is trying to make. It sorts your ideas by real problem instead of by whim. The jobs to be done lens keeps you from building ten variants of the same thing.
3. Prioritize on evidence, not desire. For each idea, ask: how many people have this problem, how badly does it hurt, and what proof do I have? An idea without proof waits. A repeated, expensive pain goes first.
4. Test before you code. Mockup, capture page, Loom demo, no-code prototype: put the solution in front of five people from your target before writing it. If nobody bites, you just saved weeks.
5. Build small, measure, repeat. Ship the smallest version that proves or breaks the idea. Watch real usage, not compliments. Then run the loop again with what you learned.

This loop is nothing more than the MVP method applied continuously, idea by idea, instead of just once at launch. You stop guessing, you start discovering.

Deciding what not to build

The real muscle of discovery is not finding good ideas: you already have too many. It is killing most of them. Every feature you add weighs the product down, dilutes your message, and costs you maintenance for life. A well-placed "no" is worth ten coded features.

Before you kick off a dev, run the idea through a screen. If you cannot check it off cleanly, discovery is not finished.

From the right feature to your first user

Product discovery keeps you from building into the void, but it does not replace distribution. A perfectly chosen feature is worthless if nobody discovers it. That is why discovery and acquisition move together: the people you interview to discover become your first users, and the channels where you find them become your launch channels. To go further, start with solid customer interviews, structure what you learn with jobs to be done, and keep your real goal in sight: iterating toward product market fit with people who actually exist.

The founder who wins is not the one who ships the most features. It is the one who discovered, before coding, which ones deserved to exist, and who already knows who to show them to the day they are ready.