The stage everyone skips

The four

Decide what to build. Design it as a system. Build it properly. Ship it, then run it.

Stated like that it sounds like every process diagram ever drawn, and on its own it would be. What makes it load-bearing is that we set our own roadmap: there is no client to hand a stage to, and no point at which the code stops being ours. Skipping a stage does not transfer the cost to somebody else — it defers it to us, later.

The one that actually gets skipped

Ask a team under pressure which stage they cut and they will say design, or they will say tests. Watch what happens and it is almost always the first one: deciding what to build.

It is the easiest to skip because skipping it is invisible. Nobody files a ticket saying the problem was never narrowed. The work simply begins, and everything looks productive — screens appear, commits land, the burndown falls. The absence only becomes legible months later, as a feature nobody uses and nobody can explain the origin of.

Design and engineering shortcuts, by contrast, announce themselves. A skipped design system shows up as the tenth screen that does not look like the first. Skipped tests show up in the incident. These are painful but honest — they produce a signal you can act on.

What narrowing actually means

Deciding what to build is not writing a specification. It is answering three questions in a form specific enough to be wrong: what do we build first, what are we deliberately leaving out, and what has to be true for this to work at all.

The third one carries the weight. Most product failures are not execution failures — they are an assumption that was never written down and therefore never checked. Foodpoint's assumption is that people will trust a directory more when it excludes things. VidFlo's is that the reason people do not make screen recordings is production cost rather than inclination. Both are falsifiable, which is the point.

Why the loop matters more than the order

The four stages are drawn as a sequence, and read as one they are wrong. Nothing goes through them once.

Running a product in production generates exactly the information the first stage needed and did not have, which sends you back to narrowing the problem with better inputs. A team that treats the sequence as a pipeline gets one pass at deciding what to build, at the moment it knows least. A team that treats it as a loop gets a new pass every release.

That is also the strongest argument for staying on call for what you ship. The last stage is not the end of the process — it is the input to the first one.