Main idea

On the development side, one rule is accepted: whoever creates the bug fixes it. Not to punish, but so that responsibility for the fix stays tied to responsibility for the production — even if the developer has moved on to another subject, even if it disrupts the schedule.

The same rule applies to product design, and it is rarely held to. A Product Manager who designs, then hands someone else the job of carrying the thing through to production, does exactly what we hold against the developer who ships and moves on: they never see where their understanding was insufficient, where their wording was ambiguous, where their arbitration was shaky. The cost of their approximations is paid by the team that discovers them, and the information never comes back.

The loop doesn't close — and it is that loop which produces quality. Quality can't be delegated after the fact, neither on the code side nor on the product side.

Layer added by "Quality belongs to those who ship" (2026-06-03). The rule invoked on the development side isn't only a principle of fairness: it rests on two distinct effects, and transposing it to product design inherits both. Before delivery it acts as an incentive — whoever knows their approximations will come back to them words things differently. After, it is the only circuit by which information returns to the author: anyone who fixes in their place finds a technical cause, not a decision cause. It is this second part that is missing for the Product Manager who hands others the job of carrying their design through to production — they keep the nominal incentive and lose the feedback that would teach them.

Why it matters

This gives an organization an internal test of fairness: a requirement held to be non-negotiable on the development side can't be suspended for those who design, otherwise it isn't a rule but a hierarchy.

And it explains why certain design errors repeat: the author never meets their consequences, so nothing flags them.

Nuances and limits

Following through to production consumes time, and that time comes from nowhere but the next design. The loop has a price, and accepting it means accepting a lower throughput.

Besides, a very large organization makes the loop impracticable as such: past a certain size it runs through mechanisms — post-release review, access to support, presence at demos — rather than through one person present end to end.

Open questions

• What minimal form of feedback from production is enough to close the loop, when the continuous presence of the designer isn't sustainable?