LSR, RICE and MoSCow: How to prioritise features fast and efficiently!

A. Problem:

80% of roadmap items labeled "P0." Ever felt like your product roadmap is a chaotic wishlist? Saying ‘yes’ to everything is the fastest way to build a bloated, unfocused mess. But how to handle such situation?

Simple Answer:

Stop Saying "Yes" to Everything Your Customers Asks For, rather take data driven approach to prioritising features that will bring meaningful impact like revenue increase, retention etc.

In the high-stakes world of product management, saying "yes" to every feature request is a surefire way to create bloated, unfocused products. It leads to misguided priorities, months of effort solving problems that impact a tiny fraction of users, and wasted development cycles that yield little to no ROI. Instead, top-performing product teams can use Live Stack Ranking (LSR) - a dynamic, data-driven prioritization framework that ensures teams work on what truly matters.

In this article, we'll explore what LSR is, how it integrates with proven prioritization frameworks like MoSCoW and RICE. By the end, you'll have a playbook to transform your prioritization process into a strategic advantage.

B. What is Live Stack Ranking (LSR)?

Live Stack Ranking (LSR) is a prioritization technique that forces teams to rank initiatives in real-time based on quantifiable metrics. Unlike traditional backlog grooming - where items are passively categorized - LSR is dynamic, iterative, and driven by live customer and stakeholder feedback.

LSR Process: Step-by-Step

1. Collect Customer Feedback First - Gather user input through surveys, interviews, support tickets, and analytics.
2. Group Similar Feedbacks and Define Features - Identify recurring pain points and assign a feature solution to each set of problems.

3. Validate Features with Customers (minimum 10% of your total users) - Features are pitched to the end user, for example, hey did you find the category button bit tricky to find/use, if the user says yes, pitch him/her "we are bringing it to the centre just below search bar for easy access, would it help you?", you should get an answer.

• If total users <1000: Conduct direct user interviews.
• If total users >1000: Perform surveys on top 80 percentile users along with smaller percentage of direct interviews as well.
4. Determine LSR Score - Rank features based on request frequency and importance(Revenue loss of a user because of a missing feature has a greater importance than colour or font change of a button).
5. Evaluate Features with RICE (PMs & Engineers) - Assess Reach, Impact, Confidence, and Effort for feasibility.
6. Review with Senior Stakeholders Using MoSCoW - Classify features as Must Have, Should Have, Could Have, or Won't Have.
7. Finalize Prioritization & Execute - Combine LSR, RICE, and MoSCoW scores to create a final roadmap for development.

Both LSR and RICE are totally data-driven and not guesswork and MoSCoW addresses that stakeholders voices are taken into account as well.

Why stakeholders (Like CEO, CPO, MDs, Board Members) voices matter? - Because they make the final decision and have the knowledge and experience to guide the team on immediate requirements while considering factors such as human capital, budget, and time etc.

C. How It Works: Detailed Explanation

1. Collecting and Grouping Feedback

Customer feedback is gathered through various channels such as direct interviews, NPS surveys, feature requests, and usage analytics. These insights are then clustered into common themes to identify underlying problems.

Example:

• Multiple users request better search functionality → Define "Advanced Search Filters" as a feature.
• Many complaints about payment failures → Define "Enhanced Payment Gateway Reliability" as a feature.

Note: You can skip the collection and grouping for features that are internal addition, for example "A team needs that started operation in India, need to collect subscription fees for their SAAS product and thus need a separate payment gateway for Indian users rather than Stripe which can be Razorpay, Cashfree or PayU etc"

2. Sampling and LSR Scoring (10% of total users)

Before committing resources, sample the proposed features with users:

• Small user base (<1000 users): Direct interviews to measure importance.
• Large user base (>1000 users): Perform surveys on top 80 percentile users to collect ranking data along with smaller sample size for direct interviews.

Each feature is then given an LSR Score based on:

• Frequency of requests
• Severity of pain point i.e. importance

3. Evaluating with RICE

Product managers and engineers score features using the RICE framework:

• Revenue - How much extra revenue it can bring or how much revenue loss it can stop?
• Impact - How many users will this feature impact & how much will it improve their experience?
• Confidence - How certain are we about the expected impact?
• Effort - How much time and resources will it take to build?

Formula:

RICE Score = (Revenue × Impact × Confidence) / Effort

This helps prioritize high-value, low-effort features first.

4. Reviewing with Stakeholders via MoSCoW

Senior stakeholders, such as CEOs, MDs and Board Members, classify features using the MoSCoW method:

• Must Have - Critical for launch or core functionality.
• Should Have - Important but not immediately necessary.
• Could Have - Nice to have but not urgent.
• Won't Have - Not valuable enough to pursue now.

---

D. Sorting Rules for Execution(Make one according to your needs)

Once LSR, RICE, and MoSCoW scores are gathered, features are sorted as follows:

• P0 (Highest Priority): LSR is High (≥80), RICE is High (≥80), and MoSCoW is "Must Have".
• P1 (Medium Priority): LSR is Medium (≥40, <80), RICE is Medium (≥40, <80), and MoSCoW is "Should Have".
• P2 (Low Priority): LSR is Low (<40), RICE is Low (<40), and MoSCoW is "Could Have".
• Won't Do: If MoSCoW is "Won't Have".

Additional Cases which help to filter more:

• LSR High, RICE Low, MoSCoW Must Have → High demand but costly to build. Reassess feasibility.
• LSR High, RICE Medium, MoSCoW Should Have → Consider elevating based on business impact.
• LSR Medium, RICE High, MoSCoW Must Have → Strong internal value, moderate customer demand. Further validation needed.
• LSR Low, RICE High, MoSCoW Could Have → Business-driven feature with low customer urgency. Prioritize based on company vision.
• Effort is disproportionately high in RICE calculations → Re-assess trade-offs before assigning P0.

By applying these detailed sorting rules, teams ensure that prioritization is both customer-driven and operationally efficient.

---

Tabular Prioritization Format:

Feature Name	LSR Score	RICE Score	MoSCoW Category	Priority	Deadline
Feature A	90	85	Must Have	P0	YYYY-MM-DD
Feature B	80	75	Should Have	P1	YYYY-MM-DD
Feature C	70	60	Could Have	P2	YYYY-MM-DD
Feature D	50	45	Won't Have	P3	YYYY-MM-DD

By structuring this way, prioritization is data-driven rather than intuition-based.

E. Why LSR is Superior to Traditional Prioritization

Most teams rely on subjective prioritization methods that often fall into one of four traps:

1. HiPPO (Highest Paid Person’s Opinion) Dominance - Decisions are made by authority, not data.
• Jeff Bezos explain this the best:
2. Inflationary Labeling - Everything is labeled "P0," making prioritization meaningless.
3. Misalignment Between Roadmaps and Customer Needs - Features are built based on internal assumptions rather than actual user feedback.
4. Misguided priorities: Teams spend months of effort solving problems that impact a tiny fraction of users, and wasted development cycles that yield little to no ROI.

F. LSR solves these challenges by:

• Forcing relative comparisons: Teams cannot label everything as "critical." Stack ranking makes trade-offs explicit.
• Incorporating live data: Customer surveys, analytics, and stakeholder votes shape prioritization dynamically.
• Creating transparency and accountability: Scores are visible to all, making prioritization decisions objective and measurable.
  

Conclusion: LSR is Your Competitive Advantage

Implementing Live Stack Ranking (LSR) transforms how teams prioritize, ensuring that decisions are backed by data rather than assumptions. By structuring priorities with customer-driven LSR scores, feasibility-focused RICE scoring, and strategic MoSCoW categorization, teams can:

✅ Maximize Impact - Work on the highest-value features that truly move the needle.
✅ Optimize Resources - Avoid wasting development cycles on low-impact requests.
✅ Increase Alignment - Ensure that customers, product teams, and executives are all on the same page.
✅ Stay Agile & Data-Driven - Continuously refine priorities based on real-time feedback and measurable business impact.

By adopting LSR, your team will stop reacting to random feature requests and instead execute a focused, scalable, and customer-centric roadmap. This approach is not just about managing priorities - it’s about building the right product at the right time with the right resources.

[UPDATE: 2 JULY 2025]

Rethinking Feedback: From Burden to Flow

A friend recently shared a pain point that struck a chord:

"You know all looks fine, but it's very difficult for me to collect feedback. Emails go unanswered, and feedback calls end up with users giving unrelated demands or having no context. How do I fix this?"

This isn't an isolated case. The current system of collecting feedback is fundamentally broken. The friction - emails, forms, untimely surveys - creates a barrier. Users either ignore it or respond without the right context.

But what if feedback wasn’t a separate task at all? What if it was built seamlessly into the product experience, so natural that the user doesn’t even realize they’re giving feedback?

Let’s explore that idea with a case study.

Case Study: Shopify’s AI Image Generator Feature

Imagine Shopify is about to roll out a feature that helps merchants generate AI-generated images of their products, directly from the "Add a Product" page.

Now, instead of sending a post-launch email asking for feedback (which will likely be ignored), here’s a smarter, passive feedback system built directly into the user flow.

👇 The Popup UI

A micro-prompt:

Each option acts as a vote, helping prioritize features. If the user selects “I have another idea,” a small text box expands, allowing them to write freely. Zero pressure, fully optional, and deeply contextual. Customizations are endless like:

• "Generate images using AI"
• "Auto-resize and crop images"
• "Use templates based on product type"

Why This Works

• Contextual: The feedback is tied to the moment the user experiences the feature. No confusion, no disconnect.
• Passive: No extra effort. A few clicks at most.
• Scalable: No manual outreach needed. Works across thousands of users.
• Insightful: Options guide users toward valuable input, while still allowing open-ended suggestions.
• Time-efficient: Users don’t feel like they’re “giving feedback” at all.

💡 Build More, Chase Less

This system enables product teams to build more and chase less. Less time spent hunting for feedback, more time spent acting on it.

And to be clear, this doesn’t mean we stop talking to customers.

“I’m not discouraging you from speaking with customers - those casual chats over coffee or quick calls often uncover the best ideas. After all, when does a customer ever say, ‘Hey, please build this for me’ outright?”

Never underestimate real human interaction. But when it comes to scaling feedback, integrating it at the point of experience is where product magic begins.

Final Tip: Start with a small LSR pilot, measure the results, and scale from there. Your team’s efficiency and impact will skyrocket. If you are a startup have LSR cycles as small as 20-30 days, and if you are a big company with thousands of users you can have a quarterly or half yearly LSR cycles. What this will do is it will give you continuous validations(thus the word "L" in LSR which denotes "Live") rather than after a 6 months or year, which will save you from changing trends or customer preferences like Feature A will take 6 months to develop but due to a change in market condition customers no more need it, with Live data you can see LSR score dropping, since the development was already started 2 months back, your team can halt it at 2 months time thus saving you 4 precious months, in startup world, forget months or even days but every hour counts!

Good Luck, Happy Building🚀