Everyone has software requests. What should come first?

A request for a dashboard already contains a proposed solution. Ask what the colleague cannot currently decide or do well. Do they need to identify customers who need attention, or find orders that are not ready for delivery? Similar requests can conceal quite different problems.

Ask for a recent example. What was the person trying to achieve, what was missing and what happened next? Include whoever receives the result of their work. An export that saves one team effort may create a new checking task for another. Following the whole activity helps you assess the request before discussing screen layouts.

The UK Government Digital Service's guidance on deciding priorities brings together user research, performance evidence and stakeholder input. It was written for public services. The approach here applies that principle to an existing business application, without assuming that one scoring formula suits every company.

Before ordering the requests, make existing commitments visible. Include essential maintenance and the time employees can contribute to design, preparation and testing. Development capacity alone does not determine whether a change can be introduced successfully.

Handle a serious incident or demonstrably urgent security issue through the responsible people and the agreed response process. Do not quietly place it in the same competition as an optional convenience. Equally, a technical improvement needs an explanation of the problem it addresses, any relevant deadline and the consequence of delay.

Agree who decides the sequence and who provides the evidence. The owner can set direction and spending boundaries while a product lead makes choices within them. Employees need a way to explain the work and challenge an incorrect assumption. Participation should give them influence without requiring unanimous approval for every adjustment.

Make the limits visible to your partner as well. If the colleague who understands a pricing rule is unavailable, an apparently small change may not be ready. Naming that dependency allows the team to choose useful work instead of starting something that will immediately wait for an answer.

Take a manageable selection of specific requests and examine them in the same way. This makes a difficult operational problem easier to compare with a polished proposal for something new.

Question	What the decision needs
Which work improves?	The person and responsibility that would benefit
What do we know?	Examples or observations supporting the request
What happens if it waits?	The disruption, commitment or opportunity left unresolved
What does it require?	Development, preparation, rollout and continuing support
What remains uncertain?	An assumption that could change the choice

Consider a fictional wholesaler comparing a sales dashboard with an improvement to incomplete-order handling. Sales expects better customer conversations. Operational staff can show repeated requests for missing order details. The second proposal has clearer evidence, but that alone does not prove that it should come first.

Perhaps a particular commercial decision has become time-sensitive. Ask sales to show which conversation is difficult and what the new information would enable. Compare that outcome with the operational problem. Avoid treating an untested revenue expectation as a confirmed benefit simply because it can be entered into a spreadsheet.

Some requests need a small investigation before development. A brief observation, a trial using existing data or a simple design review may answer the question that changes the priority. Choose the investigation for that purpose and give it a clear boundary.

For the wholesaler, first examine why orders arrive incomplete. Is the customer being asked an unclear question? Does a colleague lack knowledge of an agreement? Is the application unable to record the answer properly? These explanations lead to different changes. A mandatory field could produce superficially complete records filled with guesses if people still cannot obtain the information.

Agree the decision the investigation should support: proceed, use another approach or leave the request for now. Limit the time and effort devoted to it. Explain to participants that reviewing a prototype does not commit the company to delivering the proposed feature on a particular date.

This also protects useful ideas from premature rejection. A request may matter while its suggested implementation is wrong. Keeping the underlying problem visible allows a simpler process change or an existing capability to meet the need.

Choose a change small enough to assess but complete enough to support real work. A new screen may be insufficient if the user lacks authority to act or the next colleague cannot see the decision. Include those parts of the responsibility in the agreed scope.

Record the choice briefly: the problem being addressed now, the result expected and the alternatives being deferred. State what new evidence would justify revisiting it. A postponed request then has an intelligible status rather than disappearing into a growing list.

When an urgent new request arrives, identify which existing commitment it would displace and who needs to know. The same team cannot promise the same capacity twice. Our software strategy work connects these decisions to the direction of the business and the capabilities already available in its applications.

Agree how to judge the result before development starts. GDS guidance on defining success combines relevant performance measures with user research. For the order improvement, this could mean checking whether employees can prepare an order without asking again for missing information, alongside discussing exceptions that still need support.

Keep a few representative situations as a starting point for comparison. Look at accuracy, effort transferred to other colleagues and the ability to help the customer, as well as speed. Use the review to improve the application and working arrangements rather than to rank individual employees.

If the result disappoints, find out why before adding another feature. The problem may have been misunderstood, the design may be awkward or support may be missing. Our article on introducing software with employees explores that practical adoption work.

Start with a decision meeting around a few actual requests, involving the people doing the work and your technical partner. You do not need a complete development plan to make progress. You need an explainable choice, someone responsible for it and an agreed point at which to assess whether the work has improved.