Define Product Roles by Decision Rights, Not Task Lists

Most product role descriptions are lists of activities. The product manager writes requirements, facilitates discovery and manages stakeholders. The designer conducts research and creates flows. Engineering estimates, builds and operates the software. Growth runs experiments.

These descriptions appear clear until the team faces an actual trade-off.

Who decides that the evidence is strong enough to build? Who can reduce scope when the delivery date is at risk? Who chooses between conversion and margin? Who stops an AI feature when its quality is technically acceptable but operationally expensive? At that point, the activity list offers little help.

This matters more now because the boundaries between roles are moving. AI tools can perform parts of research, design, analysis and implementation. Engineering is increasingly asked to start from outcomes rather than specifications. Growth decisions affect the product experience, while product decisions affect acquisition costs and commercial packaging. At the same time, the wider AI discussion keeps returning to control: who owns the model, the infrastructure, the data and the consequences.

I see one pattern across all of this. We keep discussing who does the work when the more important question is who has the right to make the decision.

Task-based ownership creates two common failures. The first is hidden centralization. A team appears autonomous, but every meaningful choice still travels to a director, founder or executive group. People can run discovery and prepare recommendations, yet they cannot change a priority or reject a stakeholder request. The organization has delegated labour, not authority.

The second failure is accidental consensus. When nobody has a defined decision right, teams try to get everyone to agree. That sounds collaborative, but it often means the most persistent stakeholder wins. Meetings multiply, metrics accumulate and the final choice becomes difficult to explain because it is a compromise between several incompatible goals.

In the Product & Growth organization I led, I found it more useful to clarify decisions than to debate the exact borders between product, growth, design and engineering. For any important initiative, I want to know who can select the primary outcome, who judges whether the evidence justifies investment, who accepts the technical trade-off, and who can stop the work. Those answers may differ by decision. That is fine. Ownership does not have to mean one person controls everything.

For example, a product manager may own the decision about which customer problem deserves attention, while an engineering lead owns whether a proposed implementation creates unacceptable operational risk. A growth lead may decide how to structure an acquisition experiment, but not quietly trade away gross margin to improve conversion. A designer may decide that more research is needed before committing to a flow, while the product leader decides whether waiting is worth the opportunity cost.

The important part is that these boundaries are discussed before pressure arrives.

Decision rights also make small experiments more useful. A small bet is not automatically a disciplined bet. If the team cannot define who will interpret the result, which metric takes precedence and what action follows each possible outcome, the experiment only produces another dashboard. Evidence-based decision making requires a decision that the evidence is allowed to change.

I would not solve this with a large responsibility matrix covering every recurring task. Those documents become outdated as soon as the team, product or technology changes. I prefer a short decision map for the choices that are expensive, frequent or contentious. It should name the decision owner, the people who must contribute, the constraints that cannot be violated and the point at which escalation is required.

Breaking down role barriers can help better ideas surface. It should not erase accountability. Anyone should be able to challenge a decision, but not every challenge should reopen it indefinitely.

A healthy product organization is not one where everybody can do everything. It is one where people understand which decisions they can make, which decisions they can influence and which decisions they must escalate. That clarity creates real autonomy because it gives teams more than work. It gives them authority with boundaries.