Decision-making is the currency of execution. Fast, quality decisions accelerate progress. Slow, unclear decisions create bottlenecks, frustration, and wasted effort. Yet most organizations have murky decision rights—unclear who can decide what.
Clear decision rights are a critical component of an effective product operating model. This article provides a framework for designing clear decision rights in product organizations, drawing on Melissa Perri's work on product governance and decision-making patterns from high-performing organizations.
Why Decision Rights Matter
Every product organization makes thousands of decisions: what to build, how to build it, when to ship, how to price, whom to hire. Decision quality and speed directly impact organizational effectiveness.
- Escalation spiral: Every decision ends up with senior leadership
- Committee hell: Multiple approvals required for simple changes
- Decision vacuum: No one feels empowered to decide
- Rogue actors: Some people decide unilaterally on things they shouldn't
- Revisiting: Decisions get made, then questioned, then reversed
Clear decision rights solve these problems by specifying who decides, who inputs, and who gets informed.
The Type 1 / Type 2 Framework
Amazon popularized a useful distinction between decision types:
Type 1 Decisions: Irreversible and Consequential
- Type 1 Decisions
- One-way doors. Once made, you can't easily undo them. These deserve careful consideration, broad input, and senior oversight. Speed matters less than getting it right.
- Major architectural choices
- Significant pricing changes
- Sunsetting a product
- Major partnerships or acquisitions
- Core platform investments
Type 2 Decisions: Reversible
- Type 2 Decisions
- Two-way doors. If you get it wrong, you can correct course. These should be made quickly by the people closest to the work. Waiting for perfect information wastes time you could spend learning from real-world feedback.
- Feature implementation details
- A/B test decisions
- Process experiments
- Most hiring decisions
- UI/UX choices
This principle enables faster discovery and delivery cycles.
The Common Mistake
The opposite mistake is less common but equally damaging: treating Type 1 decisions like Type 2 decisions. Making irreversible commitments without proper consideration creates costly mistakes.
The DACI Framework
DACI (sometimes RACI) provides structure for complex decisions:
- DACI Framework
- D - Driver: Responsible for making sure the decision happens. Gathers input, creates options, ensures process is followed.
A - Approver: The person who actually makes the call. There should be only one.
C - Contributors: People whose input is needed before deciding. Their opinion should be sought.
I - Informed: People who need to know about the decision after it's made.
Using DACI Effectively
For important decisions, explicitly document the DACI:
- Who is driving this decision forward?
- Who has final approval authority?
- Whose input do we need?
- Who needs to be informed once we decide?
Decision Rights by Domain
A useful exercise: map decision rights across common decision domains.
Product Strategy Decisions
- What markets to serve: Executive team decides; product leadership contributes
- Product vision and strategy: CPO/VP Product decides; teams contribute
- Quarterly objectives: Product leadership decides; teams propose
Product Roadmap Decisions
- Which problems to solve: Product manager decides; design and engineering contribute
- Prioritization within quarter: Product manager decides
- Scope tradeoffs: Product manager decides; engineering contributes on feasibility
Solution Decisions
- User experience approach: Designer decides; PM and engineering contribute
- Technical architecture: Tech lead/engineering decides; PM contributes on constraints
- Quality bar: Engineering decides; PM contributes on tradeoffs
Execution Decisions
- Sprint planning: Team decides collectively
- How to implement: Engineer doing the work decides
- When to ship: Team decides; PM may have input on timing
Designing Decision Rights for Your Organization
Start with Friction Points
Where are decisions getting stuck? Where do escalations happen? These are signals that decision rights are unclear.
- Who actually makes these decisions today?
- How long do they take?
- How often are they revisited or overruled?
Define Desired State
For each decision type, specify:
- Who should decide (the role, not the person)
- What input is required before deciding
- How the decision should be communicated
- Under what conditions escalation is appropriate
Document and Socialize
Write down the decision rights. Share them broadly. Reference them when conflicts arise. Update them when they're not working.
Handle Exceptions Explicitly
Not every decision fits the standard model. Define how exceptions work:
- When is escalation appropriate?
- Who can override normal decision rights?
- How are precedents documented?
Common Traps
Seeking consensus sounds democratic but creates paralysis. Everyone having a vote means no one has accountability. Aim for input, not agreement.
Sometimes the formal decision rights don't match reality. The CEO "delegates" but actually approves everything. Document real decision rights, not aspirational ones.
Sometimes people avoid decisions by endless research or by waiting for more information. Set decision deadlines. Imperfect decisions beat indecision.
Defining decision rights for every possible situation creates bureaucracy. Focus on the decisions that matter most and that cause the most friction.
Speed Through Clarity
To improve decision-making in your organization:
- Classify decisions by type (reversible vs. irreversible)
- Push reversible decisions to the people doing the work
- Use DACI to clarify complex decisions
- Document decision rights for common friction points
- Revisit and refine as you learn what works
For more on organizational design for product, see our guide on Product Operating Models, The PM Mandate, or explore how we help companies clarify decision-making structures.