Decision Making for Product People

Nobody hands you a manual for deciding. You get a title, a team waiting on an answer, and a nagging feeling that you’re guessing.

I once had to make an important decision about a technology direction for our product line. We brought together a small group of leaders, broke the work into tasks, and assigned owners. We shared our findings and met regularly to review. It all went well, and we made a decision.

We reported it to the executive team. They had questions and wanted to discuss, but they were on board. The challenge came when we communicated the decision to the rest of the team. We had skipped a few important steps, and that left us doing a lot of damage control and trust building.

That experience taught me a great deal about how to make decisions and, just as important, how to bring people together and communicate them. I skipped a few steps, and taking them would have saved us a lot of time. I could have brought all the managers together first to share the decision, how we got there, and why it mattered. Then I could have widened the circle to senior contributors and the adjacent team leaders we worked closely with.

The metaphor I think of is expanding the layers of the onion. We had a small working group at the center that had done the research and made the decision. I could have expanded outward from there, one layer at a time. Instead, I jumped to the outermost layer and created concern rather than agreement.

I’ve come to believe product work is mostly decision work. Roadmaps, specs and strategy docs are the paper trail; the decisions are the job. The good news is that deciding is a skill, which means you can get better at it on purpose.

Early on, most of us reach for prioritization frameworks, and they’re a fine place to start:

• MoSCoW sorts work into must have, should have, could have, and won’t have.
• RICE scores each idea on reach, impact, confidence and effort.
• ICE is RICE’s lighter cousin: impact, confidence and ease, scored quickly.
• Kano separates basic expectations, performance features and the delighters people didn’t know to ask for.
• Eisenhower splits tasks by urgent versus important.
• Value versus effort plots ideas on a simple grid so quick wins and money pits stand out.
• Opportunity scoring rates each customer need by how important it is and how well it’s served today. High importance with low satisfaction is where the opportunity is.

They’re useful for getting options onto the table and making trade-offs visible. But they rank things; they don’t decide for you. The numbers still rest on judgment calls about what matters, and that’s the part this post is about.

Most of us learn to decide by accident: we make a call, live with it, and quietly forget what we expected. That’s a slow way to learn. Three habits speed it up.

1. Write down the decision before you know the outcome. One paragraph: what you chose, why, what you expected, and what would change your mind. A decision journal sounds fussy until you reread it six months later.
2. Separate the decision from the result. A good call can turn out badly, and a sloppy one can get lucky. Judge the process first, or you’ll learn the wrong lessons.
3. Do the reviews. Pick a few past decisions each quarter and ask what you knew then, what you missed, and what you’d do again.

I coach a lot of founders and teams on decision-making skills. It’s a muscle that can be built, but it takes regular, intentional practice. I like to help my clients start a decision log or journal. It’s a simple technique that doesn’t take much time, and it becomes incredibly valuable when we reflect on it each quarter.

Having a coach to do the review with is extra helpful, because it sheds more light on patterns and the uncomfortable lessons that come with making decisions. It turns out we bring a lot of our baggage into our work. As the saying goes, “You can only take your organization as far as you take yourself.”

In a talk at the Lenny and Friends Summit, Google’s Robby Stein argued that when AI can help build almost anything, a PM’s real craft is judgment and taste. Above all, it’s decision making, and he admits plenty of decisions are wrong. I found that reassuring. Two of his stories are about improving what goes into a decision.

• Understand the job before you pick a solution. Shopping for a bed, his wife settled the matter by asking him to flop around on it. What she needed was a mattress that wouldn’t wake her when he moved. A roadmap of cooling and price would never have surfaced that.
• Ask why before you fix. The Instagram team asked people why they weren’t sharing in Stories. The top answer was worry about who would see it, and it took about two years of ideas before Close Friends worked. Reels in Brazil went the other way: the team assumed people wanted their posts to disappear, and had to reverse that after launch.

I’m a solutioneer by nature. I jump to solving before I understand the problem all the time. It’s both a superpower and a liability.

I remember when I was a VP of Product at an early-stage startup and we were building a complex interface for users to select regions and zones. We relied on a dataset from third parties. I spent hours and hours designing and thinking about how we would implement it. I hadn’t spoken to the architect. I was stuck in my own bubble, trying to productize this important feature.

One day, I arrived at the office and the issue had been solved in the simplest, easiest way. I had been picturing a convoluted process and interface because I didn’t quite understand the problem. I was overthinking it, and the actual solution was much simpler. Now, before I design anything, I talk to the people closest to the problem.

I’m wary of frameworks that need a whiteboard and an hour. These four are light enough to use in the middle of a Tuesday.

• One-way or two-way door. Can you walk back through it? If yes, decide fast and learn. If not, slow down. Most product decisions are two-way doors, and we treat them like one-way doors far too often.
• Who decides? Name one person before the discussion starts. Consensus feels kind but usually just delays the call and blurs who owns it. Once the call is made, share it in widening circles, starting with the people closest to the work and moving outward, so each group hears it from someone they trust before it reaches the next.
• Pre-mortem. Imagine it’s a year out and the decision failed. Write down why. The risks you list are the ones worth checking before you commit.
• What would change my mind? State the evidence that would reverse the decision, then go look for it. If nothing could change your mind, you’ve already decided and the analysis is theater.

Of everything on this list, I’m especially fond of the pre-mortem. It’s another simple tool in my product toolkit, and it should take less than an hour. I like to write mine by hand on paper. Something about pen to paper gets me thinking more creatively than typing on a screen.

One of the last times I used it, we were evaluating a strategic partnership. The partner would provide a key integration at a critical point for users. That integration had been causing our customers a ton of errors and generating a lot of support tickets, and the partnership was key to solving it. I wrote down everything I could think of for how it might fail: the partner went out of business, raised prices, changed technologies, or became unreachable. Those questions alone shaped how we designed the integration and the agreement, and they gave us ample flexibility.

None of these tools makes the decision for you. What they do is slow you down in the right places. Asking which kind of door you’re facing tells you how careful to be, naming a decider keeps the call from drifting, a pre-mortem surfaces the risks, and asking what would change your mind keeps you honest.

The real skill is matching the effort to the stakes. Spend your care where a mistake is expensive or permanent, and move quickly everywhere else.

A few rules of thumb I lean on:

• Set a deadline for the decision itself. Work expands to fill the time you give it, and so does worry.
• Gather information until you’re about 70% sure. Waiting for 90% usually means you’re late. Waiting for 100% means you never decide.
• Ask what a day of delay costs. Sometimes it’s nothing. Sometimes a team is blocked, and that cost is real even though no dashboard shows it.
• Make the reversible calls small. Ship a smaller version, test it, and let reality do some of the deciding.

In the AI era, building has gotten cheap, which makes the deciding part matter more. When almost anything can be built, the hard question is what’s worth building.

Books on my shelf

These are the ones on my bookshelf I’d point you to first. It’s not surprising to me that three of these recommendations are from Annie Duke.

• Thinking in Bets by Annie Duke: A good result doesn’t prove a choice was wise. To learn, go back to what you could have known at the time.
• How to Decide by Annie Duke: Writing down what I believed before the outcome gives me a more honest way to learn from it.
• Thinking, Fast and Slow by Daniel Kahneman: Confidence doesn’t guarantee accuracy. Pausing helps me notice when I’ve answered an easier question than the one in front of me.
• Creating Great Choices by Roger L. Martin and Jennifer Riel: For when neither side of an either-or decision feels right. It asks what matters in each option and whether you can build a better one.
• Quit by Annie Duke: Decide in advance what would make you stop, before emotions and investment are running high.
• Empowered by Marty Cagan: Asking a team to own a result means giving them room to make decisions and the support to make good ones.
• The Intentional Organization by Mathias Meyer and me: We wrote it about meetings, feedback, delegation, trust, and leading teams. Values matter when they show up in everyday decisions and behavior.

Pick one decision you’re facing and answer three questions in writing: is it a one-way or two-way door, who decides, and what would change my mind? Then set a date and make the call. You’ll learn more from one decision made on purpose than from ten you drifted into.