Most prioritization frameworks are a form of cope.
When the Backlog Fight Is Actually a Strategy Fight
Endless backlog debates are usually not prioritization failures, they are the visible symptom of a product strategy that was never written down or never agreed upon. The PM's job is not to facilitate better prioritization debates; it is to make the debate unnecessary.
The meeting everyone has been in
The sprint review ends. Someone raises the item that was deprioritized last cycle. The debate restarts. Someone pulls up the scoring spreadsheet. Fifteen minutes later, the same four items are ranked in a slightly different order and nothing has been decided about the ones that matter.
This is not a prioritization problem. This is what a missing strategy looks like when it surfaces through the backlog.
What the fight is actually about
When a team debates the backlog in circles, the debate is almost never about the items themselves. It is about the underlying question that has never been answered out loud: who are we building this for, and what does winning look like for them?
Here is a fast diagnostic. Stop the next backlog debate and ask the room to answer this in sixty seconds: "Who is the single user type we are optimizing for right now?" If the room cannot agree in sixty seconds, the team does not have a strategy. They have a collection of beliefs that have never been reconciled.
The prioritization fight is just those beliefs colliding in public.
Split-screen
Team A uses an Impact, Confidence, Ease scoring model. Every sprint, the PM sends the spreadsheet around. Stakeholders update their cells. The scores are averaged. The highest-ranked item goes to the top.
Three sprints later, the product manager from the growth team challenges the score on a conversion feature. The engineering lead argues that the technical debt item was scored too low on ease. The head of customer success says the enterprise feature has higher strategic value than the number reflects.
The meeting runs over. The scores get adjusted. The same four items are on the list next sprint.
Team B had a similar fight eight months ago, about whether to build deeper reporting for power users or a simpler onboarding flow for new signups. It lasted three weeks. It was uncomfortable. It ended when the CPO said, in writing, "We are building for the power user for the next two quarters. New user acquisition is not a priority we are optimizing features for right now."
Since then, Team B has disagreed on specifics, timeline, sequencing, technical approach. But the backlog argument has not happened again. The filter is agreed. The debate was front-loaded, and execution has been clean.
The difference between these two teams is not the framework. It is whether a decision was ever made.
The Notion example
Notion spent years being described as everything: a notes app, a wiki, a project manager, a database. For a period, internal and external conversations about what to build next suffered from the same noise that affects any product that has not committed to a lane.
The shift came when the team committed to a specific positioning: the all-in-one workspace. Not a notes app with database features. Not a project management tool with a wiki. One product that replaced the fragmented stack of Slack messages, Confluence pages, Jira boards, and Google Docs.
That commitment changed the shape of every product decision that followed. A feature that made Notion more of a specialist tool, better for one thing, less connected to everything else, became easy to decline. A feature that made Notion more of everything, more connected, more flexible, got built. The filter was not a scoring model. The filter was the strategic position.
The team could still disagree on execution specifics. But the backlog fight, the one about what direction to go, stopped being a recurring meeting. It had already been resolved by the commitment.
Why frameworks make this worse
Most prioritization frameworks are a form of cope. That is the uncomfortable position, and it is worth sitting with.
When a team does not have an agreed strategy, scoring frameworks do not resolve the disagreement, they launder it. Each stakeholder's strategic belief gets embedded into their scores. The averaging process creates a false appearance of rigor. The output looks like a rational priority list. What it actually is: a snapshot of the current power dynamics in the room, expressed in numbers.
Adding a better framework to this situation makes it worse, not better. Now the team is arguing about the framework, too.
The signal that you are in this situation is not that the framework is failing. It is that the framework results keep getting challenged. If a scoring model's output is frequently overridden, questioned, or re-run with adjusted inputs, the team is not using the framework, they are using the framework to continue having the argument they have not resolved.
How to diagnose: strategy vacuum versus real disagreement
These are not the same problem, and treating them the same way fails both.
| Signal | Strategy Vacuum | Genuine Prioritization Disagreement |
|---|---|---|
| "Who are we building for?" | Room cannot agree in 60 seconds | Room agrees; debate is about what serves them best |
| Debate frequency | Same argument, different sprint | New argument, different evidence |
| What gets challenged | The conclusion, "this should not be top priority" | The data, "I think the effort estimate is off" |
| What fixes it | A bounded strategy decision, documented and signed off | Better evidence, a prototype, or a tiebreaker call |
| Framework behavior | Framework outputs get overridden or re-scored regularly | Framework outputs are accepted; debate is pre-scoring |
| How long it has been happening | Multiple quarters, no resolution | One to two cycles, new topic each time |
If the diagnostic points to a strategy vacuum, running another prioritization session is exactly the wrong response. You are holding a meeting about the symptom while the cause sits unaddressed.
How to surface the missing strategy without making it personal
This is the move most PMs avoid because it feels like calling leadership out. Done badly, it is. Done correctly, it names a structural gap rather than a human failure.
The setup is simple. In the next meeting where the backlog argument restarts, name the pattern before the debate goes further.
"We keep revisiting this item because we have not yet agreed on who we are building for in this cycle. That is not a process failure, it is a decision we have not made. I want to propose that we stop the backlog session and instead spend one hour deciding that question. Once we have it, the backlog sorts itself."
This works for two reasons. First, it reframes the problem from "we disagree about priorities" to "we have not made the upstream decision that makes priorities clear." Second, it gives everyone in the room, including whoever has been resisting a direction, a face-saving way to participate in making the call rather than defending a position.
The output of that session needs to be written down. Not in a slide. In a document, reviewed by everyone present, with names and dates. Strategy that lives in someone's head is not strategy, it is an opinion waiting to be contradicted.
The cost of skipping this
Every sprint the backlog fight happens, there is a tax. Engineering time is allocated to the wrong thing. Design produces work that gets deprioritized before it ships. Customer success surfaces requests that get scored but never acted on. The team learns that the process does not produce stable outcomes, so they stop trusting it.
The longer this runs, the more the team stops engaging seriously with prioritization at all. They show up to the meeting, they put in the numbers, and they wait to see what actually gets decided in the hallway conversation after.
That erosion is real and it compounds. A team that has lost faith in the prioritization process is very expensive to restore, because the trust problem is now layered on top of the strategy problem.
Judgment turn
The PM's job is not to facilitate better prioritization debates. It is to make the debate unnecessary.
If the framework is still needed every sprint to resolve the same question, the strategy is still missing. The framework is not a substitute for the decision, it is a workaround for not having made it.
This is what makes the prioritization-as-process instinct so expensive. It feels productive. The meeting has a structure. The spreadsheet has numbers. Something is happening. But the actual problem, leadership has not committed to a direction, is being obscured by the activity.
The Notion team did not get to clean product execution by finding a better scoring model. They got there by committing, explicitly and publicly, to what the product was. Everything else followed from that.
The question for any PM in a recurring backlog fight is not "how do we run this process better?" It is: "what decision are we avoiding, and who needs to make it?"
Key takeaways
- Recurring backlog debates are almost always a symptom of an absent or unagreed product strategy, not a prioritization process failure.
- The fastest diagnostic: ask the room "who are we building for right now?", inability to answer in sixty seconds confirms a strategy vacuum.
- Prioritization frameworks embed unresolved strategic beliefs into numbers, creating the appearance of rigor without resolving the underlying disagreement.
- The fix is a bounded, documented strategy decision, not a better-facilitated scoring session.
- Surface the missing strategy by naming the pattern as a structural gap, not a personal failure, and proposing a one-time upstream decision session.
Related articles
- The Trap of the Neutral Roadmap, Why Every Prioritization Is a Bet
- How to Tell a Vision From a Wish List
PM Code publishes frameworks-free product judgment for PMs operating at the hard edges of their role.