Backlog management is not product strategy. Backlog management sequences and slices work you already believe is worth doing. Product strategy decides which customer problems to solve, which business outcome to move, and what to stop doing. A well-groomed backlog can still be the wrong work if nobody has made those strategy calls.
A tidy backlog can still be the wrong work
Teams celebrate refined stories, estimate accuracy, and a groomed sprint. Then they ship for months without knowing whether anything mattered.
Backlog management is not product strategy. It is how you sequence work you already believe is worth doing.
The pathology
Marty Cagan’s CSPO pathology names the pattern: people trained mainly in Product Owner rituals treat backlog administration as the whole product job. Process becomes a proxy for product skill.
Melissa Perri’s build trap, as summarized by Martin Eriksson for Mind the Product, describes teams that maximize the amount of software shipped instead of the value exchanged with customers. Feature ideas plus code are treated as if they equal profit. Agile helps you build; it does not decide what to build.
John Cutler on outcomes over outputs presses the same first principle: the point of changing how teams work is better outcomes, not prettier process.
Strategy answers different questions
Strategy and discovery ask:
- Which customer problems are we uniquely positioned to solve?
- What business outcome are we trying to move?
- What will we stop doing?
- What evidence would kill this bet cheaply?
Backlog management asks:
- Is this item ready enough to build?
- What order reduces waste given current constraints?
- How do we slice for a usable increment?
Both matter. Only one decides whether you are in the build trap.
How backlog admin masquerades as strategy
- The roadmap is a feature laundry list with dates.
- “Discovery” is a stakeholder interview that ends in a ticket.
- Success is velocity or burn-down, not a changed customer behavior.
- Saying “I don’t know” is career risk, so the backlog stays full.
Perri’s framing is useful here: process, strategy, and culture all have to support learning. A perfect Scrum board inside a culture that rewards output will still optimize for output.
What to do instead
Protect time for discovery the way you protect sprint capacity. Write the outcome next to the item, not only the story. Review what shipped against what changed. Kill work that did not learn enough to justify the next slice.
We already argued that research should come before another screen. A backlog of polished mocks is still a backlog of assumptions.
Sentral’s consulting often starts by separating the unofficial feature factory from the few jobs that actually move the week. Custom software is what you build after that cut, not instead of it.
If your strategy meeting is a grooming meeting, talk to us.
Frequently asked questions
Is backlog management useless?
No. Unready work wastes engineering. It just is not strategy.
How do I know we are in the build trap?
You can list what you shipped and struggle to name what improved for customers or the business.
Who owns strategy if the PO owns the backlog?
Whoever owns value. On a healthy team that is the same person. If it is not, you have a split that usually produces a proxy.
What metric replaces velocity?
Outcome measures tied to the problem you claimed to solve. Velocity can still help capacity planning. It cannot prove value.