1. The bottleneck for twenty years
Building was the expensive step, so teams protected it. They validated less than they should have and built less than they wanted to, and every product methodology of the last two decades was calibrated to that cost. When the cost changed, the calibration became invisible baggage, and most teams still carry it.
- Why did teams validate less when building was expensive?
- Which assumptions in Lean, Design Thinking and the design sprint depend on building being costly?
- What did the old bottleneck do to the shape of a product team?
§ 1.1Cheap to ask, slow to make#
§For most of the history of software products, the two ends of discovery were cheap and the middle was not.
§Gathering problems was cheap. A room, an afternoon, a wall of notes, and a team had ninety pains ranked by vote. Talking to customers was cheap too, at least in money: a week of calls, a guide, a session. The second whitepaper is a catalogue of methods for doing these two things well, and none of them required much more than time and discipline.
§The middle was where it stalled. Turning an idea into something a stranger could tap through required a designer to draw it, a developer to make it work, and a of both their time. A navigable prototype was a two-week job for two specialists. A team that wanted to test five ideas needed ten weeks, or it needed to choose four of them to never test.
§ 1.2What teams did about it#
§Teams protected the middle, and the protection shaped the discipline.
§They validated less, because each validation cost a build. Five interviews with a paper sketch became the norm, not because paper was the right but because it was the fidelity the calendar allowed.
§They built less, because each build had to be worth it. Features were argued for weeks before anyone drew them, because the argument was cheaper than the drawing. Much of what passed for rigor was really the rationing of an expensive resource.
§They specialized. Someone owned the middle. The designer and the developer became the gate every idea passed through, and the product person became the one who decided which ideas were worth the gate's time. The first whitepaper's account of who holds product was written against this reality: the roles existed partly because the bottleneck did.
§ 1.3The methodologies were budgets in disguise#
§Look at what the last twenty years of product method quietly assume.
§ asks for the minimum viable product because building the full product is too expensive to risk. The word minimum is, in part, a cost argument.
§ asks for low-fidelity prototypes early because high fidelity is slow. Build to think was advice for a world where thinking was faster than building.
§The design sprint gives a whole day to a single prototype and staffs it with a designer, because that is what a prototype took, and it tests one idea by Friday because testing two would have needed two designers.
§None of these are wrong. All of them contain a real and a cost calibration wrapped around it, and the two are hard to tell apart until the cost changes. The second whitepaper profiled each of these methods by asking what it gave us, what it assumed, and where it breaks. This essay adds the sharpest version of "what it assumed": many of them assumed building was expensive, and built rules around the assumption that look like wisdom and are actually arithmetic.
§ 1.4Telling the principle from the budget#
§This is the work of the rest of the essay: for each stage of the collection, separate the rule that was a principle from the rule that was a budget. The principle survives. The budget is gone, and clinging to it is how a team ends up running a two-day design sprint on a decision it could now test five ways in the same two days.
§The next chapter is the day the budget went to zero, watched closely, in one sprint, in numbers.
Every method you learned was calibrated to a cost that no longer exists. Some of its rules were principles. Others were only budgets.
- Eric Ries, The Lean Startup (2011). theleanstartup.com
- Tim Brown, Change by Design (2009). www.ideo.com/journal/change-by-design
- Jake Knapp, John Zeratsky and Braden Kowitz, Sprint (2016). www.thesprintbook.com
- Product Thinking, whitepaper two (Product Discovery), on the lineage of methods.