Decision Making

The key is not to prioritize what's on your schedule, but to schedule your priorities.

Stephen Covey

The core job

Product management is about making decisions. Not all decisions, and not alone, but the Product Director sits at the intersection of business, technology, and design, where trade-offs must be resolved and paths must be chosen.

Who makes product decisions? Is it the product manager, the product team, or the stakeholders? There are debates on this question, but they miss the point. What matters is that decisions get made, actions get taken, and results get achieved. The Product Director's job is to create an environment where this happens consistently.

Why is decision making so hard? When there is a choice between something fantastic and something poor, you do not need to think about it. If the choice is obvious, there is no decision to make. Real decisions arise when you must choose between alternatives that are equally good or equally bad. Two features that both seem valuable. Two candidates who both seem qualified. Two strategies that both seem plausible. The difficulty is not in recognizing the right answer. The difficulty is that there is no obviously right answer.

This chapter offers tools to make these hard decisions more systematically: product principles that pre-decide categories of choices, frameworks that structure prioritization, and approaches to the genuinely difficult trade-offs that no framework can resolve.

Product principles

The most important thing is that you develop your own principles and ideally write them down, especially if you are working with others.

Ray Dalio

What are product principles?

"Move fast and break things." Facebook's original motto was more than a tagline. It was a product principle. It meant that when speed and stability conflicted, speed won. Given that Facebook was growing at breakneck pace, this seems counterintuitive. Any downtime would cause lost revenue and unhappy users. But Zuckerberg believed speed was so important that he enshrined it in the culture. The employee handbook reinforced this relentlessly, with phrases like "The Quick shall inherit the Earth."

Product principles are a value system for your product. They are a hierarchy of values that influence decisions before those decisions arise. When a principle exists, you do not need to debate the trade-off each time. The principle has already settled it.

How to create good principles

Keep them short and simple. A good principle is easy to understand and remember. It must convey a powerful message in a few words. If you need a paragraph to explain it, it is not a principle.

A good principle settles a conflict. There is an old adage in technology that you can have cost, quality, or speed, but not all three. When Zuckerberg created "move fast and break things," he was deliberately choosing speed over stability. A good principle has a winner and a loser. It resolves conflicts before they become debates.

The opposite should also be a valid principle. Des Traynor from Intercom makes this test clear: if no reasonable company would adopt the opposite, it is not a useful principle. "Build good software" and "don't ship bugs" are bad principles because no one would choose the opposite. But "move slow and build things safely" is a legitimate choice. I have worked for large telecommunications companies where exactly that principle guided decisions. Both are valid; they simply lead to different products.

Keep the list small. When everything is important, nothing is important. The temptation is to enumerate every value that matters. Resist it. A short list forces you to make choices, which is the entire point.

Intercom's R&D principles

Intercom is a model of clear product thinking. They publish their R&D principles openly:

Start with the problem. Begin by deeply understanding the problem you are solving. Continually evolve this understanding, and persistently return to it to ensure you have not veered off course.

Think big, start small. Think ambitiously, but know that big things have small beginnings. Always try to find the smallest coherent solution. Starting small enables you to ship sooner.

Ship to learn. The sooner you ship, the sooner you get feedback on your assumptions and your solution. Shipping is the beginning, not the end.

Notice how each principle settles a conflict. "Start with the problem" chooses problem-focus over solution-focus. "Think big, start small" resolves the tension between ambition and pragmatism. "Ship to learn" prioritizes learning over perfection.

Prioritization frameworks

If you ask product managers what they find hardest about their job, prioritization is always on the list. Prioritizing requests, features, stories, initiatives. The backlog is infinite; the resources are finite. How do you choose?

Several frameworks exist to structure this problem. None of them work perfectly, but each provides a useful lens.

RICE

RICE scores initiatives on four dimensions:

Reach. How many customers will this affect in a given time period? A feature used by everyone scores higher than a feature used by a niche segment.

Impact. How much will this move the needle for each customer reached? A transformative improvement scores higher than a minor enhancement.

Confidence. How certain are you about your estimates of reach and impact? A well-researched initiative scores higher than a speculative bet.

Effort. How much time and resources will this require? Lower effort scores higher.

The RICE score is calculated as (Reach × Impact × Confidence) / Effort. Higher scores indicate better opportunities relative to their cost.

RICE works well when you have reasonably good data on reach and impact. It struggles when comparing fundamentally different types of work, like a new feature versus paying down technical debt.

MoSCoW

MoSCoW categorizes work into four buckets:

Must have. Without this, the product does not work or the release cannot ship. Regulatory compliance, critical bugs, core functionality.

Should have. Important but not critical. The product works without it, but it is significantly diminished.

Could have. Nice to have if time permits. Valuable but not essential.

Won't have. Explicitly out of scope for this cycle. Listing these is as important as listing what you will do.

MoSCoW works well for release planning and scope management. It forces clear conversations about what is truly essential versus what merely feels urgent.

The Kano Model

The Kano Model classifies features by how they affect customer satisfaction:

Basic features. Customers expect these. Their presence does not delight, but their absence causes frustration. A hotel room must have a bed and running water. These are table stakes.

Performance features. More is better. Faster load times, more storage, longer battery life. Customers notice and appreciate improvements along these dimensions.

Delighters. Unexpected features that create disproportionate satisfaction. Customers did not know they wanted this until they experienced it. A handwritten welcome note in the hotel room. A clever shortcut in the software.

The Kano Model helps you balance your portfolio. You need enough basic features to meet expectations, enough performance improvements to stay competitive, and enough delighters to differentiate.

Value versus Effort Matrix

The simplest framework plots initiatives on two axes: value delivered and effort required. This creates four quadrants:

High value, low effort. Do these first. They are your quick wins.

High value, high effort. Plan these carefully. They are your major projects.

Low value, low effort. Do these if you have spare capacity. They are your fill-in work.

Low value, high effort. Avoid these. They are your traps.

The value-effort matrix works well for initial screening and for communicating trade-offs to stakeholders. It struggles with precision, since both value and effort are often uncertain.

When frameworks fail

The deeper problem with prioritization is that we are often comparing apples to oranges. How do you weigh a feature that increases conversion rate against a compliance project required by regulators? One has measurable revenue impact. The other has no upside but catastrophic downside if ignored.

How do you compare a feature that improves NPS against a feature that generates revenue? One measures satisfaction. The other measures money. They are not on the same scale.

How do you compare building a feature your competitors have against exploring a risky innovation that could define your future? One is predictable execution. The other is uncertain but potentially transformative.

No framework resolves these tensions. This is where principles matter. This is where judgment matters. This is where the hard decisions live.

The hard decisions

Reversible versus irreversible

Jeff Bezos distinguishes between two types of decisions. Type 1 decisions are irreversible or nearly so. They are one-way doors. If you walk through and do not like what you see, you cannot go back. Type 2 decisions are reversible. They are two-way doors. You can walk through, look around, and return if needed.

The mistake most organizations make is treating all decisions like Type 1. They apply heavy process, extensive analysis, and broad consensus to decisions that could easily be reversed. This slows everything down.

The correct approach is to move fast on Type 2 decisions. Make them quickly, learn from the results, and adjust. Reserve the heavy process for Type 1 decisions, where the stakes justify the investment.

As a Product Director, one of your jobs is to correctly classify decisions and ensure your team applies the right level of rigor to each type.

Decision velocity

Speed of decision making is itself a competitive advantage. A company that makes ten decisions per week, with 70% accuracy, will outperform a company that makes two decisions per week with 90% accuracy. The faster company learns more, iterates more, and compounds its advantages.

This does not mean being reckless. It means being appropriately fast. It means not waiting for perfect information when good-enough information is available. It means setting deadlines for decisions and honoring them.

Amazon uses a "disagree and commit" principle. Once a decision is made, everyone commits to executing it fully, even those who disagreed. This allows the organization to move fast without requiring consensus. You can voice your concerns, but once the decision is made, you execute as if it were your own idea.

When there is no good option

Sometimes you face decisions where every option is bad. Cut the feature that customers love, or miss the deadline. Lay off the team member who is underperforming, or let the team suffer. Raise prices and lose customers, or keep prices and lose money.

These decisions cannot be optimized. They can only be made. The Product Director's job is to make them clearly, communicate them honestly, and own the consequences. Avoiding the decision is itself a decision, usually the worst one.

AI as decision support

AI is changing how decisions get made. It can process more information, model more scenarios, and surface more options than any human. Used well, it makes Product Directors more effective. Used poorly, it becomes a crutch that obscures accountability.

What AI does well

Synthesizing information. AI can read every customer support ticket, every user interview transcript, every competitor announcement, and surface patterns that would take humans weeks to find.

Modeling scenarios. AI can simulate the impact of different choices, showing how changes might affect metrics under various assumptions. This makes trade-offs more concrete.

Generating options. AI can brainstorm alternatives that humans might not consider, expanding the solution space before you narrow it down.

Reducing uncertainty. When AI provides data synthesis and scenario modeling, some decisions that felt hard become easier. The uncertainty that made them difficult has been reduced.

What AI cannot do

Accountability. AI can recommend, but it cannot be accountable. When the decision goes wrong, a human must own the consequences. This means a human must make the final call.

Values. AI can optimize for metrics you specify, but it cannot tell you which metrics matter. Choosing between revenue and customer satisfaction is a values question that humans must answer.

Stakeholder alignment. Decisions in organizations are not just about finding the right answer. They are about building commitment to execute. AI cannot sit in the room, read the politics, and craft the message that brings people along.

Judgment in uncertainty. When the data is sparse and the stakes are high, AI confidence scores mean little. Human judgment, built from experience and intuition, remains essential.

The right balance

Use AI to prepare for decisions: gathering information, modeling options, stress-testing assumptions. Make the decision yourself, as a human accountable for the outcome. This division keeps the benefits of AI assistance while preserving the human judgment that complex decisions require.

Closing thoughts

Decision quality compounds over time. Good decisions lead to better positioning, which leads to better options, which leads to better decisions. Poor decisions accumulate too, constraining future choices and requiring costly corrections.

Your job as a Product Director is to build systems that improve your hit rate. Principles that pre-decide common trade-offs. Frameworks that structure prioritization. Processes that match rigor to stakes. And the judgment to know when the frameworks do not apply and the decision is yours alone to make.