When I started at Luxury Presence, the first thing I noticed was the velocity of decision making. The product team struggled to get feedback and buy-in from all their stakeholders—and ultimately finalize a decision. The lack of clear decision-making structure slowed down every part of the process.
, along with a centralized repository for decisions made at the company. The results speak for themselves; 90% of decisions now get made asynchronously, and we easily gain clear commitment from stakeholders.
Below you can see the intro page to our decision doc that explains five myths of decision making and how to mitigate them. And in the following pages, you can try out the same decision structure that we use.
The Decision Owner should have the most context, so they are responsible for writing a proposal. The proposal might not be perfect, but it will be a good starting point.
3. Stakeholder mapping
🚫 Myth: All stakeholders should have a chance to chime in on a decision.
✅ Truth: Not all stakeholders are equally impacted by a decision. The Decision Owner needs to do the research to identify different levels of stakeholders:
Advice. Which stakeholders would you like advice from? These stakeholders are useful in refining a draft proposal. They can help identify gaps, concerns to be mitigated, and/or clarifications that are needed. These advisors might be involved in committing to the final decision, but their role right now is just to improve the proposal.
Commitment. Which stakeholders needs to commit to making this decision successful? These stakeholders are going to have to allocate time or resources to help make this proposal successful. They might not agree with the proposal, but you still need them to commit (more on that later).
Inform. Which stakeholders do you just need to inform? These stakeholders just need to know what was decided, why it was decided, and how it impacts them.
4. Soliciting clarifying questions & reactions
🚫 Myth: It is good to ask for all types of “feedback”.
✅ Truth: Asking for generic feedback can get messy. Be as specific as you can be. Craft your requests to fit the level of each stakeholder.
Ask if there is anything unclear in the proposal or how the proposal can be improved.
Before getting reactions, ask if there is anything unclear in the proposal. Then, get reactions fromevery stakeholder that needs to commit.
Make sure everyone understands the proposal before they react. If someone with a lot of authority has a knee-jerk reaction to a proposal it could influence everyone else.
by hiding the Agree? and Commit? columns from the table while stakeholders ask all their clarifying questions. Then, show those two columns when you’re ready for stakeholders to react.
Don’t let a single person be the only voice. Make sure everyone voices their reaction (verbally or written async)
Just make sure they understand the decision after it is made. Clarifying questions and reactions will likely prompt some good suggestions to improve the proposal. The Decision Owner can choose to evolve the decision to respond to questions and reactions.
5. (Dis)agree & commit
🚫 Myth: All stakeholders need to agree.
✅ Truth: Not every stakeholder has to agree that this is the best proposal possible to be able to commit to try to make it successful. Disagreement is often a good thing.
After all stakeholders who need to commit have asked clarifying questions and voiced a reaction, the Decision Owner will decide if the proposal is ready for commitment.
Each committing stakeholder should be thinking: “Is this safe to try?”
The Decision Owner will ask each committing stakeholder if they can commit to this decision. Each stakeholder should say (or write):
“I agree and commit to this decision” or
“I disagree but commit to this decision” or
“I cannot commit because I believe this is not safe to try”
Commitment is binding
If you disagree but commit, it is expected that you will not try to revisit the decision and remake your argument. The decision is over.
If new information comes in and a new decision needs to be made, a Decision Owner should be identified and the process should repeat.