Main idea

When a Product Manager pushes a pull request and a developer interviews customers, the tempting conclusion is that responsibilities dissolve along with perimeters. The opposite happens: the blurring of roles makes naming owners more necessary, not less.

A product decision remains a product decision — vision, positioning, coherence, trade-offs, market reading, customer signal — and it belongs to product. A technical decision remains a technical decision — security, performance, ability to hold the load, architecture, maintainability — and it belongs to engineering. An experience decision remains an experience decision — design system, usage coherence, accessibility, level of standard — and it belongs to design or front-end.

The organization that works is therefore not the one where everyone does everything on their own: it is the one where anyone can intervene beyond their initial domain because owners have set the standards, the guardrails and the limits. It is the clarity of those three lines that authorizes stepping outside them, not the reverse.

Why it matters

It overturns a widespread intuition about autonomous teams: contributions are not widened by erasing boundaries, they are widened by naming who answers for what.

And it gives an order of operations to a team that wants to open up: name the owners first, open the perimeters second.

Nuances and limits

The three domains do not divide cleanly. An architecture decision commits the cost of future product changes, an experience decision imposes technical constraints: the owner settles matters in their own domain, they do not decide alone what the decision produces elsewhere.

And an owner can turn into a bottleneck: if everything has to go up to them, the function of ownership becomes prior authorization, and the opening it was meant to allow closes again.

Open questions

• How does an owner set a standard explicit enough that contributions conform to it without having to consult them every time?