The Decision Rights Map Every Product Organization Needs
Ambiguous decision authority is one of the most reliable sources of organizational dysfunction. A decision rights map makes authority explicit, reduces escalation overhead, and dramatically improves decision speed and quality.
Most product organizations have implicit decision rights — informal understandings of who decides what, usually based on seniority, confidence, and whoever is most persistent. This works tolerably at small scale. At scale, it produces a predictable set of pathologies: escalation loops, decision paralysis, retroactive overrides, and the forum shopping that occurs when people know the process is manipulable.
A decision rights map is an explicit document that names, for each category of decision relevant to the product organization, who decides, who provides input, who is informed, and what the process is. Making this explicit is not bureaucracy — it is the organizational equivalent of a well-designed API: clear interfaces that reduce integration failures and allow each system to operate independently within its scope.
Why Implicit Decision Rights Fail at Scale
In a small team, decision rights can be informal because:
- Everyone has context on most decisions
- The cost of a wrong decision is low enough to correct quickly
- Disputes are resolved through direct conversation between a small number of people
As teams grow, each of these conditions degrades:
- Context cannot be maintained uniformly across a larger team
- Wrong decisions at scale have higher cost and slower correction cycles
- Disputes require more people, more escalation, and longer resolution times
The informal system responds by adding more meetings (to distribute context), more process (to catch wrong decisions), and more escalation (to resolve disputes). These compensations increase overhead without fixing the root problem: nobody is clear on who has authority.
The DACI Framework
DACI (Driver, Approver, Contributor, Informed) is a more precise alternative to RACI for product decisions. The distinction matters:
Driver: The person responsible for running the decision process — gathering input, synthesizing options, proposing a recommendation, and ensuring a decision is made. The Driver is not necessarily the final decision maker.
Approver: The person with final decision authority. There should be exactly one Approver for each decision. Multiple Approvers means the decision requires consensus, which is slower and often produces compromise rather than quality.
Contributor: People whose input should be solicited before the decision is made. They do not have veto authority, but their input should materially inform the decision.
Informed: People who need to know what was decided, but who do not participate in making it.
The most common failure mode in product decision design is too many Approvers (each of whom can veto) or too many Contributors treated as Approvers. This produces the decision-by-committee pattern where the decision process is slow, the outcome is a least-common-denominator compromise, and accountability is diffuse.
Mapping the Decision Categories
A complete decision rights map covers five categories of product decisions:
1. Feature prioritization within squad scope
These decisions should be made at the squad level. The squad PM is the Driver and Approver. The EM is a key Contributor on technical feasibility and effort. Customer-facing stakeholders (CS lead, relevant sales partner) are Contributors on commercial urgency. The Group PM or Head of Product is Informed, not Approver.
The most common mistake: escalating squad-level prioritization decisions to the Head of Product or VP level, making that person a bottleneck and undermining squad autonomy.
2. Cross-squad feature prioritization
When a feature or decision requires trade-offs across squad scopes — allocating engineering capacity from Squad A to serve Squad B’s users, changing a shared data model, coordinating a feature that spans two product areas — it escalates to the cross-squad level.
Driver: Group PM (if one exists) or the Head of Product Approver: Head of Product or VP Product Contributors: Affected squad PMs, affected squad EMs, relevant business stakeholders Informed: All squad members affected
3. Portfolio-level allocation (Core / Expansion / Bets)
This is a quarterly or bi-annual strategic decision that determines the overall investment allocation across the product portfolio.
Driver: Head of Product Approver: CPO or CEO (depending on company stage) Contributors: VP Engineering (technical capacity and debt), VP Sales/CS (commercial priorities), Finance (budget context) Informed: All squad PMs, Engineering leadership
4. Product strategy and direction
Decisions about where the product is heading over a 12–24 month horizon: new market segments, major capability bets, platform vs. feature product decisions.
Driver: CPO or Head of Product Approver: CEO (in most cases) Contributors: Board/investors (for major pivots), Leadership team, Head of Product, VP Engineering Informed: Entire product and engineering organization
5. Technical architecture decisions
Decisions about how the product is built: data model choices, infrastructure platform, service architecture, API design standards.
Driver: Staff/Principal Engineer or Engineering Architect Approver: VP Engineering or CTO Contributors: Affected squad EMs, Product (for product implication review) Informed: All engineering teams, Product leadership
The Governance Mechanisms
Mapping decision rights is the first step. The second is building the governance mechanisms that make the map operational.
Decision record: For every significant decision in categories 2–5, a decision record is written that documents who decided, what was decided, what the rationale was, and what the assumptions are. This creates accountability and institutional memory.
Escalation protocol: When a decision is made at the wrong level (a squad decides something that should have been cross-squad) or when a decision is contested (a stakeholder disagrees with an Approver’s call), the escalation path should be explicit. Who can escalate? To whom? Through what process? Without this, contested decisions either get buried or resolved through whoever has the most organizational power at that moment.
Quarterly review of the map: Decision rights need maintenance. As the organization grows, as product strategy changes, as new leaders join, the map becomes stale. A quarterly 30-minute review that asks “are these boundaries still right?” prevents the map from becoming a historical artifact that nobody consults.
The investment in building a decision rights map is typically two to four hours of workshop time with the key stakeholders. The return is months of recovered escalation time, faster decision cycles, and significantly reduced organizational friction.
The conversation required to build the map — who decides what, and why — is often uncomfortable. People discover that they had been acting as if they had authority they do not formally have, or that decisions they thought were theirs are actually shared. That discomfort is the point. Making implicit things explicit creates the conditions for genuine organizational clarity, which is the foundation on which scale is built.