Half the loop is deciding the same thing twice.

The version people tell

Talk to users. Write the spec. Prioritise. Build. Launch. Measure. Six steps, left to right, and every step is a real thing that really happens. It is a fine story, and everyone who has shipped anything knows it is not how it goes.

The interesting question is not "why is the real version messier?" Everyone knows why: people, constraints, and information that arrives late. The interesting question is which parts of the mess are unavoidable and which parts are the team doing the same work twice.

The version that happens

Here is a loop that will look familiar. Ten stops, one feature, then it starts again.

Talk to users. Three of them want three different things. Write the spec. Rewrite it, because the data model cannot do that. The estimate comes back at three times the guess. Cut scope. Re-litigate the cut when a stakeholder escalates. Ship half. Argue about the metric, again. Learn that the real problem was the fourth request, the one that was mentioned in three calls and never counted.

Then the loop restarts, with the fourth request at the top of the list.

Nothing in that loop is unusual, and nothing in it is anyone's fault. Every stop is a reasonable response to the information the team had at that moment. That is the point: the problem is the information, not the people.

Three of the ten are the same decision, made twice

Look at the stops with an "again" on them.

Rewrite the spec

The data model cannot scope per user. Someone in engineering knew that. It came up in a review two weeks earlier, or a year earlier on a different feature. The spec was written as if nobody knew, so it had to be written twice. The constraint existed; it was not kept where a person writing a spec would find it.

Re-litigate the cut

Scope was cut for a reason: the estimate came back at three times the guess, and the deadline did not move. That reason lived in the planning meeting. When a stakeholder escalated, the cut had to be defended from memory, so it got argued again, and sometimes reversed. The decision existed; the reason for it did not travel with it.

Argue about the metric, again

Activation was defined in a standup as a week-one return, not a signup. The dashboard was built by someone who was not in that standup. So "the data is ambiguous" meant, precisely, "two people are using one word for two things." The definition existed; it was in a transcript nobody reread.

And then the tenth stop, which is a different kind of repeat: the real problem was the fourth request. It was mentioned in three customer calls. Each mention got a line in a recap. Nobody added them up, so it never made the list, and the team built the wrong thing well.

Why this is not ambiguity

It is worth being strict about this, because the two get blamed together and only one of them is fixable.

Ambiguity is when nobody in the room knows. Which of three requests matters most. Whether the stakeholder will accept the cut. What the metric will show. Those are the job, and no tool removes them. A team without any of that is not building anything new.

A repeat is when someone did know. The constraint was stated. The reason was given. The definition was agreed. The request was made, four times. The knowledge existed and then it went to the one place knowledge goes to disappear: a meeting that ended.

That distinction is the whole argument. You cannot shorten the loop by removing ambiguity. You can shorten it by not paying for the same answer twice.

What "kept once" looks like

Four things, each with a reason and a source, each filed under the part of the product it concerns rather than the date it was said:

• A constraint. The data model cannot scope per user yet. Engineering review, 2 March. Anyone writing a spec that touches permissions sees it before they start.
• A decision, with its reason. Export cut from v1, because the estimate came back 3x. Planning, 9 March. When the escalation comes, the answer is a link, not a memory.
• A definition. Activation means a week-one return, not a signup. Standup, 16 March. The dashboard and the standup are now the same word.
• A request, counted. Read-only role for finance. Asked four times, by two teams, between 4 and 20 March. It makes the list on its own.

Run the same loop with those four kept and it has seven stops instead of ten. Not zero. The three users still want three things, the estimate still comes back high, the stakeholder still escalates. Those are real. What is gone is the second time round.

Where Wisibl fits

This is the specific thing Wisibl is for. It sits on top of the tools the team already has, reads the transcripts and documents, and keeps the constraints, decisions, definitions and requests it finds, with the reason and the source attached, filed by product area. When someone starts a spec, asks why the cut happened, or builds the dashboard, the answer is already where they are looking, and it points back to the moment it was said. When there is no source, Wisibl says so rather than guessing.

It does not make product building linear. Nothing does. It makes the loop stop repeating itself.