Compare the customer situations behind requests before comparing proposed features. Rank the consequences, frequency and strength of evidence, then choose a problem whose improvement can be observed. Keep the reasoning beside any score so that new evidence can change the order.
Translate requests into interrupted work
A request for a mobile application names a solution, while the underlying difficulty might be recording a handover away from a desk. Ask what happened when the current approach failed, who was affected and what workaround followed. Different requests may concern the same interrupted task; identical requests can conceal different tasks.
Write problem statements without embedding the proposed feature. “Field staff cannot confirm the latest job instructions before leaving a site” leaves several responses open. “We need push notifications” does not. Preserve the original request in your notes so the translation can be checked with the person who made it. Reframing should clarify their concern rather than replace it with your preferred project.
Compare consequence and repetition separately
Record how often the situation occurs and what happens when it does. Frequent minor inconvenience and rare severe disruption require different judgments. Use recent examples, operational records where appropriate and the customer's own explanation of the consequence. Avoid assigning a precise financial value when you lack the inputs to calculate one.
Identify the roles carrying the burden. An issue that is invisible to the buyer may consume substantial staff effort, while a buyer's frustration may occur only during an annual review. These differences do not automatically determine priority, but they affect the evidence and sponsorship needed for a test. Keep commercial importance and user impact visible as separate considerations.
Make uncertainty part of the ranking
A compact comparison can use simple labels such as high, medium and low, provided everyone understands what the labels mean. Add evidence quality beside each judgment. Three recent incident records are different from a second-hand statement that something “always happens”. A promising but weakly evidenced problem may deserve discovery before implementation.
Discuss disagreement explicitly rather than hiding it in an average score. One colleague may be ranking delivery cost while another is ranking customer harm. State the decision being made: which problem to investigate, which to test or which to commit to improving. The right choice can differ at each stage. A ranking for next week's learning work should not silently become a permanent development roadmap.
Choose the smallest observable improvement
For the leading problem, describe a change in the customer's work that would count as improvement. A completed feature is an output; a handover received without clarification is an observable effect. Choose a test that can reveal that effect without requiring the full proposed system. Sometimes a clearer instruction, summary or ownership rule will expose the key assumption.
Set a review point and a condition for changing priorities. The problem may be less frequent than expected, the workaround may already be adequate or another issue may block the improvement. Keep these findings with the ranking. A transparent reversal is better than defending a score after its evidence has weakened.
Fictional example: three requests, one handover failure
A fictional scenario to explain the method, not a customer result or a market benchmark.
A fictional maintenance service receives requests for a larger upload limit, automatic reminders and a mobile application. Its team reviews recent jobs before choosing a feature. Several cases involve photographs arriving without an explanation of the next action. Staff then call the previous shift to reconstruct what remains unfinished.
The team ranks unclear handover responsibility above file capacity for its next experiment. It tests a short handover summary containing the current state, next action and receiving owner, using the existing tools. It records whether the recipient still needs clarification and how much support the trial requires. A mobile application may eventually help staff submit that information, but it is not assumed to be the first necessary step. The service and events are fictional; the case demonstrates a decision process rather than a measured performance result.
TAKE THIS INTO YOUR NEXT CONVERSATION
A practical next-step checklist.
- Rewrite each feature request as a situation and consequence.
- Assess frequency separately from severity.
- Show whose work is affected and who can sponsor change.
- Put evidence quality beside every priority judgment.
- Define the observation that could change the leading choice.
Common questions.
Should a large customer request always rank first?
Consider the commercial context, but also inspect scope, delivery burden and whether the problem is shared by your chosen segment. A large contract can justify bespoke work only as an explicit decision.
Do we need a numeric scoring framework?
No. Consistent criteria and visible reasoning matter more than arithmetic. A score helps only when its inputs and trade-offs remain understandable.
Further reading & source context.
These primary references provide background. They are not evidence for the fictional example above and do not endorse AccelerateLink.
Found an error or a missing qualification? Send an editorial correction.
Find my next move.
Use a practical tool to turn this idea into a clearer starting point.
Find my next move