A plan is not finished when the build starts

Why the plan stops being used

Not because it was wrong. Because of what it feels like once code exists.

A written plan looks finished. It has sections and answers, and answers invite you to stop thinking about them. Meanwhile the build produces a stream of small, urgent, concrete questions, and the document — general, calm, three weeks old — never seems to be the fastest place to look. So the decision gets made in the code, and the plan quietly becomes a historical record of what you believed before you knew anything.

The fix is not discipline. It is noticing that the plan was written at the moment of least information, and the build is what supplies the rest.

Everything in the plan was a guess. Shipping is what tells you which guesses were wrong.

Close the open decisions, one at a time

A plan written properly ends with a list of decisions that were not made — the ones deliberately left open so they would not be settled by accident. That list is the first thing to work through after v1, because each item is now cheaper to answer than it was.

An open decision closes when three things are true.

• Something real is pressing on it.A user hit it, a support question named it, or the next stage cannot start without it. Not “we should decide this at some point”.
• The evidence exists now and did not before.Usage, a failed path, a request that arrived twice. If the answer is still a guess, leave it open — a guess written down as settled is worse than a question.
• You write down what closed it.The reason, not just the choice. The reason is what stops it being reopened every month by whoever feels differently.

Closing a decision moves it out of the open list and into the invariants — where it becomes something the next change is not allowed to break, and something an agent can be given before it writes anything.

Revisit the cut list, with the reasons attached

The other half of the plan worth reopening is what you deliberately cut. Each cut was written with a reason next to it — and that reason is the thing to test, not the feature.

Take each cut and ask what its reason claimed, then check whether that claim survived contact with real usage.

A cut whose reason no longer holds is not automatically in. It goes back through the same filter as anything else, because the boundary is what keeps the product explainable — and “we cut it once” is not a reason either.

What not to reopen

Post-launch is also when a plan gets destroyed by good intentions. Two things should be much harder to change than everything else.

The positioning line. Early usage is thin and unrepresentative, and the first five users will pull it in five directions. Changing who the product is for because of three conversations is how a narrow product becomes a vague one. Change it when you can say what was wrong about the old line — not because a new one sounds broader.

The invariants. The rules a decision closed and that everything now reads from. These get quietly broken rather than debated: a change lands that violates one, nothing visibly breaks that week, and the rule stops being true without anyone deciding it should. Breaking an invariant on purpose is fine. Discovering later that one was broken is not.

A rhythm that actually survives

None of this needs a process. It needs the plan to be somewhere you already look, and one recurring moment when you look at it deliberately.

• Weekly, with the build log. Anything the week settled goes into the plan while you still remember why — the log already carries the evidence, so this is five minutes on top of a habit you have.
• At the end of each build stage. Before starting the next one, check that the decisions it depends on are actually closed. A stage built on an open decision is where rework comes from.
• Whenever a cut gets argued for the second time. Twice is a signal. Either the reason is weak and should be updated, or it is strong and should be easier to find.

Do that and the plan stops being a document you wrote and becomes the place the product is actually decided — which was the whole point of writing it. The alternative is not chaos on day one. It is a slow return to the state that made a plan necessary: a growing list of reasonable ideas and no way to say what happens next.