Main idea

The question "can a Product Manager now develop with an assistant?" calls for a yes or a no, and that is what makes it unusable. No organization proceeds that way with its own developers: you don't open the most critical repository to a beginner on day one, and you don't give them every access, all the data and all the permissions either. Competence doesn't decide on its own; it decides relative to what is at stake.

The useful formulation is therefore not a right but a perimeter. A small internal tool, personal, short-lived and without impact, tolerates little formalism: if it breaks, you throw it away. A shared tool, with limited write operations and business dependencies, already demands more. A product that touches sensitive customer data, permissions, billing or irreversible writes changes category entirely.

The same reasoning applies to competence, and not only at the entrance: someone who accepts not being able to explain certain parts of the code on an internal tool can refuse that same vagueness on a critical product. The dial isn't a character trait, it is a trade-off made product by product.

Why it matters

This gets the discussion out of the quarrel over legitimacy. Debating whether product profiles have "the right" to code produces no policy; defining what they can do, on which repositories, with what permissions and above what level of stakes produces one.

It also shifts the burden of proof. It is no longer a matter of demonstrating that a Product Manager is good enough, but of classifying products by what an error would cost there — work the organization has to do anyway, including for its developers.

Nuances and limits

The rule assumes an object's risk category is known at the time it is built. It rarely is, and a tool can change category through adoption without the initial framing ever being replayed.

Nor does it say anything about the level of requirement to adopt for each category: it fixes the question, not the grid, and that grid depends on each company.

Open questions

• Who, in an organization, is entitled to classify a product into a risk category — the technical team, security, or the business that depends on it?