How CPO Zac Hays makes fast decisions without meetings

icon picker
How CPO Zac Hays makes fast decisions without meetings

A proven structure for product and company decision making.
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.
So we created a , 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.
Copy Luxury Presence’s to make faster decisions with your own team.
Copy template

The 5 Myths of Decision Making

Decision-making in organizations is hard.
There are lots of stakeholders.
The final decision-maker is unclear.
Often there is no clear right answer, so instead, you try to make a choice everyone can feel good about.
So what should we do about it? In our experience, if we want faster decisions and clearer stakeholder commitment, then we have to confront and mitigate the myths around decision-making. Here’s how:

1. The “Decision Owner”

🚫 Myth: The person with the most authority should be the decision-maker.
✅ Truth: The Decision Owner drives the process of making a decision. The Decision Owner is one person who:
Has context on the problem and solution options
Will be accountable for driving the success of the decision
Has the bandwidth to drive the decision to a close

2. The Proposal

🚫 Myth: Giving people choices is good for making decisions.
✅ Truth: Making choices between different options is often hard. Usually all choices have pros and cons and evaluating all the pros and cons and be mentally taxing (see ).
However, reacting to a specific proposal is easy.
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 from every 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.
Tactically, you can do this in the 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.

Getting commitment

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.

Ready to make faster decisions?

Copy the , write your proposal, then send it to your stakeholders.
Copy template

I’d love to hear how your team makes fast decisions! Drop feedback on and let me know what you think.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.