Prioritisation Frameworks

Why Prioritisation is the Job

Every product team has more ideas than time. A PM at Paystack might have engineers who could build instant settlement improvements, a new merchant dashboard, fraud detection upgrades, or a referral programme -- all in the same quarter. There is never enough time, money, or engineering capacity to build everything at once.

Prioritisation frameworks turn a messy backlog of opinions ("the CEO wants this", "a big customer asked for that") into a structured, defensible decision about what to build first. A good framework does not remove judgement -- it forces the judgement to be explicit, so the whole team can see the reasoning and disagree with the inputs rather than the gut feeling.

RICE: Reach, Impact, Confidence, Effort

RICE, popularised by Intercom, scores each idea on four factors and combines them into a single number:

Formula:

RICE score = (Reach x Impact x Confidence) / Effort

Worked example: Moniepoint is deciding between two features for its POS terminals.

• Feature A: Offline transaction queueing -- Reach: 20,000 agents/month, Impact: 2 (high), Confidence: 80%, Effort: 3 person-months. RICE = (20,000 x 2 x 0.8) / 3 = 10,666
• Feature B: In-app loyalty rewards -- Reach: 8,000 agents/month, Impact: 1 (medium), Confidence: 60%, Effort: 1 person-month. RICE = (8,000 x 1 x 0.6) / 1 = 4,800

Offline queueing wins decisively, even though loyalty rewards is cheaper -- because it reaches far more agents with higher impact. This is the power of RICE: it stops "quick and easy" ideas from crowding out ideas that matter more.

Use the interactive RICE Calculator below to score your own feature ideas.

MoSCoW: Must, Should, Could, Won't

MoSCoW is a simpler, faster framework often used for scoping a single release or MVP rather than ranking a large backlog:

• Must have -- Non-negotiable. The release fails without it. (e.g. a payments app must have transaction history.)
• Should have -- Important but not launch-blocking. Painful to skip, but the product still works. (e.g. exporting transaction history to PDF.)
• Could have -- Nice to have if time and budget allow. (e.g. custom colour themes.)
• Won't have (this time) -- Explicitly out of scope for now, to prevent scope creep and endless debate.

MoSCoW is popular in Nigerian fintech and telecom teams (e.g. at Flutterwave and MTN) for sprint and MVP planning because it is fast to run in a workshop with stakeholders and produces a clear, shared line between "in" and "out."

The Kano Model

The Kano Model, developed by Noriaki Kano, classifies features by how they affect customer satisfaction -- helping teams distinguish "must exist" features from features that genuinely delight:

Kano is typically built from a customer survey asking how users would feel with and without a feature. It is powerful because delighters today often become basics tomorrow -- free data rollover was once a delighter for African telecom customers; now its absence would be considered a dealbreaker.

Choosing the Right Framework

Global teams like Spotify and Amazon often blend frameworks: RICE for backlog scoring, Kano-style customer research for discovery, and MoSCoW-style scoping in release planning meetings. There is no single "correct" framework -- the goal is a repeatable, transparent process the team trusts.

Common Prioritisation Pitfalls

• HiPPO decisions -- Highest Paid Person's Opinion overriding data-backed prioritisation.
• Sunk cost fallacy -- Continuing to invest in a feature because of work already done, not because it is still the best use of time.
• Vanity metrics -- Prioritising features that boost easy-to-measure but low-value metrics (e.g. downloads) over metrics that matter (e.g. retention or revenue).
• No re-prioritisation -- Treating the roadmap as fixed instead of revisiting priorities as new data arrives.