After mapping a service, ideas are rarely in short supply. A form is confusing, information is repeated, waiting is lengthy and several tools do not work together. The difficulty is choosing the first change. When everything is the top priority, the team cannot see where to begin, and it becomes harder to tell which change caused which effect. Prioritization concerns the order of attention, not a contest for the most appealing proposal.
Begin with the effect on the work
Consider a hypothetical organization weighing a new dashboard, clearer request status and the removal of duplicate entry. The number of users alone will not settle the comparison. A minor ambiguity may generate follow-up every day, while an uncommon error may have a more serious consequence. Consider frequency, severity and the people affected together.
GOV.UK’s guidance on deciding on priorities uses performance analysis, user research and stakeholder input to inform decisions. It also includes support and technical debt, not just new features. Prioritization should therefore extend beyond additions that are easy to demonstrate.
Importance is not the same as readiness
A change can be important without being ready for safe implementation. Connecting two systems may depend on an agreement with the data owner and clear access rules. Revising a message may be testable sooner. That difference need not mean abandoning the important change. Turn its prerequisite into a specific piece of work instead of leaving a vague promise at the bottom of the list.
For each option, ask what outcome is expected, what evidence supports the problem, what remains uncertain and whose cooperation implementation requires. If you assign numerical scores, record their reasons as well. A number built from guesses should not behave like a confirmed fact. Sometimes clarifying a risky assumption is more valuable than immediately starting development.
A limited change, not a meaningless fragment
Narrowing the scope should create an opportunity to learn. If the aim is to reduce request follow-up, a limited change might clarify status and responsibility for one type of request. Changing a button’s color alone does not necessarily test that assumption. Choose a boundary where the connection between the change and the problem remains visible and the people delivering the work can support it.
Alongside what you choose, make clear what you will not do yet. This supports focus and reduces hidden expectations. If a feature is outside the current scope, record the reason and when it will be reconsidered rather than silently ignoring the request. A good decision is understandable to people outside the meeting and states what new evidence could change the order.
A roadmap expresses intent, not commitment to a guess
GOV.UK’s guide to developing a roadmap presents it as an expression of intent and value, rather than an unchangeable list of solutions. Each step needs a goal and a way to assess progress. That allows the sequence to change responsibly as the team learns.
The first choice is not the final decision. A test may sharpen the problem definition or reveal another dependency. Reconsidering priorities is not instability when the reasons are clear. Unexplained changes of direction are what weaken trust. Keep the intended outcome steady while allowing implementation assumptions to be revised.