Short answer
A prioritization decision holds when it is written down: what gets built, which problem it solves, what is set aside, and what has to be true in two months for the decision to have been right. One page per decision is enough, read aloud at the next review.
Most backlogs are lists of everything anyone has ever asked for. Such a list can be sorted forever, because it lacks the thing that makes sorting meaningful: what you are trying to achieve this quarter.
Start with what has to be true in three months
A goal phrased as a state makes prioritization easy. "A new customer gets going on their own" is something every proposal can be held against, and most of them fall away in ten seconds. A goal phrased as an activity does none of that work, because activities can always be justified.
Three questions that separate proposals
Ask them in order, and the third does the most work. A proposal that costs nothing to postpone can be postponed, however loudly it is being asked for.
- Which problem does it solve, for whom, and how often does it occur?
- What do we become more certain about once it is built?
- What does it cost to postpone for three months?
Write the decision on one page
A decision made only in a meeting gets renegotiated the next time someone is annoyed. One page with the date, the choice, the alternatives that were on the table and what has to be true in two months means the next discussion starts where the last one ended. It is the same principle as an architecture decision record: the reasoning outlives whoever wrote it.
Redo the priorities every two weeks
Two weeks is tight enough to catch a change and loose enough to finish something. The goal itself is reviewed each quarter. A decision that turns out wrong after four weeks is cheap to change as long as the reasoning behind it is written down.
What usually goes wrong
The list becomes a wish list, the largest customer gets the final word, and anything hard to estimate is deferred until it turns urgent. In our experience all three are symptoms of the same thing: a goal nobody on the team can quote from memory.
Common questions
- How often should we redo our priorities?
- Every two weeks works for most teams. More often makes it hard to finish anything, and less often means reality has moved on between sessions.
- What do we do with everything that never gets built?
- Delete it. A backlog of 300 items is a list nobody reads. Anything genuinely important comes back on its own, usually within a few weeks and with a better argument.
- Who should own prioritization?
- One person, who listens widely and decides alone. Group prioritization produces lists where everything is second most important, and then the order is set by whoever argues longest.
- How do we handle a large customer demanding a feature?
- Write down what the customer is trying to achieve, how many others have the same problem, and what the build costs. There is often a smaller solution covering both, and it only becomes visible once the need is stated.
- Do we need estimates in hours?
- Rarely. A rough size in days, weeks or months is enough to choose between two proposals. Precise estimates cost time to produce and still miss on exactly the parts that are uncertain.
- When is a roadmap worth having?
- When it describes problems in time order. A list of features with dates becomes a promise you have to explain away; a list of problems survives reality changing.
Tell us what you want to build
Thirty minutes, free of charge, and a straight answer on whether we are the right studio for it.