DACI: Decision Clarity for Product Teams

Summary

DACI assigns four roles to a decision: one Driver who runs the process to a deadline, one Approver who makes the call, Contributors who advise without a veto, and Informed parties who are told the outcome with context. Developed at Intuit in the 1980s and spread widely through Atlassian’s Team Playbook, it is the light, product-team member of the decision-rights family. Its two rules carry the framework: exactly one Approver, and a clear split between driving the process and making the decision. Choose it for frequent, cross-functional product decisions where speed matters; choose the heavier RAPID when a large organization needs explicit veto rights across contested functions. Assign every role to a named individual, never to a team.

The letters

DACI assigns roles to a decision, and its whole design is aimed at speed with accountability.

The two rules that carry the framework are: exactly one Approver, and a clear separation between the Driver who runs the process and the Approver who decides. A Product Manager can drive a launch decision without being the person who approves it, and naming that split is most of the value.

Origin and history

DACI was developed at Intuit, the United States financial-software company, in the 1980s, as a variant of the older RACI matrix aimed specifically at decisions rather than tasks. It addressed decision paralysis: the confusion, common when a team lacks a clear owner, over who makes the final call, who should be consulted, and who merely needs to be told.

It was popularized at scale by Atlassian, which built DACI into its widely used Team Playbook and its Confluence templates, giving the framework a canonical modern reference and spreading it through the agile and product-management communities. Unlike RAPID, DACI has no single named individual as author; it is an institutional invention from Intuit, later carried to prominence by Atlassian’s tooling and content. A key principle that both sources stress is that each role should be assigned to a specific named individual rather than a team or a job title, which is what prevents the diffusion of responsibility the framework exists to cure.

What problem it solves

DACI solves group-decision gridlock in fast-moving teams. When everyone has an opinion but no one is clearly empowered to decide, discussions circle and decisions drift. DACI cuts through this by naming one Driver to run the process and one Approver to make the call, while giving experts a defined Contributor role that carries influence but not a veto. That last point is subtle and important: the Contributor role lets you involve experts without letting any of them block the decision, which smooths the process without excluding knowledge.

Because it is lighter than RAPID, DACI suits the tempo of product and agile work, where decisions are frequent and the cost of ceremony is high. It works equally well synchronously in a room or asynchronously across a distributed team, which has made it popular with remote and cross-functional groups. The Informed role also does real work: it ensures the people whose own work will change as a result of the decision receive the context, not just the outcome.

When to choose it, and when not

Choose DACI for cross-functional or high-impact product decisions where you want clarity without heavyweight process: product roadmap choices, launch go or no-go calls, major design shifts, and significant hires. It is the right tool when the friction is a decision, the team values speed, and you want a single clear owner of the call. It is especially at home in agile and product organizations and in distributed teams that make decisions asynchronously.

Do not use it for routine or obvious decisions that do not need a framework at all, and do not use it for tasks, which belong to the RACI family. In very large organizations making high-stakes, contested decisions across many functions, RAPID’s explicit Agree veto and its heavier structure may be a better fit than DACI’s lighter machinery. The rule of thumb: DACI for velocity, RAPID for scale and contested authority.

Common pitfalls

• Two Approvers. The single most damaging error. Two approvers create a co-veto that paralyzes the process. If you are tempted to name two, you probably have two separate decisions to clarify.
• Scope too broad. “Our marketing strategy” is not a decision; “do we run a paid campaign in Q3 targeting a specific segment?” is. Write the decision as a single answerable question before assigning roles.
• Contributor sprawl. Beyond a handful of contributors you have built a consensus meeting, not a decision process. Keep the list tight.
• Driver mistaken for decider. The Driver runs the process but does not make the call. Blurring the two rebuilds the ambiguity the framework removes.
• Resistance in consensus cultures. In organizations that prize consensus, the single-Approver rule can feel authoritarian. It needs to be introduced with care, framed as speed rather than autocracy.

Worked example

A decision on whether to discontinue a product feature.

The Product Manager drives but does not decide; the VP of Product decides but did not run the process, which gives them a degree of objectivity; Engineering, Customer Success, and Legal shape the decision without being able to block it; and the downstream teams are told, with context, so they can adjust. One driver, one approver, a bounded set of contributors, and a clear informed list.

Where it sits in the family

DACI is the light, product-team member of the decision-rights family, standing opposite the heavier, enterprise-scale RAPID. Both separate the person who drives a decision from the person who makes it; DACI does so with fewer roles and less ceremony. Its Driver role is the same concept that the task-family matrix DRASCI borrows for delivery coordination. If RAPID is the framework for the twenty decisions that most shape a large company, DACI is the framework for the many day-to-day decisions a product organization needs to make quickly and cleanly.

Sources

Web sources

• DACI: A Decision-Making Framework, Atlassian Team Playbook: https://www.atlassian.com/team-playbook/plays/daci
• DACI Decision-Making Framework, ProductPlan (developed at Intuit as a RACI variant): https://www.productplan.com/glossary/daci
• DACI Decision-Making Framework, FourWeekMBA (Intuit, 1980s): https://fourweekmba.com/daci-decision-making-framework/
• DACI Decision-Making Framework guide, project-management.com: https://project-management.com/daci-model/

Academic sources

No peer-reviewed literature treats DACI as its own subject; its documentation is institutional (Intuit as originator, Atlassian as popularizer). The decision-rights research that grounds its sibling RAPID applies equally here.

• Rogers, P. and Blenko, M.W. (2006) ‘Who has the D? How clear decision roles enhance organizational performance’, Harvard Business Review, 84(1), pp. 52-61. The published evidence base for single-decider frameworks, of which DACI is the lightweight case.
• Jensen, M.C. and Meckling, W.H. (1992) ‘Specific and general knowledge, and organizational structure’, in Werin, L. and Wijkander, H. (eds.) Contract Economics. Oxford: Blackwell, pp. 251-274. The theory of assigning decision rights that DACI’s Driver-Approver split applies.