How to Make Product Decisions That Actually Stick

The real reason decisions get relitigated

It's rarely disagreement about the priorities themselves. Most product teams I've worked with have a rough shared sense of what matters. The problem is that nobody can point to anything. There's no document, no trail, no artifact that says: we chose this, for these reasons, and this person made the call.

When a new stakeholder joins a meeting, or a senior leader asks a question, or the market shifts slightly, the decision is back on the table. Not because the original decision was wrong. Because it was never properly closed.

This is the uncomfortable truth about most product organisations: they treat prioritisation as a recurring event rather than a system. Every quarter the same inputs, the same debate, the same outcome that evaporates before the next planning cycle.

What decision infrastructure actually looks like

Good product decision making requires three things, and none of them are a scoring model.

First, explicit decision rights. Who has the final call on this type of decision? Not "who should be consulted" but who actually closes it. I've worked with teams where this was genuinely unclear at the CPO level. The result was that every significant prioritisation decision stayed open until the CEO weighed in, because nobody else felt authorised to close it. That's not a prioritisation problem. That's an organisational design problem.

Second, documented criteria. What signals matter when we make this trade-off? Speed to market even over completeness? Retention even over acquisition? These need to be written down before the decision, not reverse-engineered after. Without pre-agreed criteria, every decision becomes a negotiation about what criteria to use, and the strongest voice in the room wins. This connects directly to the [product strategy framework that sticks](/blog/product-strategy-framework-that-sticks), if your strategy isn't concrete enough to filter decisions, it isn't doing its job.

Third, a lightweight audit trail. Not a 40-page decision log that nobody maintains. A single shared place where each significant decision is recorded with the date, the rationale, and the name of who made the call. One paragraph is enough. The purpose is not documentation for its own sake. It's so that when someone re-opens the discussion in six weeks, you can point to something.

Why DACI and RACI aren't enough

These frameworks are useful. I'm not dismissing them. But they solve the wrong layer of the problem. DACI tells you who is Driver, Approver, Contributor, and Informed. RACI tells you who is Responsible, Accountable, Consulted, and Informed. What neither tells you is how the decision actually gets made, or what a good decision looks like in this context.

You can run a perfect DACI and still come out of the meeting with three people who think they made the call and no record of what criteria were used. The infrastructure layer sits underneath the process layer. You need both.

The AI problem nobody is talking about yet

This is becoming more urgent now that AI tools are generating prioritisation suggestions. I've written about [why AI roadmap features don't actually improve prioritisation](/blog/ai-roadmap-prioritization-why-it-doesnt-work), and the same issue shows up here. When an AI tool surfaces a ranked backlog or a suggested roadmap, teams that lack pre-agreed criteria have no shared basis to evaluate it. The AI output just becomes the new thing to argue about. The debate moves from "what should we build" to "should we trust this recommendation" and the result is the same: no decision that sticks.

If you have documented criteria, AI suggestions become a useful input. If you don't, they add noise to an already noisy conversation.

What the CPO actually owns here

The CPO's job is not to make every product decision. It's to design the system that makes good decisions repeatable. That means being explicit about decision rights across the team, making the criteria legible enough that a PM two levels down can use them without escalating, and maintaining enough of an audit trail that the organisation can learn from past calls.

Start small. Pick one recurring decision type that keeps resurfacing in your team. Write down who closes it, what criteria apply, and where the record lives. Then do it again.

The decisions won't stop being hard. But they'll stop being the same ones twice.