A product prioritisation framework India startup teams can trust replaces gut-feel debate and HiPPO overrides with a shared, visible scoring method — usually RICE or ICE — applied before the roadmap meeting rather than argued about after a decision the loudest voice in the room, typically the CEO, has already made.
This post breaks down how HiPPO (“Highest Paid Person’s Opinion”) decision-making creeps into early-stage teams. It also covers how RICE and ICE scoring work, and where each one breaks down. Then it covers how to introduce a framework without starting a turf war with leadership. If you are still validating whether you have the right problem to prioritise, read our piece on product-market fit metrics for India startups first. Prioritisation only matters once you know which problem is worth solving.
By Zaheer Thaha · Last updated: July 23, 2026
Key Takeaways
HiPPO decision-making is not a personality flaw — it is what happens by default when no scoring framework exists to replace it.
RICE scoring (Reach, Impact, Confidence, Effort) gives every roadmap item a comparable number, but it is only as honest as the estimates feeding it.
ICE scoring trades RICE’s precision for speed, making it the better fit for early-stage teams running weekly triage.
Opportunity scoring, derived from the Kano model, prioritises by the gap between how important a feature is and how satisfied users already are with it.
A prioritisation framework survives a HiPPO override only when it is introduced as a tool the CEO uses too, not a process imposed on them.
The HiPPO Problem: Why “Highest Paid Person’s Opinion” Wins by Default
The HiPPO problem persists for a simple reason: without a scoring method, decisions collapse to whoever has the most authority in the room. In most India startups, that is the founder or CEO. Early on, this works fine, because founder intuition is often right about the big bets. The trouble starts once the company outgrows that intuition as a reliable filter. However, the decision-making habit rarely changes with it. As a result, a ten-person team’s process can look identical to a hundred-person team’s. The only difference is more people quietly disagreeing in Slack.
This pattern is not unique to India. Intercom’s original RICE writeup describes the same failure mode: teams “guessing” at priority because no one agreed on what “impact” meant. The fix is not removing the CEO from the conversation. Instead, give everyone, CEO included, the same scoring inputs. This moves the debate from opinion to assumption, and assumptions can be tested.
RICE Explained: Reach, Impact, Confidence, Effort — and Its Limits
RICE scoring forces every roadmap item through four estimates, then combines them into one number: (Reach × Impact × Confidence) ÷ Effort. Reach estimates how many users a change touches in a given period. Impact is a multiplier — commonly 3, 2, 1, 0.5, or 0.25 — for how much that change matters per user. Confidence is a percentage that reflects how solid the data is. Effort is the cost, in person-months.
Here is a worked example. A billing-page redesign reaches 4,000 users a quarter, with a 2x impact multiplier, 80% confidence, and 3 person-months of effort. That scores (4,000 × 2 × 0.8) ÷ 3 = 2,133. A new integration reaches only 200 power users, but carries a 3x impact multiplier and full confidence. With 1 person-month of effort, it scores (200 × 3 × 1) ÷ 1 = 600. The billing redesign wins on RICE, even though the integration feels more exciting in a leadership meeting. That gap is exactly what RICE exists to expose.
RICE’s limit is that three of its four inputs are estimates, not measurements. A confidently wrong Reach or Impact number produces a confidently wrong priority. Teams that skip writing down their reasoning tend to anchor on whatever score justifies what they already wanted to build. Therefore, RICE only earns its reputation for rigor when every score carries a one-line rationale, not just a number.
ICE Scoring: A Simpler Alternative for Early-Stage Teams
ICE scoring answers the same question with three inputs instead of four: Impact, Confidence, and Effort. Each is rated on a 1–10 scale and multiplied together. Dropping Reach makes ICE faster, because nobody has to dig through analytics before a Tuesday standup. That speed is also its weakness. A feature that delights 20 users and one that delights 20,000 can post the same ICE score. That happens because Impact, Confidence, and Effort can feel similar to whoever is scoring them.
In practice, ICE suits a five-to-fifteen-person team triaging a weekly backlog, where most ideas reach a similarly sized audience anyway. Once a startup has customer segments of very different sizes, however, the missing Reach term starts hiding real gaps. That is the signal to graduate to RICE. Many of our India startup clients run ICE for the first 12–18 months. They then move to RICE once a second product line forces them to compare reach across genuinely different audiences.
Opportunity Scoring: Prioritising Around the Kano Model for User-Centric Teams
Opportunity scoring prioritises features by the size of the gap between how important users say a job is and how satisfied they currently are doing it. The bigger the gap, the bigger the opportunity. This approach borrows from the Kano model’s split between basic, performance, and delight features. Users rate importance and satisfaction on a 1–5 scale for each job-to-be-done. Opportunity is then importance plus the positive difference between importance and satisfaction.
This method earns its keep when a team has rich user research but weak internal agreement on what that research means. Opportunity scoring turns survey data into a ranked list nobody has to interpret from scratch. The trade-off, however, is real. It needs a user research pipeline that RICE and ICE do not. Teams without a recurring way to survey users cannot run it credibly. For B2B India startups, a quarterly survey of 15–20 active accounts is usually enough signal — no dedicated research team required.
📊 Key Stat: In Marty Cagan’s analysis of product organisations, teams without a structured discovery and prioritisation process ship roughly half their features with no measurable business or customer impact. That is the strongest argument for replacing opinion-led roadmaps with a scoring method before scaling the team further.
How to Introduce a Framework When the CEO Always Overrides the Data
The way to introduce a framework to a CEO who keeps overriding data is simple. Hand them the scoring sheet before the meeting, not after the decision is already made. Most HiPPO overrides are not really about ego. They are about timing. A CEO who first sees a fully-baked priority list in the meeting will want to poke holes in it live. By contrast, a CEO who scored three items themselves the night before walks in already invested in the method.
Start small. Pick the next sprint’s five most contested backlog items and run them through RICE or ICE. Share the spreadsheet with leadership 48 hours ahead of the planning meeting. Invite an open challenge to any single input. This reframes the conversation from “your idea versus my idea” to “which Reach estimate is wrong,” a smaller, more solvable disagreement. Because the framework is transparent, a CEO can still override a final score. But now they are overriding a specific, visible assumption, not a process they were never part of.
| Dimension | RICE Scoring | HiPPO |
|---|---|---|
| Decision basis | Reach, Impact, Confidence, and Effort estimates, documented per item | Whoever holds the most organisational authority in the room |
| Speed to decide | Slower — requires gathering and agreeing on four inputs | Fast — a single opinion settles it immediately |
| Repeatability | High — same inputs produce the same ranking for anyone | Low — depends entirely on who is present that day |
| Team buy-in | Higher, because the rationale behind each score is visible | Lower, because junior team members cannot contest a senior opinion |
| Failure mode | Confidently wrong estimates produce confidently wrong priorities | Strong early intuition masks the need for data as the team scales |
Relative comparison of decision speed, repeatability, team buy-in, and data rigor between RICE scoring and HiPPO-driven decisions.
Common Mistakes Teams Make When Adopting a Prioritisation Framework
Treating the CEO as the Enemy Instead of a Co-Owner
The most common mistake is framing the new framework as a way to overrule the CEO, instead of a tool the CEO also uses. Teams that pitch RICE as “now we’ll stop you from picking your favourite feature” trigger defensiveness fast. That alone can kill adoption in week one. Instead, position the CEO as the framework’s first power user. Their instincts get validated or challenged by data, not managed around.
Scoring Once and Never Revisiting the Numbers
A second mistake is treating RICE or ICE scores as permanent once written down. Reach and Confidence estimates made in January are often stale by June. This is especially true for an early-stage product with a fast-changing user base. Consequently, teams should re-score the top of the backlog at least once a quarter. Also re-score whenever a major assumption, like the size of a customer segment, turns out to be wrong.
Letting Effort Estimates Come Only From Engineering Without Context
The third mistake is collecting Effort estimates from engineers in isolation. Teams skip sharing the Reach and Impact numbers those estimates get compared against. An engineer asked “how long would this take” in a vacuum tends to give a conservative, defensive number. By contrast, an engineer who knows a feature might unlock a 2,000-user segment reasons about effort differently, and more usefully.
Proof: How a Re-Scored Roadmap Changed One Client’s Quarter
One of our HR-tech clients in Bengaluru came to Quinoid running a HiPPO-driven roadmap. The founder picked the next three features every sprint, based on the last customer call he had taken personally. We introduced RICE scoring across a backlog of 34 items. The founder, product lead, and two senior engineers scored it together in a single 90-minute workshop. The exercise surfaced something the team had missed. A notifications-permissions fix had sat deprioritised for two sprints. It scored 3,800, the highest in the backlog, because it touched every user on every login. The founder’s preferred analytics dashboard, by contrast, scored only 410, because it reached a narrow admin-only segment. The team shipped the notifications fix first. Within five weeks, support tickets tied to missed alerts dropped by 38%. The founder became the framework’s strongest internal advocate, because the data had validated a fix he had been underrating.
That outcome is the real argument for a structured framework. It does not just block bad ideas. It also surfaces good ones nobody was championing loudly enough to win a HiPPO debate.
Frequently Asked Questions
How much does it cost to set up a prioritisation framework?
Setting up RICE or ICE scoring costs nothing in software, because a shared spreadsheet is enough for teams under 20 people. The real cost is time. Budget one 60–90 minute workshop to score your current backlog, plus 15–30 minutes per sprint afterward for new items.
How long does it take before a team sees the benefit?
Most teams notice a difference within one sprint cycle, because the scoring debate replaces the opinion debate immediately. The bigger cultural shift, leadership trusting scores over instinct, usually takes two to three full cycles. For a team running two-week sprints, that is roughly one quarter.
What’s the difference between RICE and ICE in practice, not just theory?
In practice, RICE takes longer per item, because Reach requires pulling a number from analytics. ICE, on the other hand, can be scored from memory in minutes. Choose ICE when your team is small enough that most ideas reach a similar audience size. Choose RICE once you compare ideas that touch very different numbers of users.
Are there good alternatives if RICE or ICE don’t fit our team?
Yes. Opportunity scoring based on the Kano model works well for teams with an active user research pipeline. A simple weighted-scoring matrix against company-specific criteria also works well. Revenue, retention, strategic fit, and effort are common picks for teams that find RICE’s formula too rigid for their stage.
Can a small startup really run this without a dedicated product ops person?
Yes. A founder, one product or engineering lead, and a shared spreadsheet are enough to run ICE or RICE consistently. The framework needs no dedicated tooling or headcount — only a recurring 30-minute slot in the sprint cycle to keep scores current.
The Real Fix Is a Shared Framework, Not a Better Argument
HiPPO decision-making is not a leadership failure. It is what fills the vacuum when no product prioritisation framework exists to replace it. RICE gives larger, multi-segment teams a rigorous, repeatable score. ICE gives early-stage teams speed. Opportunity scoring gives user-research-rich teams a way to let customers settle the debate. None of these work, however, if they get introduced as a weapon against the loudest voice in the room. They work only as a tool that voice helps build.
If your roadmap still gets decided in the same meeting where it gets argued about, that usually signals the process needs outside structure, not just outside opinions. Quinoid’s product strategy consulting team works directly with founders and product leads across India. Together, we design and embed a scoring framework that survives contact with a real leadership team, not just a slide deck.
Have a product idea, roadmap question, or MVP build decision to make?
Build the right first version with Quinoid.
Talk to our product and engineering team about the fastest practical path from idea to validated software.
