3. The decision document

§The question: in six months, when someone asks why, what will we be able to show them?

§Small teams make good decisions and then lose them. Not the decision itself, which sticks, but the reasoning, which evaporates within weeks and is replaced by a story. The story is usually kinder to whoever tells it. The decision document exists so that the reasoning outlives the meeting.

§ 3.1Why it matters more at five people#

§In a large company, a decision leaves a trail: the deck, the email thread, the meeting notes, the ticket. At a startup it leaves a memory, held differently by each of the three people who were there. Six weeks later one of them wants to reopen it, another is sure it was settled, and the third has left. Without a document, the decision is relitigated, and relitigating is the most expensive thing a small team does, because it spends the scarce resource, attention, on the past.

§Michael Nygard's architecture decision record solved this for engineering teams with a form so light that it gets used: context, decision, consequences, on one page. The product version below is slightly longer and no less light.

§ 3.2What it contains#

§Evidence summary. The five rows and their colors, the key findings behind each, the critical data points, the market context, and what each team member believed before the conversation. That last item matters: recording the prior positions is what lets the team see, later, that the evidence moved someone.

§Decision and rationale. What was decided, in one sentence. The main factors. The trade-offs considered and the one taken. The risks acknowledged and accepted. The opportunities identified and deliberately deferred.

§Next steps. Immediate actions with owners. Resource allocation. Timeline. The metrics that will tell you it is working, and when they will be read.

§Learning. What the team learned about the market, and what it learned about how it decides. Which row was rated too generously. Which voice carried more than its evidence. What the process would do differently.

§ 3.3One-way and two-way doors#

§Not every decision deserves the full form. Bezos's distinction is the filter: a two-way door can be walked back cheaply and should be decided fast by whoever is closest; a one-way door cannot and deserves the document. Choosing which restaurant runs the pilot is a two-way door. Choosing to build the loyalty unit on visits rather than tokens, which every later screen will assume, is a one-way door.

§The document is for one-way doors. Two-way doors get a line in the log and a name.

§ 3.4Disagree and commit, in writing#

§The document does one more thing for a small group. It records who disagreed, and that they committed anyway. Gokul Rajaram's SPADE framework makes this explicit with a step where each participant's position is logged before the decision is called, and Bezos's phrase, disagree and commit, only works when the disagreement is written where everyone can see it. Otherwise the dissenter carries it privately, and it comes back as a fight when the first metric disappoints.

§Written, the disagreement becomes an asset: if the dissenter was right, the document shows it early, and the team learns which of its members reads evidence best.

§ 3.5What comes out#

§One document, two pages at most, filed with the tension map and the two-act memo. It closes Part I. The team now knows what the evidence says, has decided whether to iterate or pivot, and has written down why. Part II takes that decision and asks a question the decision alone cannot answer: what, exactly, are we trying to achieve?