Main idea

The Product Manager answers for the product choice: why this subject, for which audience, with what expected impact, in what order. Developers answer for the technical quality of what they ship: the code, the code base, what goes to production. If the product trade-off is bad, the first owns it; if the code is fragile, poorly tested, poorly understood or hard to maintain, the second own it.

These two zones talk to each other constantly — a good product is built in the exchange between choice, feasibility, usage and technical constraints — and that is where the confusion sets in. Because the decision was discussed, each side can consider itself partly bound by the other's, and therefore fully responsible for neither.

Dialogue serves to work up the decision, not to mutualize it. Treating developers as executors and diluting their responsibility in a collective decision are two opposite ways of taking the same thing from them: ownership of what they ship.

Why it matters

This gives a workable test in a dispute: ask not who took part in the decision, but who could have blocked it single-handedly. The zone is read from that veto right, not from attendance in a meeting.

It also avoids the reverse reading, just as costly: sealed-off zones where product never discusses feasibility and engineering never discusses usage.

Nuances and limits

The boundary is not always clean. A technical design choice can determine a user-visible behavior, and a product trade-off can impose debt. What counts then is knowing which of the two zones settles it, not making the subject disappear.

And the split presupposes that developers actually have the latitude to arbitrate their own quality — without that latitude, the responsibility is assigned to them without having been given to them.

Open questions

• Who settles it when a product trade-off can only be met at the price of technical debt the team refuses?