daci-framework

What this skill does

# 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.

### When to Use

- **New team formation** -- When a new team or cross-functional group needs clear decision-making roles.
- **Decision thrash** -- When decisions stall because nobody knows who has authority.
- **Scaling teams** -- When team growth creates ambiguity about who owns what decisions.
- **Post-incident** -- When a failed launch or missed deadline reveals unclear ownership.
- **Reorg transitions** -- When role changes create governance gaps.

### When NOT to Use

- For task assignment or project execution (use RACI instead).
- For individual contributor work allocation (use sprint planning).
- When decisions are truly one-person (no governance overhead needed).

## DACI Role Definitions

| Role | Symbol | Definition | Rules |
|---|---|---|---|
| **Driver** | D | The person driving the decision to closure. Responsible for process, timeline, and ensuring a decision gets made. | Exactly one per decision. |
| **Approver** | A | The person(s) with authority to approve or veto. Their sign-off is required. | 1-2 maximum per decision. |
| **Contributor** | C | People who provide input, expertise, or implementation effort. Their input shapes the decision but they don't have veto power. | As many as needed. |
| **Informed** | I | People who are notified of the decision outcome. Not part of the decision-making process. | As many as needed. |

### Key DACI Principles

1. **Every decision has exactly one Driver.** If two people are driving, nobody is driving.
2. **Approvers have veto power.** Limit to 1-2 to avoid gridlock.
3. **Contributors influence but don't block.** Their input is valued but the Driver decides how to use it.
4. **Informed means notified, not consulted.** Don't confuse notification with input.
5. **DACI is about decisions, not tasks.** Map decisions, not work items.

## Building a DACI Chart

### Step 1: Identify the Working Group

Define the team, business unit, or cross-functional group this DACI covers.

### Step 2: List Job Titles / Roles

Enumerate all roles involved in product decisions. Common roles:

- Executive Management
- Product Manager
- Product Owner
- Engineering Lead
- UX / Design Lead
- Product Marketing
- Scrum Master
- Sales & Marketing
- Customer Support / Professional Services
- Legal / Compliance

### Step 3: Define Decisions

List the key decisions this group makes. Common product decisions:

| Decision | Description |
|---|---|
| What problem are we solving? | Problem definition and validation |
| Who is the primary user? | Persona and segment selection |
| What is the product vision? | Long-term direction and strategy |
| What is the value proposition? | Differentiation and positioning |
| What are the JTBD? | Jobs-to-be-done identification |
| What goes into the backlog? | Story selection and prioritization |
| What is the release plan? | Timing, scope, and sequencing |
| What experiments to run? | Discovery and validation activities |
| How is the product built? | Architecture and technical decisions |
| How is the product delivered? | Deployment and rollout strategy |
| What data do we collect? | Analytics and instrumentation |
| How do we price the product? | Pricing model and strategy |
| What is the GTM strategy? | Go-to-market planning |

### Step 4: Build Current-State DACI

Map how decisions are made **today** (not how you want them to be made):

| Decision | Exec Mgmt | PM | PO | Eng Lead | Design | Marketing | Support | Legal |
|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| Problem definition | A | D | C | C | C | I | C | |
| User/segment selection | I | D | C | | C | A | C | |
| Product vision | A | D | C | C | C | I | | |
| Value proposition | I | D | | | C | A | | |
| Backlog priorities | I | A | D | C | C | | | |
| Release plan | I | A | D | C | | I | I | |
| Experiments | | D | C | C | C | | | |
| Architecture | I | C | | D | | | | A |
| Pricing | A | C | | | | D | | C |
| GTM strategy | A | C | | | | D | C | I |

**Rules:**
- Each row has exactly one `D`.
- Each row has 1-2 `A` maximum.
- Use `D`, `A`, `C`, `I`, or blank only.
- Add Notes column for non-obvious assignments.

### Step 5: Identify Pain Points

From the current-state chart, identify common failure patterns:

| Failure Pattern | Symptom | Business Impact |
|---|---|---|
| **No Driver** | Decision stalls for weeks | Missed market windows |
| **Too many Approvers** | Endless review cycles | Slow time-to-market |
| **Driver lacks authority** | Decision made but not respected | Rework and confusion |
| **Informed treated as Approver** | Late objections derail decisions | Scope creep and delays |
| **Missing Contributors** | Decisions made without key input | Poor outcomes, rework |

### Step 6: Design Target-State DACI

Based on pain points, redesign decision ownership:

- Ensure every row has exactly one D.
- Reduce Approvers to 1-2 per decision.
- Move chronic blockers from A to C or I.
- Add missing Contributors.
- Document changes in Notes column.

### Step 7: Create Transition Plan

| Timeframe | Action |
|---|---|
| **First 30 days** | Align on first 3 high-impact decision changes; communicate new roles |
| **60 days** | Expand to all decisions; run first decision under new DACI |
| **90 days** | Full adoption; retrospective on decision speed and quality |

## DACI Health Metrics

Track these metrics to monitor governance effectiveness:

| Metric | Target | How to Measure |
|---|---|---|
| Decision cycle time | <5 business days for P0 decisions | Time from decision identified to resolved |
| Decision reversal rate | <10% | Decisions overturned within 30 days |
| Stakeholder satisfaction | >80% | Survey: "Do you know who makes decision X?" |
| Escalation rate | <15% | Decisions escalated past intended Approver |
| Decision coverage | 100% | All recurring decisions have a DACI row |

## Integration with Other Skills

- Use `create-prd/` to document decisions made via DACI in PRD Section 2 (Contacts).
- Use `identify-assumptions/` to surface assumptions about decision authority.
- Use `brainstorm-okrs/` to align DACI decisions with quarterly objectives.
- Use `summarize-meeting/` to capture decision outcomes in meeting notes.

## Troubleshooting

| Problem | Likely Cause | Resolution |
|---|---|---|
| Decisions still stall after DACI rollout | Driver lacks confidence or authority in practice | Coach Drivers on decision-making process; ensure Approvers respect the framework |
| Everyone is marked as Contributor | Team avoids accountability by defaulting to C | Force each person to commit to D, A, C, or I -- no "everyone contributes" |
| DACI chart exists but nobody references it | Document not integrated into workflows | Post DACI in team Confluence/Notion; reference it in kickoff meetings |
| Approvers overrule without explanation | Authority without accountability | Require Approvers to document veto rationale; review in retrospectives |
| New decisions not added to chart | DACI treated as one-time exercise | Review and update DACI quarterly; add new decisions as they emerge |

## Success Criteria

- 100% of recurring product decisions have a DACI row with exactly one Driver
- Decision cycle time reduced by 30%+ after DACI implementation
- <10% of decisions reversed within 30 days of being made
- >80% of team members can identify the Driver for any given decision
- DACI chart reviewed and updated at least quarterly

## 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), pr