Product Discovery: Finding What's Worth Building

Lesson 1 named the costliest failure in product work: building the wrong thing well. Discovery is the discipline that prevents it. It is the work a product manager does to figure out what is worth building before the team invests months building it.

The stakes are enormous. Studies and post-mortems of failed products point again and again to the same root cause: not bad engineering or bad design, but building something customers did not actually want. Engineering time is the most expensive resource a company has, and pointing it at the wrong problem wastes it completely, no amount of execution quality recovers a product nobody needs.

Discovery is the PM's answer to this risk. Instead of assuming you know what to build and diving into construction, you deliberately investigate:

• What problems do users really have, and how badly?
• Which are worth solving, for enough people, in a way the business benefits from?
• Would a given solution actually get used?

The goal is to be reasonably confident you are building something valuable before you build it, replacing expensive guesses with cheap learning. This lesson covers the core discovery skills: distinguishing problems from solutions, understanding real needs through jobs-to-be-done, talking to users well, and validating demand before committing. These are the skills that most separate an effective PM from an order-taker, and they are learnable.

The single most important habit in discovery is to fall in love with the problem, not the solution. Beginners, and stakeholders, tend to arrive with a solution already in mind ("we need an app that does X") and jump straight to building it. The discipline is to step back and first deeply understand the problem the solution is supposed to address.

Why this order matters:

• A solution is only as good as the problem it solves. If the problem is not real, painful, or common, the most elegant solution fails. Validating the problem first prevents building polished answers to questions nobody is asking.
• One problem has many solutions. Fixed on the first solution, you never consider the others, and the first idea is rarely the best. Understanding the problem opens the space of possible answers.
• Requests are not needs. When a user asks for a feature, they are proposing a solution to an underlying need. The classic line, often attributed to Henry Ford, is that customers might have asked for a faster horse; the underlying need was faster transport, which the car served far better. Your job is to hear the request and dig to the need beneath it.

This is why PMs are trained to keep asking "what problem are we really solving?" and to resist jumping to features. A good PM can restate any proposed feature as the user problem it is meant to solve, and if they cannot, that is the signal that discovery has not happened yet.

A powerful lens for understanding the real problem is jobs-to-be-done (JTBD), a framework associated with Harvard Business School professor Clayton Christensen. Its core idea: people do not really want products, they "hire" a product to get a job done in their lives.

Christensen's famous example: a fast-food chain studied why people bought milkshakes and found a surprising job. Many customers were "hiring" a morning milkshake for a boring commute, they wanted something to occupy a long, dull drive that was not messy and lasted. The competition was not other milkshakes; it was bananas, bagels, and boredom. That insight changes what you build entirely.

JTBD reframes discovery around the job, not the demographic or the feature:

• Focus on the progress the user is trying to make. "When [situation], I want to [motivation], so I can [expected outcome]."
• Understand the context and the alternatives the user currently uses to get the job done, including workarounds and doing nothing.
• Design for the job, which often reveals needs a feature-request never would.

For a PM, JTBD is a practical antidote to shallow discovery. It forces you past "users want a dashboard" to "what is the user actually trying to accomplish, and what would truly help?" Understanding the job is understanding the problem at the right depth, which is exactly what good discovery requires.

Discovery runs on talking to users, and doing it well is a skill with real technique, because done badly it produces confident, misleading answers. The central rule: ask about their actual experiences and problems, not about your solution or hypotheticals.

Good and bad questions differ sharply:

• Do ask about the past and the concrete. "Tell me about the last time you had to do X." "Walk me through how you handle that today." "What was frustrating about it?" Real stories reveal real behavior.
• Do not ask hypotheticals or pitch. "Would you use a feature that does X?" is nearly worthless. People are bad at predicting their own future behavior and, to be polite, will say yes to almost anything. This is the trap the book The Mom Test by Rob Fitzpatrick is built around: ask questions even your mom could not give you a falsely encouraging answer to.
• Listen far more than you talk, and dig. Follow "why" and "tell me more"; the goal is to learn, not to validate what you hoped.

Two more principles. Talk to enough of the right users, a handful of real target users surfaces most major problems, far more cheaply than a big survey. And separate what people say from what they do, stated preferences are weak evidence; actual behavior is strong. Interviews find and frame problems; the next step tests whether people will actually act.

Understanding a problem is not proof that people will use, or pay for, your solution. Before committing months of engineering, a PM validates demand cheaply, testing the risky assumptions with the least possible work. The principle: spend a little to learn before spending a lot to build.

Common low-cost validation methods, roughly from cheapest up:

• Landing-page / smoke test. Describe the solution on a simple page with a "sign up" or "buy" button and see if the right people click. Interest expressed with a click or an email is far stronger than a verbal "sure, sounds good."
• Prototype tests. Put a clickable mockup (no real code) in front of users and watch them try to complete the job. Reveals whether the solution actually works for them.
• Concierge / Wizard-of-Oz. Deliver the value manually behind the scenes before automating it, so you learn whether people want the outcome before building the machine.
• Pre-sales or a waitlist. The strongest signal short of a full launch: people committing money or a spot before the thing fully exists.

The unifying idea is de-risking: identify the assumptions that would sink the product if wrong (do people have this problem? would they use this? would they pay?), and test the riskiest ones with the cheapest experiment first. This connects to the continuous-discovery practice taught by Teresa Torres, discovery is not a one-time phase but an ongoing habit of testing assumptions with small experiments before and while you build.

See discovery work end to end. A PM at a small accounting-software company hears a stakeholder say: "We should build a mobile app."

1. Resist the solution. Instead of scoping an app, the PM asks: what problem would a mobile app solve? For whom? No clear answer yet, so this is an untested solution, not a validated need.
2. Investigate the problem. The PM interviews a dozen customers about their actual work: "Walk me through your last month-end." A pattern emerges, not "I want an app," but "I need to approve expenses while traveling, and I cannot until I am back at my desk, which delays everyone."
3. Frame the job. The job to be done: "When I am away from my desk, I want to approve pending expenses quickly, so the team is not blocked." That is sharper and truer than "build an app."
4. Consider solutions. A full mobile app is one option, but so is a mobile-friendly approval email or a lightweight approvals-only mobile page, far cheaper and possibly sufficient for the job.
5. Validate cheaply. The PM mocks up a simple mobile approval flow and tests it with five traveling customers, and floats an email-approval version. Users strongly prefer quick email approval, revealing the full app was overkill.

Result: the team ships a small, high-value feature that solves the real job, instead of spending six months on an app built to a stakeholder's untested guess. That is discovery earning its keep, and it is the everyday craft of the role.

Discovery has a shape you can carry into any product role. Here it is as a set of habits and their traps.

The throughline for a career switcher: discovery is where product management stops being about opinions and starts being about evidence. It is a learnable, repeatable process for reducing the biggest risk in product, building the wrong thing, and it is the skill that most distinguishes a real PM from someone who just writes down what stakeholders ask for.

Discovery tells you what is worth building. But you will always find more worthwhile problems than you can possibly address at once. That creates the next challenge, deciding which of the validated opportunities to build, and in what order. That is prioritization, the subject of Lesson 3.

Discovery starts from a problem or request, digs to the real user problem and the job to be done through user interviews, explores multiple solutions, validates the riskiest assumptions cheaply, and only then builds, looping back whenever evidence says the idea is wrong.