Product Management makes decisions, lots of them. Some days it’s 10 small decisions about the product interface, some days it’s one major decision about a $3M acquisition. Decision making is part and parcel to the job.
Yet, decision making is the most critical and contentious activity that any team undertakes. Thus, having a trustworthy and systematic way to approach decision making is an important part of any Product team’s arsenal.
There are many ways to make a decision. Here are some common frameworks:
- The loudest person in the room wins (I’m sure we’ve all seen this movie before)
- The most mentioned name/item/project wins (sadly, this is how elections work)
- Choose two people who represent opposite views, have them arm-wrestle for it (bring some popcorn for this one)
- The most senior in rank decides (unfortunately, this person might not be close enough to problem to make an informed decision)
- Everyone votes and everyone has to agree (this often creates a stalemate)
- Everyone chickens out and delay the decision for as long as possible (sadly, this happens more often than we’d like, and makes life very hard for the execution team, as they need to build for all scenarios)
As much as we claim to be objective when making a decision, we are only human. And we are subject to:
- Recency bias
- Anchoring bias
- Availability bias
- Bandwagon effect
- Choice-supportive bias
- Confirmation bias
And this is not even the full list. When it comes to decision making, we are influenced by all of the above, company politics and personal fears. “How will I be perceived if I push for decision A?” “Will voting against decision B alienate me from manager X?”. Talk about a minefield.
Deciding to Decide
In order to streamline decisions then, it’s necessary to remove personal fears, company politics and help the team focus on the work. To do this, one of my favorite decision making frameworks is the DACI.
The DACI document also includes:
- The Decision Statement
- The Background
- The Pros/Cons table
- The due date of the decision
- A revisit date for the decision, if applicable
How does the DACI work?
In this framework, the Driver first makes a determination about how to decide. This is an important step that establishes an environment for objective decision making. First, the Driver assigns an Approver. Whereas a decision without an explicit Approver often defaults to the highest-ranked person in the room, this framework allows a deliberate assigning of the Approver. Thus, the best person to make the decision, usually someone closer to the problem, can be assigned. In some instances, multiple Approvers may be assigned on a decision. In this case an odd number of Approvers can prevent a deadlock and speed up the decision.
The Driver also writes up the DACI document and pulls in Contributors to add relevant information. The most important part of the DACI document is the Decision Statement. Sometimes this can take a while to write up properly. I’ve seen 3–4 re-writes on the Decision Statement itself. But by going through this process, the decision itself is clarified and properly scoped, which makes the decision making easier and the post-decision communication much much easier. Then the pros/cons table is created.
Finally, the Driver facilitates a discussion on the decision to make sure the Approver(s) have enough information at their disposal to make an informed and objective decision. Let’s see an example of a DACI write-up in this simple but illustrative decision scenario.
We’ve had many request for a dog-friendly workplace, we would like to evaluate whether we will allow it, and if so, how.
The DACI lays out the options clearly for the stakeholders to debate. As new considerations were brought up, such as adding a trial period, it was added as an option. By writing this up in an internal forum such as a Confluence page, Notion page, or other collaboration spaces, all employees can see the decision in progress, and we could collect input as the decision moved forward.
The final decision included additional layers on Option 2B, such as requiring obedience training and a 3-strike policy. So this DACI document is a living document that evolves as the discussion progresses. It also serves as an audit trail for future reference, which has come into use more times than I can count.
When should I use a DACI?
While not all decisions require a fully fledged DACI, critical decisions that span multiple teams can use a clear DACI.
I’ve used DACIs to decide pricing strategy, finalize website copy, debate marketplace policies, weigh the pros and cons of architecture options. I’ve used it to finalize branding details, and to choose a contracting agency to hire. I’ve used it so much that, even when I don’t write out the DACI, I run through a virtual DACI. In my head, I decide who should decide, by when to decide, I clarify my decision statement, and juggle an abbreviated pros/cons table. It’s useful for deciding on a company acquisition, or for couples buying a house. It is, without question, the most powerful tool in my product management, and life, toolbox.
What are the common pitfalls of a DACI?
Common pitfall #1: Using DACI to replace actual stakeholder management
I’ve seen DACI misused. The most important thing to remember is that:
A DACI does NOT replace the stakeholder management aspect of your decision shepherding process.
So keep those meetings you would otherwise have to talk things through with the right people. Have the 1:1 and group meetings that are necessary to align the team. The DACI shall not and will not replace any of that. What it does provide though is a framework, a way to document and standardize the process.
A DACI provides clarity to all stakeholders, transparency to the organization, and closure on the decision.
A DACI also allows you to trace past decisions and improve the organization’s decision making capability over time. But what it does not do is replace the work required to shepherd the decision to a meaningful close.
Common Pitfall #2: A culture that does not respect the DACI
A DACI requires a culture that respects its use. One of the main problems a DACI solves for is the unnecessary re-opening of decisions. This re-opening of past decisions causes a lot of thrash in an organization. A DACI solves this problem with decision finality. But for this to work, everyone involved in the decision must respect that when a final decision is taken and documented in the DACI, it stays that way barring either the “revisit date” on the DACI, or truly extenuating circumstances.
If this culture does not already exist, then introducing the use of a DACI often requires introducing the culture of respecting the DACI. Executive sponsorship is a must. Some organizations adapt nicely to this, some don’t. Keeping an eye on who is causing decision thrash, and re-training on the DACI concept over time helps the organization transition. It often takes 5–10 DACIs before the organization truly understands how to use the framework.
Have you used a DACI? How has your experience been implementing DACI at your organization? And what is your most powerful tool in your toolbox? Tell us in the comments!
Please 👏 this article. For further reading, check out:
Want more actionable tips on Product Management? Subscribe at: www.productmaestro.com/tips