Ranking a backlog doesn't decide what to build next. It just sorts whatever's already been written down. The actual decision happens earlier: get clear on the customer, the outcome, the journey, and the evidence, then use a one-page decision brief to force the trade-offs into the open. Do that first. Ranking becomes the easy part.
Why the backlog can't decide for you
A backlog is a memory aid, not a priority queue. It records everything anyone has ever asked for, with no built-in relationship to your strategy. Treating it as the source of truth quietly assumes the best next move is already sitting in the list, waiting to be ranked and found.
That assumption is usually wrong. The most valuable move this quarter might be to remove something, to talk to a segment you're not yet serving, or to strengthen the core for customers you already have. None of those arrive as a well-formed ticket. A backlog rewards what's easy to write down, not what matters most.
In Build the Right Thing, Haja J Deen makes the same point from a different angle: iteration without a guiding vision produces confidence in the wrong direction. Lean and Agile only work on clear foundations. Speed applied to an unexamined list just gets you to the wrong place faster.
That's not a theoretical risk. Pendo's 2019 Feature Adoption Report, built from usage data across 615 live product subscriptions, found that 80 percent of features in the average software product are rarely or never used. Ranking a backlog well doesn't fix that. It just makes the wrong things move faster.
What do you need to know before you compare backlog items?
Four things, in this order. Skipping any of them turns comparison into guesswork dressed up as rigor.
- Customer. Which specific segment, and which real person, is this for? Not an average user. An actual customer whose problem you could describe in their own words.
- Outcome. What change in that customer's world are you trying to cause? "Ship feature X" isn't an outcome. "Cut the time a new admin needs to invite their team from days to minutes" is.
- Journey. Where in the customer's current path does the problem actually bite, and what would the ideal path look like instead? Mapping that gap is where most real priorities come from, not the backlog.
- Evidence. What do you actually know, and how solid is it? One loud call is weak evidence for a broad change. A pattern across calls, tickets, and behaviour is a different thing entirely.
Once those four are clear, a feature request stops being a thing to build and becomes a candidate answer to a well-formed question. Now you can judge it on whether it moves the outcome, for that customer, along that journey. That's a different exercise than ranking effort against impact on a spreadsheet.
What's a decision brief, and why use one instead of a backlog ranking?
A decision brief is a one-page artifact that forces the trade-offs behind a "what should we build" call into the open, before anyone starts estimating story points. Here's the version worth copying as-is:
| Field | What goes here |
|---|---|
| Customer | The specific segment and a real person it's for. |
| Desired outcome | The change in the customer's world you're trying to cause, stated as an outcome, not an output. |
| Evidence | The signals behind this call: calls, tickets, behaviour, market data, and how reliable each one actually is. |
| Alternatives considered | The other moves you looked at, including "do nothing" and "stop something else." |
| Confidence | How sure you are, honestly, and what would raise that confidence. |
| Cost of delay | What it costs to not do this now versus next quarter. |
| Stop condition | The signal that would tell you this was the wrong call, so you'd actually reverse it. |
Most teams skip the last two fields, and that's exactly where the brief earns its keep. Cost of delay stops "important" and "urgent" from quietly blurring into the same thing. Stop condition is the honesty check: if you can't name what would prove you wrong, you're not making a decision. You're placing a bet you'll never settle.
Does moving faster actually help if the direction is wrong?
No, and this is where most teams lose the quarter without noticing. Picture two paths.
Path A starts at the backlog and accelerates: rank, build, ship, discover it missed the point, rework. Velocity looks great on a dashboard. Direction is unmanaged.
Path B starts slower: purpose, then customer and journey, then evidence, then the decision, and only then building. It takes longer to get moving and reaches an actual outcome instead of a shipped output nobody asked for.
The point isn't to slow down permanently. It's that a few minutes of clarity at the front changes what "fast" is even pointing at. Modern tooling, AI included, has made the building phase of Path A dramatically cheaper. That's exactly why the deciding phase now carries more of the weight than it used to. Cheap execution doesn't fix a bad decision. It just gets you to the wrong outcome on a shorter timeline.
Where this fits in a weekly rhythm
A single decision brief is one thing. Running this every week without it turning into a ritual of theatre, a form filled out and ignored, is a separate problem. That's the territory of a few connected pieces in this series:
- Turning a week of scattered evidence into a small set of defensible moves in a Monday product briefing.
- What to do when your calls, tickets, and analytics disagree, and which signal should actually win.
- Making "don't build this" a real strategic move instead of an accident of neglect.
- Why a feedback repository, no matter how well organised, is not a decision system on its own.
If you're building this habit into your own process, start with the brief above on the next request that lands in your inbox. Fill in all seven fields before you let anyone estimate it. The gaps you can't fill are usually the most useful part.
If you'd rather see this play out with a real team and real evidence than build the habit cold, that's what a FlightPath Sprint is for: get the decision right, then ship the first working version in weeks, not quarters.
This article adapts frameworks from Build the Right Thing by Haja J Deen, reinterpreted here for post-seed B2B SaaS teams.
