I wrote down my decision-making process for the first time. Here's the version I use, with the research behind it.
I recently spent four days at the University of Georgia in a course on organizational behavior. One module was on decision making, and I left with a desire to write down and document my actual decision-making process.
I make a lot of decisions. I run a company with Kenny, lead a software product called Alignify, work with clients, and help manage a venture fund. Some weeks the job is mostly deciding things.
If you'd asked, I would have described some instinct and process, but I never really took the time to think through and document how I make decisions.
So here's what I wrote. It borrows heavily from people who have studied this far more carefully than I have, and I'll name them as I go.
Sort First: Pencil or Pen
Most decisions don't need the full process. So the first step is deciding which kind I'm facing.
A pencil decision is reversible, cheap, and unlikely to affect a partnership, someone's role, or a major commitment. I decide within a day, log it in Notion, and move on.
A pen decision is significant, hard to reverse, or costly to unwind. It usually touches a partnership, a person's role, or a big commitment. Those get the full process below, and the output is a short decision memo.
This simple sorting step is pretty intuitive, but it helps me identify the bigger things that need a more deliberate approach.
1. Identify the Choice
The first job is to define the decision and how I'll choose, before I look at any evidence.
I write the issue as one sentence, then keep asking why it's a problem until I reach the root instead of a symptom. “We need a new marketing hire” often turns out to be “nobody owns the pipeline,” which has more than one option.
Then I set the criteria. I borrowed this split from Kepner-Tregoe decision analysis. Musts are pass/fail and eliminate options immediately. Wants get weighed against each other. Setting these before gathering evidence is the point. If I look at the options first, I'll build criteria around the one I already like.
I try to list every real option, including doing nothing and waiting. Chip and Dan Heath's book Decisive makes the case that many bad decisions start as “whether or not” questions with only one option on the table. Adding even one more option improves the odds.
Finally, I name who makes the final call, who has to agree, and who gives input. I also write down what I don't know and set a decide-by date.
2. Gather Evidence
The job here is to find the facts that separate the options, not the facts that make me feel good about one.
The book The Mom Test and Itamar Gilad's Evidence Guided workshop have influenced me here. And there's a fantastic book titled How Big Things Get Done that drove this home for me.
So an evidence sweep is a big part of the process. I try to look for things that cut against my current leaning and prioritize action over ideas. Opinions are cheap and usually generous.
Daniel Kahneman and Bent Flyvbjerg call this reference class forecasting: before estimating how my project will go, ask how efforts like this usually turn out, for other people and for me in the past.
3. Challenge My Reasoning
Now I look for the ways my view could be wrong. There are all these biases that we all have, so I try to work through the most relevant ones. Here are a few:
- What you see is all there is. What information are we missing, and what story are we filling in?
- Anchoring. What was the first number or idea on the table, and would we land here without it?
- Confirmation bias. Did we look as hard for evidence against as for it?
- Availability bias. Are we weighing something because it's recent or vivid rather than relevant?
- Ambiguity aversion. Are we dismissing an option because it's unfamiliar?
- Affect. Do we simply like or dislike this, and are feelings doing the reasoning?
- Optimism bias. Are we planning on the best case instead of the realistic one? I'm really guilty of this one in planning.
Sometimes, a premortem helps. Assume it's a year from now and the decision went badly. Write down why. It's surprising how easily the reasons come once you give yourself permission to imagine failure.
Last, I try to get some distance. I set the decision down for at least a day, then ask what I'd tell a friend in the same spot. The Heaths recommend this question, and it works because we're usually wiser about other people's problems than our own.
4. Consult the Right People
Most of the time, the decision affects other people. So I often put a summary in front of someone who has no stake in the outcome and ask them to find a hole in it.
Approval is easy to get and tells me very little. Scrutiny is harder to ask for and much more useful.
For anything inside Stackhouse, Kenny and I both have to agree. For bigger bets, I also take it to a small mastermind group of peers I've trusted for years.
5. Decide and Assign Action
Now it's time to make the call. And there are two things here.
First, tradeoffs. Because saying yes to something is usually saying no to other things, I try to be honest about that.
Second, tripwires. This is my favorite part of the process, because it's where you look at specific signals and dates and decide now what will happen then. If you're climbing Mount Everest with a guide, they will make sure you reach a certain point by a certain time or you'll go back. This is a tripwire, and it's predetermined.
A while back, we wanted to launch a second product, and we said we would do it when the first product got 1,000 paying subscribers. That was a tripwire, and a motivator.
Then it's time to act. Decided is not done.
6. Review
Annie Duke points out the common mistake of “resulting,” judging a decision by how it turned out. Good decisions sometimes get bad outcomes, and bad decisions sometimes get lucky. So a review of a written decision is the last step in the process.
A Toolkit for Specific Decisions
Some decision types come up often enough that I keep extra tools for them. I only add a new category after I've run a real decision of that type through the process.
Product and market bets. I check desirability, viability, and feasibility separately, since most failed products were strong on one and weak on another. I talk to customers about what they did the last time they had the problem and what they paid, which is the core of Rob Fitzpatrick's The Mom Test. I rate the evidence using Itamar Gilad's Confidence Meter, where my own conviction sits at the bottom and customer behavior sits near the top. If the evidence is weak and the decision can wait, I run a cheap test first and match the cost of the test to the size of the decision.
Portfolio calls. When deciding whether to keep, kill, or pivot something, I break the original thesis into parts: problem, audience, mechanism, timing, and economics. I mark each one as still true, partially true, or no longer true. I ask whether we're learning or just enduring. And I ask the sunk cost question plainly: if I were starting fresh today, would I fund this? The best version sets kill criteria before they're needed, with a milestone, a date, and a consequence agreed in advance.
People decisions. I use the same structured questions for every candidate and score the answers before comparing people. I ask references what the person did in specific situations rather than what they're like. For an existing role, I ask whether I would hire this person for this role again today. And I check whether what's best for one person is overriding what's best for the team, which is a trap I'm wired to fall into.
Write Yours Down
Your process doesn't need to look like mine. Start with the sorting step, since that alone will change how you spend your time. Then take the next pen decision on your plate, write the one-sentence version of the problem, and set your criteria before you look at a single option.
A process that lives only in your head is a habit. Writing it down is what lets you check it.
