The hard part of product management is the backlog you reject
Every roadmap becomes a prioritisation problem where sales, design, engineering, and leadership all have defensible asks. Scoring frameworks help by forcing better arguments, not by producing answers.
Every roadmap turns into a prioritisation problem, and every request arriving at it is defensible.
Sales wants the feature blocking a deal that closes this quarter. Design wants to fix the flow that tests badly. Engineering wants to pay down the debt slowing every subsequent change. Leadership wants the thing that moves the growth number. Customers want all of it, sooner.
None of them are wrong. The failure is attempting to satisfy everyone, which produces a roadmap with no shape and a team that ships continuously without changing the position of the product.
What a framework actually does
I use five dimensions:
| Dimension | Question | |---|---| | Customer value | Does this solve a problem users have, at a size worth solving? | | Business impact | Which metric moves, and by roughly how much? | | Strategic alignment | Does this support where the product is going in eighteen months? | | Effort | What is the true engineering cost including maintenance? | | Confidence | How certain are we, and what would raise that? |
RICE, ICE, MoSCoW, and WSJF all encode versions of this. Pick one and stay with it.
Their value is not that they produce the right answer. Scores are estimates and estimates carry the bias of whoever made them. A determined stakeholder can move a RICE score by adjusting reach.
What a framework does is force the argument into the open. When someone wants a feature prioritised, they now have to say which dimension justifies it. That converts "I feel strongly about this" into "I believe reach is higher than you scored it," which is a claim the group can examine.
The framework produces better arguments. You still make the decision.
Rejection as the deliverable
The output nobody celebrates is the list of things you decided not to build and can explain. That list protects the team from relitigating the same request every quarter, and it tells everyone what the product is not.
Product management is not building more. It is building the right thing at the right time, which means most of what lands in the backlog stays there permanently, and someone has to be comfortable saying so.
Related reading
- Product managementVolume is not evidenceThe most confident voice in a product review steers decisions it should not. Quiet team members often hold better information, and that is a product risk rather than a culture complaint.
- Product managementUsers tell you what hurts, not what is missingThe largest product opportunities do not arrive as customer requests. They come from watching what users work around and never think to mention.
- AI engineeringAI made execution cheap. Judgement did not get cheaper.Building an autonomous agent took days instead of months. Deciding which tasks deserved automation took far longer, and that gap is not closing.