How to Prioritize Product Features When Everything Feels Important

The business situations in this article are fictional illustrations, not accounts of Parikh Advisory client engagements.

A sales prospect wants enterprise permissions. Customer success wants the onboarding failure fixed. Engineering needs time to remove a fragile integration. All three requests are plausible; only one team owns the next six weeks. The useful question is not which request has the most persuasive sponsor. It is which decision best advances the agreed outcome within the capacity and risk the business can actually carry.

Set the decision horizon

Start with a time box and one outcome: for example, improve activation among the target customer segment this quarter. List non-discretionary obligations separately: an active security exposure or contractual deadline should not be buried in a feature popularity contest. Then name the capacity that remains. If a request cannot be connected to the outcome or a genuine obligation, it needs a clearer case before it takes a slot.

Compare evidence, not adjectives

For each candidate, record the affected users, observed problem, expected change, evidence quality, effort range, dependencies, and the cost of waiting. A customer conversation is evidence of a problem, not proof that the requested feature is its best solution. A lost deal is informative, but ask whether that buyer represents the segment you intend to serve repeatedly. Distinguish measured friction from a forecast and write down the assumptions that could reverse your ranking.

Make the trade-off explicit

Imagine enterprise permissions might help one large contract, while an onboarding repair could improve hundreds of new accounts. The first has concentrated revenue potential; the second may strengthen repeatability. Compare plausible upside, delivery risk and opportunity cost. If the enterprise commitment has a binding date, record it. If it is still speculative, do not silently treat it as contracted revenue. A score can help structure discussion, but it cannot resolve strategic judgment for the accountable leader.

Commit, learn, and reopen

Publish a short decision log: chosen work, deferred work, why, owner, review date and what evidence would change the choice. Give sales an honest response for the customer and engineering a defined scope. Test the riskiest assumption with a small release or customer walkthrough where possible. Revisit when new evidence arrives, not every time a louder stakeholder enters the room. This is how a roadmap becomes a record of accountable decisions instead of a queue of promises.

A decision to take into the next meeting

Bring one actual case, name its owner and decide what evidence would justify the next investment. If the evidence is missing, make the smallest useful test the next action. Record the choice and the date to review it.

Source note: GOV.UK Service Manual, Deciding on priorities. The example is illustrative; the source informs the method or control discussed, not the imagined business.