The Product Leader's Approach to Decision Frameworks

I made A LOT of product decisions last quarter - it was Q4 2025, fun time. But you know what? I can’t remember the reasoning behind 90% of them. Not because they were not important, but because I had no framework for making or recording them.

Turns out, good decisions aren’t just about making the right call. They’re about being able to explain why you made that call six months later.

Why Most Teams Struggle With Decisions

I was a PM in a company where every product decision took forever. Feature prioritisation debates lasted three meetings. Technical architecture discussions went in circles. Nobody could pull the trigger because nobody wanted to be wrong.

The problem wasn’t that we lacked smart people or good data. We lacked a shared framework for how decisions get made. So every decision became a new negotiation about process, not just about the choice itself.

What we did? One smart guy suggested we should build a simple decision framework. The result was a short document that answered: What types of decisions exist? Who makes them? What information is required? How do we handle disagreement?

Decision-making improved immediately. Not because the framework was brilliant, but because everyone agreed on how decisions work.

What a smart guy. Saved thousands of EUR monthly with one framework. Be that guy at your company.

Building Early Foundations

What to Prioritize: Types of Decisions

First the obvious (or maybe not that obvious): not all decisions are equal. Treat them the same and you’ll either move too slow (over-thinking reversible choices) or too fast (under-thinking irreversible ones).

The framework I use: I borrowed from Jeff Bezos - Type 1 (irreversible, high-consequence) versus Type 2 (reversible, lower stakes).

Type 1 decisions at a startup:

• Hiring senior leaders (expensive to undo)
• Technical architecture for core systems (costly to change)
• Pricing model (affects all customers, hard to reverse)
• Target market positioning (changes your entire GTM motion)

Type 2 decisions:

• Feature prioritization (can always reprioritize)
• UI changes (can test and revert)
• Marketing messaging (iterate quickly)
• Process improvements (try and adjust)

We treated feature decisions like Type 1 that required extensive analysis, stakeholder alignment, business cases. Slowed us to a crawl.

We changed our approach: Default features to Type 2, so we ship, measure, iterate. The heavy process was reserved for actual irreversible decisions.

Quick Wins: Decision Recording That Actually Works

Made a decision? Write it down. Sounds obvious. Nobody does it.

The format that works:

• Date
• Decision (one sentence)
• Context (why now, what problem)
• Options considered (what we didn’t choose and why)
• Who made it (DRI)
• Success criteria (how we’ll know if it was right)

Five minutes per decision. Six months later when someone asks “why did we build it this way?”, you’ll find the answer quickly.

How? Keep a decision log in Notion, Confluence or anything else that’s accessible. Every significant product decision should get an entry. When new people join, they could read the log and understand product strategy evolution. It is a massive onboarding value.

Scaling for Growth

When to Formalise Decision Rights

Early stage, the founder makes everything. Works until about 10 people, then becomes a bottleneck.

The signal you need formal decision rights: when the founder becomes the constraint on decisions getting made.

At one small startup, where I was a PM, every product decision still went through the CEO. She was thoughtful, but she was in back-to-back meetings all day. Decision latency went from hours to days to weeks.

We had to formalise decision rights:

• Product features: PM decides, gets input from engineering and design, CEO has veto right (rarely used)
• Pricing changes: CEO decides, gets input from product and sales
• Technical architecture: Engineering lead decides, gets input from product
• Hiring: Hiring manager decides, CEO has veto on senior roles

Velocity improved because decisions had clear owners. CEO stayed involved on things that mattered, delegated the rest. Truth be told it wasn’t easy to implement.

Team Evolution: From Consensus to Conviction

Early teams love consensus. Everyone gets a voice, all opinions matter, decisions feel collaborative.

Then you hit dozens of people and consensus becomes impossible. Too many stakeholders, too many opinions, too much time spent in meetings trying to get everyone aligned.

The shift: From consensus (everyone agrees) to conviction (DRI makes the call after gathering input).

• Input is required, consensus is not
• DRI must seek input from relevant stakeholders
• DRI makes final call and documents reasoning
• Team commits to the decision even if they disagreed

First month will be rough. People will feel unheard. By month three, it will click. Decisions will happen faster. Wrong decisions should start the reasoning review - you learn, and you move on.

The Startup Reality

Resource Constraints: Decision-Making Under Pressure

Startups want to make perfect decisions. But reality is they have time and resources for good enough decisions.

The trap is spending three weeks analyzing a decision that needs two days of thought. Analysis paralysis, anyone?

The forcing function: Time-box decision making based on reversibility.

Type 2 decisions get 2 days maximum. Gather essential input, make the call, move on. If it’s wrong, you’ll know quickly and can adjust.

Type 1 decisions get 2 weeks maximum. More analysis justified, but still bounded. Diminishing returns kick in fast.

Speed vs Quality: The Decision-Making Tradeoff

Fast decisions with 70% confidence versus slow decisions with 90% confidence. In startups, the 70% decision made today usually beats the 90% decision made next month.

There is science and math behind this: if you’re wrong 30% of the time but moving 3x faster, you learn faster and course-correct faster than teams that are right more often but move slower.

Important note: This only works if you’re actually learning from wrong decisions. If you make fast decisions and never review them, you’re just making mistakes efficiently.

• What did we decide?
• What was the outcome?
• What did we learn?
• Would we make the same decision again?

Say that about 65% of fast decisions are right, 20% are wrong but easily corrected, 15% are wrong and costly.

The 15% costly mistakes are worth it because the 85% good-or-correctable decisions that moved you faster than competitors who aim for 95% accuracy.

Key Takeaways

Right, let’s make this practical:

• Distinguish Type 1 from Type 2 decisions - Irreversible decisions need more rigor. Reversible decisions need speed. Don’t treat them the same.
• Record decisions in a shared log - Five minutes per decision. Include context, options considered, success criteria. Your future self will thank you.
• Formalize decision rights as you scale - Clear DRIs for different decision types. Seek input, make calls, move on. Consensus doesn’t scale.
• Time-box decision-making based on reversibility - Type 2 decisions: 2 days max. Type 1 decisions: 2 weeks max. Bounded analysis beats analysis paralysis.
• Default to speed with 70% confidence - Fast wrong decisions you can learn from beat slow right decisions that miss the market window.
• Review decisions quarterly - What worked? What didn’t? What did we learn? Build institutional decision-making capability.

Final Thoughts

The best product leaders I’ve worked with aren’t the ones who make perfect decisions. They’re the ones who make good decisions quickly, learn from them systematically, and get better at decision-making over time.

Your decision framework should feel lightweight, not bureaucratic. If it slows you down, it’s wrong. If it speeds you up by creating clarity, it’s right.

Start this week: Pick one decision you’re currently stuck on. Is it Type 1 or Type 2? If it’s Type 2, set a 2-day deadline and make the call. If it’s Type 1, identify what information would move you from 60% to 75% confidence and go get it.

Decision-making is a skill. Like any skill, you get better through deliberate practice and systematic reflection.

Have questions or thoughts? Get in touch - I’d love to hear from you!