How to Prioritise Software Features Based on Business Value

Start with the problem. Ask what problem each requested feature solves and how you would know it worked, because a request without an observable outcome cannot be ranked against anything. “Sales wants a dashboard” is not rankable. “Sales spends about an hour a day compiling numbers that a dashboard would show live” can be ranked, because it names a measurable outcome.

Park the rest on a holding list. Requests with no measurable problem are not bad ideas, but they should wait until someone can say what they would fix and how that would be measured. Otherwise they compete on equal terms with evidenced requests, and the ranking drifts toward whoever writes the most persuasive message rather than whoever carries the most pressing problem. Persuasion is not evidence.

Test each request with one question. Ask the requester what they would stop doing, or start doing, the day the feature exists, and write the answer next to the request in their own words. Answers like “nothing changes” are common, and they save weeks of build time by moving a request to the holding list before anyone estimates it. Cheap questions save expensive builds.

Everyone calls their request essential. Use a tighter test: a must-have is something the release cannot function without, so if removing it still leaves a usable release, it is not a must-have. However important a feature feels to the person who asked for it, importance alone does not make it a condition for launch, and the test keeps that distinction visible. Apply the test aloud.

Write the real constraints beside it. List a budget ceiling, a hard launch date tied to a licence renewal, a seasonal peak or a contractual deadline, and any technical limit of the platform you chose. Constraints are not a formality. They turn a long wish list into a release that a real team can deliver by a real date with the money actually available.

Score each feature on three measures. Value is the size of the problem it solves, and risk is what happens if you do not build it, where a compliance gap differs from a convenience gap. Effort covers development time, complexity and the testing burden, and looking at any one measure alone produces a skewed list that favours whichever factor the loudest person cares about. High value with very high effort can rank below moderate value with low effort and low risk, and the grid should be allowed to show that. Let the grid speak.

Dependencies then adjust the order. A lower-scoring feature that enables two higher-scoring ones may need to move earlier, because everything else in the plan waits on it. Map these links before you fix the release order, or you will publish a plan that looks correct on paper but cannot be built in that sequence. Build the enabler first.

Keep the scale simple. A one to five scale for each measure is enough, because the aim is a defensible order rather than precision that the available evidence cannot support. Score together in one meeting with finance, operations and sales present, and record the reason beside every number so the discussion afterwards is about evidence.

Group scored features into phases. Use a first release of genuine must-haves, a near-term follow-up and a longer list, and name the deferred items instead of letting them vanish from conversation. Whoever asked for a deferred feature deserves a concrete answer about when it will be reconsidered, because a vague “maybe later” erodes trust in the whole process. Give every deferral a date.

Consider a coworking space operator. It is building a member app, where operations asks for automated check-in and sales asks for referral credits, and both requests arrive with equal urgency. Scoring shows check-in solves a daily, high-friction problem for every member, while referrals solve an occasional problem for a few, so check-in ships first. Referrals go on the deferred list with a review at the next quarterly planning meeting, not an open-ended “eventually” that nobody ever revisits.

Pre-launch scores are estimates. Real usage proves them wrong in specific, useful ways, so after each release check which features get used, which get used differently than expected and which sit untouched. Feed those observations straight into re-scoring the deferred list, and let the evidence overrule the opinion that originally put an item at the bottom. Usage data beats opinion.

Most small businesses skip this step. They treat the first ranking as final instead of as a first draft, so the backlog drifts further from what staff and customers actually do. A feature that scored low before launch can become the obvious next build once usage shows where the release falls short, and a high scorer may matter far less.