9. Four tests before building

§The question this chapter answers: is this solution clear enough that a test of it would mean anything?

§Teams skip from the canvas to the build because building feels like progress. Four tests stand in the way, and each takes minutes. They exist because a prototype of an unclear idea produces unclear results, and unclear results are worse than none: they feel like evidence.

§ 9.1One sentence#

§Say what it is, in one sentence, to the person it is for. Not to an investor, not to a friend who builds software. To the restaurant owner, in the words from chapter 4.

§"It tells you what to reorder before you close, so you never run out during service." That works. "An AI-powered inventory intelligence platform for the hospitality vertical" does not, and it does not for a reason that matters: the second sentence is about you, and the first is about them.

§If you cannot write the sentence, the solution is not yet one thing. It is usually two, and you should split it.

§ 9.2One napkin#

§Draw it. A napkin, a whiteboard, the back of the canvas. Boxes and arrows. What does the person see first, what do they do, what happens.

§The napkin test catches a different failure from the sentence test. Solutions that can be described often cannot be drawn, because the description hides a step nobody has thought about: how the data gets in, who approves the thing, what happens when it is wrong. The napkin makes the hidden step visible, and Ryan Singer's argument for rough sketches over polished mockups holds here: the roughness is what keeps the conversation on the shape and off the surface.

§ 9.3Thirty seconds#

§Convince someone of the value in half a minute. Not the features, the value: what changes for them.

§This is not about pitching, and the person you convince should not be an investor. It should be someone who has the problem, because the thirty-second test measures whether the value is legible to them without your context. Kevin Hale's advice for pitches applies to product: if the listener has to work to understand, they will not, and you will mistake their confusion for disinterest. The reverse also happens. A value that lands in thirty seconds with the person it is for is the strongest early signal you can get without building anything.

§ 9.4Current resources#

§Can you build a first version with what you have? Not the vision, the first version. With the people, money, skills and tools you have this month.

§Before 2023, this test killed a great many good ideas, because a first version meant a developer and a designer and weeks. It kills far fewer now. A navigable prototype from a written brief is a two-day job for people who have never built one, and the case in chapter 16 is the proof. But the test still applies, and it applies to the parts that are not software: the data you need and do not have, the partner you need and have not met, the regulation you need to understand and do not. Paul Graham's test for ideas is whether you are the right people to have this one. The resource test is its practical form.

§ 9.5What the tests are for#

§They are not a gate that ideas must pass. They are a way of finding out what you do not yet know about your own solution. A failed sentence test tells you the idea is two ideas. A failed napkin tells you there is a hidden step. A failed thirty seconds tells you the value is not yet in the customer's language. A failed resource test tells you what to go and get before you build.

§Fail them early, in the room, with nothing at stake. The alternative is to fail them in front of a stranger, with a prototype, having spent two days.

§ 9.6What you leave with#

§For each canvas that survives: the one sentence, in the customer's words. The napkin, photographed. A note on who you said the thirty seconds to and what their face did. And an honest list of what you would need to build the first version that you do not currently have. The canvases that failed go back to chapter 8, or into the drawer.