The quality of your decisions is your most important output as a PM. Not the features you ship or the OKRs you write — the quality of the judgments you make under uncertainty, with incomplete information, while smart people disagree. Here's how to make those judgments better.
The most important product decision I ever made was also the most uncomfortable. We had a feature that had been in development for four months, was three weeks from launch, and that I had been championing internally for most of that time. Then new data came in that strongly suggested we were solving the wrong problem. The users we thought would love it weren't our future — a different segment was.
I killed the feature. After four months of development. Three weeks before launch. With the engineering team looking at me like I'd lost my mind.
It was the right call. And it was one of the hardest calls I've made — not because the analysis was hard, but because of the social and political cost of being wrong about something I'd been publicly confident about. The decision-making framework I needed wasn't RICE or a prioritization matrix. It was the courage to update beliefs when evidence changed — and the organizational credibility to execute the change without destroying team trust.
The Six Decision Types Every PM Faces
Before applying any framework, identify what type of decision you're making. Different types require different approaches.
Reversible vs. irreversible. Amazon's famous "two-way door" distinction. Reversible decisions should be made quickly, with less analysis, by whoever is closest to the situation. Irreversible decisions — architecture choices, pricing models, major product pivots — deserve more rigor, more stakeholders, and slower deliberation.
Tactical vs. strategic. Tactical decisions optimize within existing constraints. Strategic decisions change the constraints. Most PMs are better at tactical decisions and systematically under-invest in the mental energy required for strategic ones.
Data-rich vs. data-poor. When you have good data, use it. When you don't, be explicit about how much of your decision is evidence versus informed judgment. The danger is treating data-poor decisions as data-rich because some data — even poor-quality data — is available.
The Framework That Actually Works
Step 1: Name the actual decision in one sentence
Not the situation — the decision. "Should we build Feature X in Q2?" rather than "We're trying to figure out the onboarding problem." Naming the decision precisely focuses subsequent analysis and prevents scope creep.
Step 2: Identify who should be involved and why
Who has information relevant to this decision? Who will be affected by it? Who needs to feel heard to support the outcome? Involving the right people upfront is faster and less painful than making the decision alone and dealing with objections after.
Step 3: Generate at least three options
Most decisions get presented as binary: do this or don't. Forcing yourself to generate at least three options — usually: do it fully, do a reduced version, don't do it but do something else — produces better decisions. The third option is often the one nobody thought of and the one that turns out to be right.
Step 4: Make key assumptions explicit
For each option, what assumptions are you making? Which are you most uncertain about? Which, if wrong, would change your decision? This step is the one most teams skip — and it's where the most dangerous gaps in thinking hide.
Step 5: Decide, document, and set a review point
Make the decision. Write down what you decided, why, and what assumptions you're betting on. Set a date to review whether those assumptions proved correct. This practice, done consistently, is how PMs develop genuine judgment — by creating a feedback loop between predictions and reality.
Facing a high-stakes product decision?
The best decisions come from good process, not just good intuition. I work with product leaders to build decision quality at the team level. If you're navigating a significant decision or want to improve how your team makes them, let's talk.
Work with Yogesh →