If you are going to be making a hard, important decision, then a more formal process can help you navigate to the best answer. The DECIDE framework is a powerful way to execute that process. Equally importantly it can make sure that you’ve got buy-in for that decision with the right people. Leading everyone through a predefined process makes it clear how you’re going to decide, the timeline for the decision, and who will be involved. Documenting the decision at the same time forces people to be crisp on their reasoning, and allows anyone to get up to speed quickly on what was decided and why.
One such decision making framework for important decisions is DECIDE, which follows six steps to get you to a high quality answer:
- D | Define problem
- E | Evaluate criteria
- C | Create options
- I | Identify solution
- D | Decide and commit
- E | Engage and execute
This decision making template gives you a step-by-step guide to taking difficult decisions in a thorough and collaborative way.
When to use the DECIDE framework
Using the DECIDE framework for decision making can take significant time, and therefore isn’t appropriate for most decisions. When a decision is easily reversible, or relatively unimportant then it’s more important to decide quickly than be 100% right. Most decisions are like this and often called “Type 2” decisions or two-way doors: if you don’t like the destination, you can return to where you came from. For them you are better off using High Velocity Decision Making techniques.
Of course, some decisions are Type 1, or irreversible decisions. If you don’t like the destination, you cannot easily go back through these one-way doors to where you’ve come from. Take for example launching in a new market, changing your business model, or doing a major SaaS integration. In these cases, decisions should only be made after considerable research and debate, to ensure that the chosen path is the correct one.
Benefits of using the DECIDE framework
When used appropriately, the DECIDE framework has a number of benefits:
One of the biggest sources of tension in organizations as they grow is who gets involved in which decisions. Being excluded from a decision, or not being empowered enough to make one that you feel you should be able to, are incredibly frustrating. Often the pain is caused more by the process being unclear, than by who is actually involved. If a sensible process is declared up front, then people find it much easier to understand why they may have been excluded. They can also see the thought and effort that’s gone into a decision, and will be reassured by this.
The DECIDE framework forces you to provide the context for your decision, gather input from a diverse range of opinions, create options and evaluate them against a sensible criteria. When you use it to make a decision then you know you’ve done your homework, and aren’t cutting corners. Explicitly touching base with other people also makes sure you get feedback throughout the process. Whilst this doesn’t guarantee a perfect answer, it vastly increases your chances of making a high quality decision, and one where other people would make the same decision if they were the decider.
The DECIDE framework is a written document that acts as a single source of truth for all the inputs and people involved in a decision. That means people can read through, understand the decision being made, and follow the line of reasoning that led to the answer. Decisions can be reviewed further down the line, once the outcome starts to become apparent. This makes every decision an opportunity to improve your process and judgment for next time.
Applying the DECIDE framework
Whilst the DECIDE framework is fairly easy to follow on its own, the following guide gives more context on why it’s designed the way it is.
The first step to DECIDE is to clearly define the problem that you’re trying to solve. A good problem statement provides the context and boundaries that mean everyone is aligned on why the decision needs to be made, and what the objectives of taking the decision are. It’s common to include:
- Summary – a single line statement of the problem.
- Context – an explanation of why you need to make a decision, why the outcome is important, and the research and analysis that will affect it.
- Scope and constraints – an explicit statement of what the problem includes (e.g. customer segments, geographies, feature sets) and any boundaries you need to work within (e.g. investment, timeline for implementation).
- Success measures – how you will know that success has been achieved. This should be an objective measure and ideally quantified in a metric.
- Timeline – the date by which the decision must be made. This can help avoid “analysis paralysis”.
- Stakeholders – who needs to be involved in the decision making process.
Key Roles For Decision Making
Including the right people is critical to both getting the right answer to the decision, but also making sure the decision sticks once it is made. You’ll want to include as few people as possible to prevent your decision getting bogged down in bureaucracy and groupthink, but you’ll need to include diverse perspectives and representatives from key groups that will be affected by your decision.
Once you’ve identified who should be involved, you need to map the role they will play in the decision making process. There are plenty of frameworks for this, of which RACI is one of the most common:
- R | Responsible – the person driving the decision making process. Often you as the product manager.
- A | Accountable – the person with the authority to make the final decision. This could be you, but is often someone senior for big decisions. This should always be a single person.
- C | Consulted – everyone who has a say in the decision. You have a two-way dialogue with them, where you actively seek and incorporate their feedback. Not everyone in this group needs to be treated equally – there may be some “big C’s” and “little c’s”.
- I | Informed – everyone who is interested and affected by the decision, but who doesn’t get a say in it. These people should be in the loop on the decision making process, but you have a one-way dialogue with them, and don’t need to seek their input.
Something to note here is that having a single person accountable has two massive benefits on decision making:
- Ownership – With a single decision maker, there’s immediate accountability around the decision. They are personally on the line for its outcome, and as a result will drive a much higher bar for the quality of decision. Consensus-based decision making can feel good, but can lead to everyone ducking ownership if things go wrong.
- Speed – A single decision maker accelerates action, because you can proceed without unanimous buy-in. It’s rare that you need everyone to come to the same conclusion – most people are happy to “disagree and commit”, as long as they feel they’ve had input into the decision.
It’s best to identify how you will evaluate potential solutions before you come up with the solutions themselves. This allows you to think through the criteria that are really important to solving the problem, rather than creating criteria that justify a solution you already have in mind.
Not all criteria need to be weighted equally, and if this is the case you should make this clear now. You want to avoid the fallacy of false equivalence, where people are resisting an option because it doesn’t deliver on one or two minor criteria that aren’t really important.
In practice, this means having about four levels:
- Fundamental principles – 1-2 overarching principles that guide our decision. Cut across many important decisions for the company. If these distinguish between options, then almost nothing else matters. If two or more guiding principles appear to be in conflict then you need to resolve that before you can decide anything else.
- Major criteria – The most important criteria for deciding when fundamental principles don’t discriminate between options. These will be specific to this decision. Most decisions come down to differences here. Try to keep this list as short as possible.
- Minor criteria – Other factors that are useful to understand, but not important enough to influence the decision. Park things here to make sure people feel heard and have a complete picture of the options, whilst acknowledging that these things are unlikely to sway the final result.
- Risks to avoid – Pitfalls you want to avoid. This is most useful as a check on the criteria you have selected. For example, security or uptime might not be the headline factor in choosing a CRM system, but if you realize these are very real risks that you need to avoid, then you favor options which have these covered.
“All models are wrong, but some are useful” – George Box
When you’re thinking about how to assess different options, you need to consider whether there’s any way to quantify the impact each will have. How you define impact will depend on what is in your problem definition. For example, if you are selecting a CRM vendor, then estimating their ongoing cost is obviously a critical input you’ll want to include.
This leads to better decisions for two reasons:
- Improved understanding of the problem – as you think through how to model the impact, you’ll improve and stress test your understanding of what the key drivers of impact are. This always leads to most robust thinking throughout the process
- Forced objectivity – options that look similar in qualitative terms might be obviously different when you quantify them. For example, if you’re choosing between two features, it’s easy to overlook the fact that one will only have 10% the reach of the other if you don’t model things out.
That said, the future is uncertain, and modelling is an imperfect science. Quantified impact should always be taken as one of several inputs to the decision, and rarely be used in isolation. Models are great at giving you directionally correct answers (Option A has twice the impact of Option B), but incapable of distinguishing between very similar outcomes (Option A is 5% better than Option B).
When the outcomes are similar then the margin of error in the inputs will be bigger than the results given. You need to be especially careful of this in businesses that pride themselves on being data-driven, where the faux-precision of a model can hide the uncertainty surrounding the assumptions driving it.
A decision is by definition choosing from options. If you don’t have options, there’s no decision to be made – just a path to follow, however difficult. You’ll also quickly run into two issues with stakeholders:
- Criticism that you haven’t been thorough – can you really have put that much thought into the alternatives if there aren’t any? Have you added inaction and continuing the status quo as a possibility?
- It prevents people from giving input – if there are no alternatives, then it doesn’t matter what feedback people have, because it has no bearing on the outcome. This is very disempowering, and can easily lead to people silently resisting the decision later.
A good way to develop options is to seek external references for inspiration, and then brainstorm alternatives with other people, while explicitly banishing criticism to a later session. This way ideas are “hot-housed” and can develop a little to see if there’s any merit in them before being weeded out. Nothing kills creativity faster than someone shooting down ideas as soon as they are voiced.
It’s now time to make a decision. You might use either or both of the following steps as the final input before making a call:
- Recommendation – the responsible individuals driving the decision making process present their recommendation to the accountable person
- Private feedback – the accountable person asks for input from consulted stakeholders
This often happens when a team has done a lot of the legwork on the research so far, but the authority to make the decision has been elevated to someone more senior to check their homework. In this case, the responsible individuals will present the DECIDE framework, outlining what their preferred option is and why.
Decision makers often like to consult others to get different perspectives before they commit to an option. Ideally everyone runs through the options and criteria together to make sure everyone has the same fact base, and then submit their feedback to the decider. This can be done as a public discussion to encourage consensus and transparency, or can be done in private so individuals don’t influence each other, and prevent giving the impression that it is a democratic vote. Which is the right course will depend on the decision at hand, the individuals involved and company norms.
In either case, the accountable person doesn’t have to follow the recommendation, or the consensus of the stakeholders they have consulted. But they now have all the information they need to take a fully informed decision.
Once they decide, the accountable person should be very clear about what decision they have made, and why. Both of these things should be written down, as this will:
- Leave no room for ambiguity – having got this far, you need to make sure that there’s no ambiguity on the final decision. Writing it down means that no one can misinterpret what has been decided. It’s shocking how often unwritten decisions need to be revisited because people aren’t clear on what was actually decided.
- Straighten out messaging – big decisions need to be announced to the organization, and distilling down why a decision was made is groundwork for doing these comms.
- Create audit trail – if the decision was a tough one, then it’s useful to capture the arguments that won the day. When the decision is looked at in the future, you want an accurate record of how the decision was made. This gives you an opportunity to improve your process and judgment for future decisions.
With the path forward clear, you need to make sure that key stakeholders are committed to the decision and act to support it. If you’ve done the work upfront aligning everyone and understanding their views, then this should go (relatively!) smoothly. Even if people don’t agree with the decision, they should be able to see the merits of it and firmly commit.
However, be on the lookout for unaddressed dissent or a lukewarm reception. At this stage decisions aren’t blocked explicitly, but by key people failing to commit time, effort and resources to making it work. Ever had someone agree in principle, but then never seem to have time to do their bit? The root cause is that you didn’t secure a genuine commitment from them.
A good technique to prevent decisions being silently throttled in this way is to get critical stakeholders to publicly commit to supporting them. This can be as simple as getting all the consulted people together, and going round the room with everyone verbally confirming they will support the decision – even if they “disagree and commit”. You can also get people to explicitly confirm their commitment in a document, like the commitment table in the DECIDE framework template. Either way, people are much more likely to follow through on their commitments when they are made explicitly and publicly.
Engage and execute
With the decision made, and key people committed to supporting it, it’s time to broadcast the decision and act.
Broadcasting the decision is important so that everyone beyond the inner circle involved in taking the decision knows that a decision has been made, and what it is. The decision should always be communicated by the person accountable for it, to reinforce their ownership of the decision and the outcome that follows.
Again, the format will depend on the company and decision at hand, but with if you’ve captured the process in the DECIDE framework template up to this point you’ve got everything you need. Write a quick email with the decision and key reasons for it, and include the link to the DECIDE framework document. Everyone will benefit from transparency on how the decision was made.
And as with any course of action, determining what needs to be done, by which person, and in what timeframe is critical. Make sure this is captured in writing, and set a date to check in on the actions to make sure people actually deliver on them.
Important, irreversible decisions should be made after careful consideration of what the problem is that you’re trying to solve, research into the available options, and thoughtful debate amongst the key people involved. The DECIDE framework provides you with an off-the-shelf process to guide you through these sorts of decisions, and give you the best chances of both getting the best answer, but also generating buy-in to the decision along the way.
Hustle Badger Resources
Hustle Badger Resources on Amazon
What are the best frameworks for product decisions and strategy?
The DECIDE framework is an excellent framework for making difficult decisions that require significant research and thought. The framework covers the following steps:
D | Define problem
E | Evaluate criteria
C | Create options
I | Identify solution
D | Declare commitment
E | Engage and execute
This framework is a step-by-step process to help you make an informed decision, and generate buy-in with stakeholders along the way.
How do you make hard decisions in startups?
To make hard decisions in startups, it’s useful to agree on a decision making process such as the DECIDE framework. Agreeing on a framework up front has three main benefits. Firstly, it helps ensure that you make a good decision by taking the time to evaluate options thoroughly. Secondly, it helps get buy-in with stakeholders by making sure the process is transparent and they have opportunities to provide input. Finally, it provides a written record of why a decision was made, allowing people to check back on the lines of reasoning and learn from them once the outcomes of the decision become clear.
How do you create alignment on start up decisions and strategy?
To create alignment on decisions and strategy, it’s helpful to define the process you will use to make a decision up front. That way people can input into the process itself, as well as the decisions that will be made with it. Providing a transparent process, and then giving people updates on how the decision making is going, means that their feedback can be incorporated at an appropriate point, and they are more likely to agree with the final decision.
What decisions do product managers make?
Product managers make decisions on defining, developing and marketing a product. They help a cross functional product team decide which user problems to solve in order to create business value, and then systematically reduce risk as the team works on those problems. As a result, product managers make decisions on a variety of strategic and tactical issues, from choosing where the team should focus, to which features the team should build, and how those features are rolled out.
How do product managers make decisions?
Product managers make decisions by gathering information, weighing the alternatives and seeing what course of action makes the most sense. Information may come from quantitative data on user behavior (i.e. how users are using the product currently), qualitative insights from speaking to users, researching competitors and speaking to experts and stakeholders.