16. Failure modes of judgment

§Every whitepaper in this book ends its argument with how the thing fails, because failures are more recognizable than successes and a founder mid-failure needs a mirror more than a model. Discovery fails in four ways. None of them is a lack of method. All of them are a lapse of judgment while a method was being followed.

§ 16.1Rushing to solutions#

§The first and most common. The team has a problem in view, sort of, and an idea in hand, definitely, and the idea is exciting and the problem is vague, so the team builds the idea and calls the building validation. Part I of this whitepaper exists to prevent this and it still happens to people who have read Part I, because the pull of the solution is emotional and the discipline of the problem is not.

§The check is the photograph. Before the first line of code or the first prompt, can the team describe, in one paragraph, a specific person in a specific place having the problem? If the paragraph contains a feature, the team is in the solution space early.

§ 16.2Research as a checkbox#

§The second failure is subtler because it looks like the cure for the first. The team knows it should do discovery, so it does: a round of interviews, a survey, a competitor analysis, all completed, all filed. Then it builds what it was always going to build. The research happened. It changed nothing, because it was never going to be allowed to.

§The check is conversion, from the previous chapter. What did the research change? If the roadmap after the research is the roadmap before it, the research was a ritual. Real discovery costs the team something: a feature it wanted, a market it assumed, a belief it held.

§ 16.3Discovery delegated to one person#

§The third failure is structural. The company decides discovery is the product person's job, or the designer's, or the founder who likes talking to customers. That person collects the slices; everyone else waits for the summary. Part III's third pillar was written against this, and the reason it fails is not that one person cannot do the work. It is that the insight lives in the connection between what the engineer knows, what support hears and what sales is told, and a summary arriving from one seat has already lost the connections.

§The check is the table. Where do the slices meet? If the answer is "in the head of one person who then tells us," the connections are being made by one person's sense of relevance, and the surprising ones, which are the valuable ones, do not survive.

§ 16.4Frameworks followed rigidly#

§The fourth failure is the one the whole of Part II was written to prevent. A team adopts a method, Design Thinking or Lean or the Double Diamond, and runs it faithfully, in a context the method's authors never imagined. The workshops happen. The phases complete. The method was designed for a different bottleneck, a different team size or a different decade, and its faithful execution consumes the runway on the wrong thing.

§The check is the assumption. Every method in Part II was profiled with what it assumes. Before running one, ask whether the assumptions hold here. A method whose assumptions do not hold is not wrong; it is a tool for a different job, and using it well is still using the wrong tool.

§ 16.5What they share#

§All four feel like progress. Building feels like progress. Completing research feels like progress. Having an owner for discovery feels like progress. Following a respected method feels like progress. The common thread is activity substituting for the one thing discovery is for: a decision, changed by evidence, about what to build.

§The conclusion of this whitepaper asks how the failures change when the activity that most resembles progress, building, becomes nearly free.