Order is a product decision

There is no trick in the arithmetic, and the mechanism is worth saying slowly because it is the whole session.

The job needs four core outcomes. Until all four are met, the organiser still cannot do the thing he came for, so the tool is not yet usable to him - it is a building site with some finished rooms in it. Loudest-first spends its early weeks on features that serve other outcomes: real ones, ones people genuinely asked for, but ones the job did not need first. Every one of those weeks is a week where the count of unmet core outcomes does not move. The core outcomes get built eventually, because everything gets built eventually, but they get built near the end, and the usable date follows them there. Week 33.

Job-first does the identical twelve features and simply takes the core four early, cheapest route first. All four are met in week 5. Everything after that is improvement to a thing that already works, which is a completely different kind of week to be having.

Note what did not change. Job served at the end: 96.7% both times. Total build: 34 weeks both times. Cost: identical. This is not a trade. It is free.

Fair question, and the honest answer has two halves.

The first half: yes, the size of the gap is an artefact. Twenty-eight weeks is a property of this invented backlog. A different set of twelve features with different costs would produce a different number, and some backlogs would produce almost no gap at all - if the loudest requests happen to be the core ones, both orders arrive on the same day.

The second half: the mechanism is not an artefact. A gap appears whenever the things people ask for loudest are not the things the job needs first. That condition is not exotic. Loudness tracks who is in the room, how recently they were annoyed, and how easy the thing is to describe. None of those is correlated with what the job needs first, so the two orders will differ most of the time, and the only question is by how much.

What you should not take away is a rate. No published figure exists for how often build order costs real projects time, and none is claimed here. What you can take away is that the check is cheap: you can compute your own version of this in twenty minutes with a list and a pencil, which is exactly what the build-along does.

The week-five Ferry does the job. It does almost nothing else. Most of the twelve features are not there yet, and the missing ones are not imaginary - somebody asked for each of them, several people will notice they are absent, and at least one person will be annoyed in a way that costs you an awkward conversation.

It will also be wrong in ways you cannot see yet. Real use always reveals something the plan did not contain, and the fixes land in code that other people are now depending on, which is more expensive than fixing a plan. Shipping early converts cheap changes into expensive ones by putting users on the other side of them.

And it starts a clock you cannot stop. From week five there is a thing in the world that can break on a Thursday night, that somebody has to answer questions about, and whose absence on a Saturday is now your fault in a way it was not before. Support, expectations and the cost of changing something people rely on are all real, they all arrive at first ship, and none of them appears in a build estimate.

So the claim is not that early is free. It is that twenty-eight weeks of a tool that does the job, with all of that attached, usually beats twenty-eight weeks of a more polished plan. And the early version does something no plan can do: it tells you which of the remaining features anybody actually wants, using evidence instead of a meeting.

Three situations where the early version is a bad idea, and they are worth knowing so that you do not apply tonight's lesson to all of them.

When being wrong in public is unrecoverable. If a first version that miscounts costs somebody their money, their safety or their licence, the cost of early breakage is not a support ticket. The calculation changes, and it should.

When you only get one look. Some audiences will try a thing once. If your users are a hundred strangers who will never come back after a bad first minute, an early version can burn the only attention you were going to get. Note that this rarely applies to internal tools, where the audience is captive and knows you.

When the core outcomes genuinely need all of it. Sometimes the four core outcomes are simply expensive, and there is no cheap route to them. Then first-usable and finally-finished converge, and the honest answer is that ordering buys you little here. The bench shows this too: a cut that misses a core outcome ships fastest of all and is never usable, because speed to a thing that does not do the job is not speed.

One. Mark the core. Go down the list and mark every item that a core outcome cannot be met without. If you cannot say which outcome an item serves, that is not a mark against your memory, it is a finding about the item.

Two. Within the core, cheapest first. Not most important first - cheapest first, among the things that are all required anyway. Since every core item has to be built, the only variable left is which order gets you to the complete set soonest, and taking the cheap ones first does that. This is the step people skip, and it is the one that moves the date.

Three. Everything else goes after, in whatever order you like. Once the job is being done, the order of the remainder genuinely matters less, and now you can afford to let loudness decide some of it, which is a cheap way to be generous.

Four. Write down the week number. Both of them: the week the old order first produced something usable, and the week the new one does. A reorder that does not move that number was not worth the meeting, and knowing that is also a result.

Of the three alternatives, hardest-first is the one with a real argument behind it, and it deserves better than being lumped in with the other two.

Its logic is about information, not about output. If one item on your list might turn out to be impossible, or three times its estimate, or dependent on something nobody has permission to touch, then every week you spend elsewhere is a week spent building on a plan that might be void. Doing the scary item first buys you the right to abandon or reshape the whole plan cheaply. That is a genuine purchase, and it is the correct call when the uncertainty is large enough to invalidate everything else.

The tell for whether it applies: can you name the specific thing you do not know, and say what you would do differently if the answer came back badly? If yes, do it first, and you are not arguing with tonight's lesson - you are applying the same reasoning to a different thing that blocks everything. If you cannot name it, "get the hard bit out of the way" is usually just discomfort looking for a schedule.

Easiest-first has a thinner but real case: a team that has never shipped anything together sometimes needs to prove it can, and a quick win is a cheap way to buy that. Notice the beneficiary is the team, not the person with the problem. That can still be the right call. It just should not be an accident.