BACKLOG / PRIORITIES / DECISIONS
Why a backlog is not a strategy
Reconnect the task queue to customers and the chosen direction: priority rationale, decision records and checking results after release.
The backlog has 186 tasks. Each has a description, an estimate and a priority. Every two weeks the team carefully moves cards to the right. Three months later there are more features, but it is still hard to explain why these particular features were supposed to improve the product’s position.
A backlog is good at storing work that can be done. It can also become a collection of obligations: customer wishes, sales promises, leadership ideas and technical improvements. The longer the queue lives, the more necessary it appears merely by existing.
Check where the top tasks came from
Take the top ten cards and reconstruct the chain for each: which customer triggered it, which result it should change, which observations support it and why it matters now. Do not ask the author to invent a polished justification afterwards; find the original conversation, data or decision.
Some tasks are obligations: fix a vulnerability, honour an agreement or maintain compatibility. They do not need a pretend connection to conversion growth. Others are investments in product outcomes. For those, the link to the chosen direction should be explicit.
In Next Move Theory, company focus is understood as directing resources towards specific jobs in the chosen segment. For a backlog, the practical question is: after all the urgent requests, how much attention does our chosen direction actually get?
Keep the customer’s task next to the solution
Imagine managers of service teams asking for an Excel export. “Build export” enters the queue. But the request may come from different situations: reporting to a client, calculating worker payments or combining data from several systems.
If the goal is to give a client a verified record of completed work, export is one option. Others include a ready summary, a restricted-access link or a document using an agreed template. Without the original situation, the team will compare only how long it takes to build a button.
Keep two linked records. One describes the situation, desired outcome and evidence of the problem. The other describes the chosen solution and constraints. Rejecting an implementation then does not erase what you learned about the customer’s task.
A priority should not outlive its rationale
A card may have been urgent because a contract depended on it. The contract fell through, but the task stayed at the top. Or an idea was meant to reduce manual handling, yet a process change has already solved the problem without development.
Add a decision date and a condition for relevance to important initiatives. For example: “Start if we confirm by month-end that this situation recurs among target customers.” This is not a deadline that automatically makes a task urgent. It is a point at which to recheck the rationale.
Archiving does not destroy the history. Keep the reason for stopping, links to observations and the circumstances that would justify revisiting the idea. A new colleague then will not restart the same argument from scratch.
Assess impact alongside uncertainty
RICE and other ranking methods help when the team agrees on what the input estimates mean. A number cannot repair a weak assumption. If expected reach is based on all customers but only one small segment needs the scenario, a careful calculation merely organises the error.
A short decision record is enough for the initiative under discussion:
| Field | Example for a hypothetical service |
|---|---|
| Customer and situation | A manager sends the client a summary of completed work |
| Required result | The client accepts the summary without further correspondence |
| Evidence | Specific instances of rejected reports have been examined |
| Assumption | A single template covers recurring requirements |
| Next test | Prepare a template manually and use it for several handovers |
| Constraint | Do not expose other clients’ data |
| Decision after the test | Automate, revise the template or stop |
This is an example of a team format, not a universal scoring template. Its purpose is to let another person understand where the work came from and what result is expected.
Reserve capacity for essential work in advance
Reliability, accessibility, security and bug fixes should not compete with every new idea through invented revenue forecasts. They have their own grounds: failure risk, existing commitments, service quality and the team’s ability to release changes.
Make resource allocation explicit. If most capacity goes to maintaining promises to existing clients, that is a material fact for strategy. Renaming technical tasks as product hypotheses will not change it.
Close the loop with a decision about the result
After release, close more than the engineering ticket. Return to the original question: did the customer get the result? What happened to cost and quality? Should you continue, change the solution or remove it?
Start the next planning session with these findings and the product’s current constraint. Choose a small amount of work the team can take all the way to validation. The backlog remains useful memory and an execution queue, while direction comes from fresh decisions rather than the age of accumulated cards.
