Main idea

"Can a Product Manager push to production?" is a badly framed question, because it expects a single answer where the product is not homogeneous. The useful question is about the area: translations, content, dashboards and read-only screens carry low risk; small write actions and supervised interface changes, medium risk; payments, permissions, security, sensitive data, critical business logic and architecture, high risk.

This division does not follow product boundaries. A regulated piece of software contains relatively safe lookup screens; an innocuous-looking product contains a very sensitive area as soon as it touches permissions or an irreversible business decision. It is therefore the area, not the domain, that sets the level of requirement.

The analogy with a junior developer joining holds: you do not hand them the engine on day one, you start with simple perimeters and widen as competence is observed. The same staircase applies to a product profile who builds — provided competence, context and guardrails advance together.

Why it matters

It replaces a debate about identity with a workable decision: instead of deciding who has the right to contribute, you decide which areas are open and on what conditions.

And it guards against both excesses: the blanket ban that freezes contribution, and the blanket opening that lets someone change a billing rule the day they learned to open a pull request.

Nuances and limits

A risk map costs something to maintain, and it ages: an area held to be safe becomes less so as soon as an integration connects it to a sensitive flow.

And risk does not reduce to the area touched: an innocuous change to a shared component propagates everywhere it is reused.

Open questions

• Who draws up and maintains the map of risk areas, in a team where several jobs contribute to the same repository?