Introduction
Teams do not fail discovery for lack of process. They fail for lack of judgment: they cannot tell a problem from a solution, they treat learning as a phase, and they assume the insight sits with one person. This whitepaper is about the judgment, and about the methodologies that shaped it, each of which fixes one of those failures and breaks when applied whole to a company of one to five.
- What is product discovery and why does it matter more at a startup?
- Why do smart teams build things nobody wants?
- Which product methodologies should a founder actually learn, and which parts to ignore?
§The most expensive sentence in a startup is "we know what to build." It is said with confidence, it is usually said early, and CB Insights' long-running post-mortem of failed companies puts its consequence near the top of every edition: the largest single reason startups die is that they built something the market did not want.
§ discovery is the name for the work that prevents that sentence from being wrong. It is not research, though it uses research. It is not a phase, though companies schedule it as one. It is the judgment a founder exercises between the moment they see a problem and the moment they commit a team to a solution, and the whole of this whitepaper is an argument that the judgment matters more than any method for exercising it.
§ 0.1Three ways the judgment fails#
§Watch enough early teams and the failures repeat.
§The first is that they cannot tell a problem from a solution. Someone says "people need a better calendar," and the team hears a product, not a need. The problem, whatever people were actually struggling with, never gets stated on its own, so it can never be tested on its own.
§The second is that they treat learning as something that happens before building, in a box on the plan labelled research, after which the real work begins. Every conversation after that box closes is treated as feedback on the solution rather than about the problem.
§The third is that they assume the sits with one person: the founder who had the idea, the designer who ran the interviews, the engineer who knows what is possible. At one to five people, everyone is holding a piece of the picture, and the failure is not that the pieces are missing but that nobody puts them on the same table.
§ 0.2What this whitepaper is and is not#
§Product Foundation described the job. This whitepaper describes how the person holding it should think. It is short on instruction by design: the practical process, the conversations, the synthesis, the prototypes, is Product Sprint. What is here is the theory a founder needs so that the process does not become ritual.
§Part I draws the one distinction everything else depends on: and solution space, and the test for telling them apart. Part II profiles the methodologies that shaped modern product thinking, Design Thinking, Jobs to Be Done, Lean Startup, Agile and the Double Diamond, each through the same three questions: what it gave us, what it assumes, and where it breaks at startup scale. Part III is the three pillars that hold discovery up at a startup regardless of method. Part IV is the mental models, the habits of mind that survive when every framework fails. Part V names the failures of judgment.
§This is the whitepaper to quote from, not to fill in. Read it once now and again after the first goes wrong.
Discovery is not a phase before building. It is the judgment that decides what building is for.
- CB Insights, The Top 12 Reasons Startups Fail (2021, updated). www.cbinsights.com/research/report/startup-failure-reasons-top
- Marty Cagan, Inspired (2017), on discovery as the answer to the four risks. www.svpg.com/four-big-risks