The Power of the Decision Doc

The decision doc is one of the most useful techniques in my product management toolbox. I can give many examples of when decision docs came in handy, and probably just as many of when I wished I had created one.

What is a decision doc?

A decision doc documents a decision, sure. In reality, though, it does a little more. When faced with a challenge or a difficult decision to make, it can lead you and your organization through the entire decision-making process, highlighting and documenting the necessary steps.

What structure can it have?

This is my preferred decision doc structure:

Title: The question that we are trying to answer. Nothing else.

• Should we sunset feature X?
• Which of the vendors should we choose?
• Which subscription tier should include feature Y?

Background and Context: A transparent explanation of why we need to make the decision. What do we know so far? What impact will it have? Is it urgent?

Stakeholders: A list of all people (or entities) that are affected by the decision or can impact it in any way.

Meeting dates and attendees: Enumerate all meetings related to this decision-making process, both planned and past.

Deadline to make the decision, if there is one.

Options:

I like to create a table with the following rows for all considered options:

• Reference number or name of the option
• Description
• Pros of selecting this option
• Risks or cons of selecting this option

I am aware that some people included in the decision-making process find it odd that for each option not only the pros, but also the cons or risks are called out. Aren’t the pros of one option the cons of another? In my experience, this is not always the case, especially when there are more than two options. Additionally, this explicit call-out often makes people consider things from a different angle, allowing them to spot consequences that could otherwise go unnoticed.

Open questions: Missing pieces of data that can hopefully be filled before the decision is made.

Final decision: Which option has been selected, with any follow-up steps.

Note: Many tools, including Atlassian Confluence, offer decision doc templates.

How is it created?

In a healthy organizational structure, there should always be one final decision-maker. For anything related to the product, it should, obviously, be the Product Manager. Regardless of whether you do or do not have the power as a PM, you should still make the effort to facilitate decision-making and include the right stakeholders. It might be useful to identify the RACI chart position of the stakeholders — who is Responsible, who is Accountable, who should be Consulted, and who only Informed — but make sure to consider the consequences of making the chart public.

When I am starting to work on a complex decision, I start with a document that is only visible to me. I describe the context, enumerate the options I can think of on my own, then try to think of any pros and cons.

In the next stage, I consult. I usually set up a number of 1:1 meetings with the stakeholders who are easy to reach for me to capture their knowledge and feedback, and to prepare them for any upcoming meetings and questions. After this phase, when I am happy with the shape and contents of the doc, I usually set up the decision-making meeting. In the invite, I ask the audience to familiarise themselves with the document before the meeting.

I moderate the decision-making meeting. I explain why we are meeting, and explain the options. If there are stakeholders invested enough to want to speak up, I let them express their opinions and frustrations. I am mindful of the time, but I try not to interrupt them (and do not let anyone else do it as this is not yet the discussion phase). I have discovered that it is important for people to feel that their position has been heard. It makes it so much more likely that in the end, if another option wins, they will be able to disagree and commit.

After walking through the options, and having heard everybody’s feedback, I present the option that seems to be leading and open it up for discussion. Is it good enough? What negative consequences does it have? What would need to change for more people to accept it?

Sometimes new, better options arise in the meeting.

At the end we vote —even if in the end the decision belongs to one person and this outcome can only be treated as a suggestion. If we are unable to agree within the allocated timespan, I might set up a follow-up meeting — but only if new information can be brought to it through clearly defined action items or questions. Otherwise we need to make the best call in the time we have.

Why would you use one?

One reason to create decision docs is transparency. It is important and good for the organizational culture to explain who the final decision maker is, what options were discussed, and why a particular one has been selected. Decision docs facilitate knowledge sharing, and may even help avoid accusations of favoritism in trickier situations (like vendor selection). However, I draw a clear line between explaining the rationale behind decisions, and explaining yourself. Sometimes there are people who will always suspect foul play, and it is not the PM’s job to cater to their way of thinking.

Another reason to have decision docs is documenting alignment and buy-in. Sometimes stakeholders will forget that they participated in a meeting, sometimes the personnel changes and the new person does not have the full context. The decision doc can then protect the org (or an engineering team) from delays resulting from revisiting already established decisions.

Finally, decision docs save resources that could be spent on repeated research. Especially in a bigger organisation, the same question can be asked for the second time, and the third, perhaps by a different person or at a different moment in time. Why have we chosen this framework? Wasn’t the other one supposed to perform this operation faster? Did we know about Z when making the call? When options and their consequences are documented, just sending a link to the doc can save hours of “new” research leading to the same conclusion.

Misconceptions about decision docs

Misconception 1: the decision is absolutely final and cannot be revisited.

When I say that the decision doc protects you and the org from going through the same decision process one more time (when someone challenges the decision or encounters the same problem) it does not mean that the decision can never change. It can — but for this to happen, new data has to surface. It might be a change in client behavior, a new framework in the market, a new regulation.

The last one actually happened to me a short while ago — we decided to stop storing a piece of data because it was problematic to pass between systems and unnecessary. Two days after signing off on the decision, I was contacted by an expert in payments standards who notified me this was now obligatory to keep in the system. This, by the way, shows how important it is to identify and include relevant stakeholders in the conversation.

Misconception 2: you do not have ownership if you need decision docs.

As mentioned above, in a healthy org it is understood who is the owner or decision maker in each domain. So, why would you need decision docs if you can just make the call yourself? Does it not make you look weak? Well, I don’t think so. I believe a good leader is transparent, well-informed, efficient, and driven by data. And so is a good decision doc :)