Main idea

Development has already settled, under the name of Domain-Driven Design, the question of how to isolate a perimeter, what it contains, and how information enters it from another perimeter. Organizing the study of a product opportunity by taking up that same split — a bounded space, its rules, its local truth — is not a decorative analogy: it is using the same concept on both sides.

What this removes is an intermediate layer of abstraction. When product splits by theme and engineering by domain, every crossing from one side to the other calls for a conversion, and every conversion bends the concepts a little: what the Product Manager calls a feature covers three domains, what the team calls a domain runs across two opportunities. Nobody makes the mistake deliberately; it is born of the misalignment of the splits.

Sharing the split makes those conversions unnecessary. The discussion then bears on the content rather than on the mapping between two ways of filing the same product.

Why it matters

This gives a criterion for choosing product methods that does not depend on their intrinsic quality: at comparable value, the method that shares its vocabulary with engineering costs less in use, because it carries no translation overhead.

It also shifts a recurring debate about the technical level expected of a Product Manager: what is at stake is not knowing how to code, it is splitting the work the same way.

Nuances and limits

Not every development concept transposes. Product works on bets and hypotheses, which code knows nothing of: borrowing a split does not mean borrowing an entire method.

And aligning the splits has a cost of its own: the technical split is not neutral, and adopting it on the product side means inheriting its architectural choices.

Open questions

• Which product concepts have no equivalent on the development side, and how do you keep them alive inside a borrowed split?