DACI Decision Framework
Overview
Clarify decision ownership and reduce decision thrash using the DACI framework (Driver, Approver, Contributor, Informed). Unlike RACI which focuses on task responsibility, DACI is purpose-built for product decisions -- who drives the decision to closure, who has veto power, who provides input, and who needs to know.
The four roles in brief: Driver (exactly one, drives to closure), Approver (1-2 max, holds veto), Contributor (input without veto), Informed (notified, not consulted). Build a chart by mapping current state, finding pain points, designing target state, and rolling out a 30/60/90 transition. See the playbook reference for role rules, the 7-step build sequence, and health metrics.
When to Use
- New team formation -- A new cross-functional group needs clear decision-making roles.
- Decision thrash -- Decisions stall because nobody knows who has authority.
- Scaling teams -- Growth creates ambiguity about who owns which decisions.
- Post-incident -- A failed launch or missed deadline reveals unclear ownership.
- Reorg transitions -- Role changes create governance gaps.
When NOT to Use
- Task assignment or project execution (use RACI instead).
- Individual contributor work allocation (use sprint planning).
- Truly one-person decisions (no governance overhead needed).
Clarify First
Before building the DACI chart, confirm these inputs. If any is unknown or vague, ASK — do not assume:
- [ ] The specific decisions to map — the 3-5 high-impact decisions, not "everything" (each becomes a chart row; mapping too much at once is the top failure mode)
- [ ] Candidate people and their real authority — who can actually approve or veto (drives the Driver and Approver assignments; without genuine authority the chart is fiction)
- [ ] Current pain points — where decisions stall or thrash today (drives the current→target-state gap and the 30/60/90 transition plan)
Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.
References
- references/playbook.md — read this when building or running a DACI chart: role definitions and rules, the 7-step build sequence (working group → roles → decisions → current-state map → pain points → target-state → transition plan), governance health metrics, troubleshooting, and success criteria.
- references/red-flags.md — read this before publishing a chart or running a decision under it: common ways a DACI chart goes wrong with bad/good examples anchored to the role rules.
Scope & Limitations
In Scope: DACI chart creation, current-state mapping, target-state design, transition planning, governance health metrics, pain point identification, decision ownership clarity.
Out of Scope: Task assignment (use RACI), project execution tracking (use sprint planning), individual performance management, organizational design beyond decision governance.
Important Caveats: DACI works best when leadership commits to respecting the framework. Without executive buy-in, Drivers may lack the authority to actually drive decisions. Start with 3-5 high-impact decisions rather than trying to map everything at once.
Integration Points
| Integration | Direction | What Flows |
|---|---|---|
| create-prd/ | Feeds into | DACI decisions inform PRD Contacts section and decision log |
| identify-assumptions/ | Complements | Surfaces assumptions about who has authority |
| brainstorm-okrs/ | Complements | OKR ownership aligns with DACI decision ownership |
| summarize-meeting/ | Feeds into | Meeting summaries capture DACI decision outcomes |
| senior-pm/ | Complements | Portfolio-level DACI for cross-project decisions |
Further Reading
- Productside DACI guidance for product teams
- Inspired by the DACI framework used at Intuit and other product-led organizations