Product Discovery

Building software used to look a lot like filling orders. Sales wrote down what a customer asked for, the founder wrote down a feature spotted at a competitor, and engineering worked through the resulting list from the top. What to build was treated as already settled. The only open question was when it would ship.

Meetings kept stalling in the same spot. Someone would ask whether anyone would actually use a given feature, and the answer was that a customer had requested it. How many customers, and whether the thing they wanted was really this feature, went unchecked. There was no agreed way to check, so the person who raised the question felt awkward and the room moved on. Requests piled up at roughly sixty a quarter, and sorting real demand from one person's passing impression was nobody's job.

The bill arrived only after everything was built. Four months of work would ship and twenty-three accounts would touch it in the first month. At that point there was nobody to blame. Engineering delivered what was specified, on time. Sales passed along what they genuinely heard. Product wrote the document as described. Everyone did their part and there was still no result. The postmortem would conclude that the team should have validated sooner, and the next quarter would run exactly the same way, because nothing in the calendar had changed.

What was missing was a place in the schedule for asking whether a thing was worth building. Without it, an idea goes straight from a conversation into a roadmap, and the news that it was wrong arrives through the most expensive channel available — a finished, released feature. The answer costs four months of payroll. It didn't have to. Showing sketches to seven customers was possible back then too; it just wasn't written into anyone's week.

Product discovery is that missing slot, made explicit. People and time get budgeted for checking, separately from the time budgeted for building, and only what survives the check moves into the build queue. Cutting the cost of abandoning a wrong direction from four months to two weeks is the entire point.

The terms under product discovery fall into four groups: the rhythm the work runs on (methods), what findings get arranged on (tools), what gets written down (artifacts), and how far the checking has to go before it counts as done (lenses).

Before the groups, here is one full turn of the loop. In practice it runs in five steps.

1. Pick one number you intend to move, such as the share of new signups who come back in their first week. Without a target, the next four steps turn into a contest of taste, since any finding can be argued to support any feature once nobody has agreed what success looks like.
2. Go meet customers. User research covers watching people work and asking them questions; the voice of customer (VOC) covers the complaints and requests that already piled up in your inbox. Six or seven conversations is usually enough for the same sentence to start repeating, and past that point new people add very little.
3. Choose one problem from what you heard. A complaint five people raised weighs more than one a single person raised, and even an equally weighted complaint gets dropped if it doesn't connect to the number from step 1. Expect to discard nine out of ten.
4. Write down how you think the problem gets solved. What comes out of this step is not an answer but a guess recorded so it can be judged later.
5. Check that guess the cheapest way available. Show five people a prototype that is only screens, or ship the button for a feature that doesn't exist yet and count who presses it.

Methods decide how often that loop turns, and the two of them differ in what the loop runs alongside.

1. Dual-track agile — discovery and delivery run as two parallel tracks. While engineers build what cleared the check last cycle, a few people from the same team are checking the candidates for the next one. Discovery walks one cycle ahead of delivery, so engineering never sits idle waiting for a decision.
2. Continuous discovery — customer contact becomes a habit rather than a project. Instead of twenty interviews crammed into one quarter, the team sees one or two people every week. Batching means the market has already shifted by the time the findings are written up, and for the three months until the next batch the team is back to guessing. Weekly contact lets a guess made last week get tested this week, before a wrong direction ever reaches the roadmap.

Tools are what spread the findings out on one page, and there is one of them. An opportunity solution tree puts the target at the top, the opportunities blocking it on the next level, candidate solutions under each opportunity, and the experiment that would test each solution at the bottom. Drawn that way, it becomes visible which level a disagreement is happening on — one person arguing about an opportunity while another argues about a solution is the most common way a meeting spins. If "increase return visits" sits above two opportunities, weak notifications and nothing to work on at first login, and only the second one has three solutions hanging off it, the picture alone tells you what to test this quarter. Because the levels are separate, killing a solution leaves its opportunity standing, ready for the next candidate. Teams without the tree tend to drop the opportunity along with the failed solution, which quietly retires a real customer problem on the strength of one bad idea.

Artifacts turn findings into something another person can pick up, and there are two: one on the problem side, one on the solution side.

1. Problem statement — one paragraph nailing down whose problem this is, what it is, and why now. Without that paragraph, a feature can drift into solving something else entirely over four months and nobody notices.
2. Hypothesis — the guess that a given solution fixes the problem, written so it can come out true or false. "Showing a sample document raises the share of users who create their first document from 34 percent to 40 percent" carries a number and a threshold, which is what keeps the team from arguing about the result two weeks later.

Lenses decide what has to be checked before the work counts as done, and there is one. The four big risks split the checking into four questions: will people want this (value), can they figure out how to use it (usability), can we build it (feasibility), and does it work for the business (viability). Teams routinely check one and skip the rest, and the one they check is usually usability. Polishing a screen is visible work with a clear deliverable at the end of it; doubting that the thing is needed at all is uncomfortable, and it tends to arrive late, after a date has already been promised to somebody. A feature that is pleasant to use and wanted by nobody is harder to fix than a clumsy one, because there is nothing to fix.

The four groups don't run separately. Methods set the tempo of a turn, tools separate the levels of the argument inside it, artifacts pin down what was agreed, and lenses catch what got skipped. The loop doesn't always pay for itself, though. Run it over a small reversible change, or over something whose answer is already obvious, and a two-week job becomes a six-week one while the team checks its way into shipping nothing.

"That's still a hypothesis. Let's talk to five customers this week and then decide."

A brake on a discussion running on guesswork — stop arguing and go check.

"We'll run it in the discovery track for two weeks, and if it clears, it goes into the backlog for the next cycle."

Exploration is running ahead of the build schedule, and only what survives moves into delivery.

"This reads like a value problem, not a usability problem. Fixing the screen won't make them use it."

The issue isn't that the thing is awkward to use, it's that nobody needs it, so further time spent on the interface is wasted.

At Pagedeck, a document approval feature went through this loop. Sofia brought back the same request from four enterprise accounts, strong enough to sit at the top of the list.

Mia spent two weeks before anyone wrote code. She talked to seven teams, including the four who asked, about the situations where things had actually gone wrong. What repeated wasn't approval. What frightened them was finding the final version changed without knowing who had edited it or when. Approval was simply the fix they had thought of, and three of the seven teams had already built a workaround, a weekly message asking people not to edit certain documents without saying so.

Noa drew two screens: one with the approval chain they had requested, one that notified the relevant people whenever an important document changed and showed the before and after side by side. Shown to the same seven teams, six picked the second. Theo estimated the second at about half the build cost of the first. The request came in as written, what shipped was something else, and the decision cost two weeks. Building the approval chain as asked would have taken four months, and the news that it wasn't what those four accounts wanted would have arrived at the end of them.

The most common mistake is treating discovery as a phase you pass through before development starts. Plan, build, ship is such a familiar picture that exploration looks like the first box in it. In practice the loop keeps running during the build, because things you can only learn after starting keep surfacing. If it turns out in week three that customers work in a different file format than anyone assumed, changing course right then is cheap — one sprint of rework against a feature that would have shipped unusable. Fixed as a phase, someone says discovery is over, and since half the work is already built, the other half gets built too.

Assuming that asking customers produces the answer is the other common one. Interviews are the picture everyone has of this work, so asking and finding out look like the same act. But customers describe the trouble they had precisely and choose solutions badly. The approval request above is the example: all four said approval, and what actually blocked them was change history. Transcribe the requests literally and the list gets longer while the built result still goes unused. What asking gets you is the situation, not the fix; the fix gets confirmed by watching how people react to something small, like a minimum viable product (MVP). That's why interviews ask how someone handled the task last time instead of which feature they want. Predictions about future use miss often, because agreeing that a feature sounds useful costs the person nothing. Last week's behavior doesn't miss, because it already happened.