How to Prioritize Product Features Using Stack Ranking

Every product manager faces the same challenge: too many feature requests, not enough development time. Here's how stack ranking helps you build the right things first.

The Feature Prioritization Problem

Your backlog has 47 features. Sales wants custom reports. Support wants better onboarding. Engineers want to refactor the auth system. The CEO has "one quick idea."

Traditional prioritization methods fail here:

• Voting: Everyone picks their favorite, no consensus emerges
• RICE scores: You spend days calculating, stakeholders argue about the math
• Gut feeling: The loudest voice wins, not the best idea

Why Stack Ranking Works Better

Stack ranking forces everyone to make tradeoffs. You can't say "everything is high priority." You have to choose: is dark mode more important than API access?

Step-by-Step Process

Step 1: Narrow Down Your List (5-12 Features)

Don't rank 47 features. People give up. Instead:

• Filter by theme (e.g., "Q1 Enterprise Features")
• Pre-eliminate obvious non-starters
• Group similar requests together
• Aim for 5-12 distinct options

Step 2: Write Clear Descriptions

Don't write: "Dark mode"

Write: "Dark mode toggle in settings (8 dev days, affects all screens, reduces eye strain for 40% of users per survey)"

Include:

• What it does (one sentence)
• Rough effort estimate
• Expected impact or user request volume

Step 3: Choose Your Stakeholders

Who should rank features? Depends on your goal:

• Strategic decisions: Leadership team (5-8 people)
• User needs: Representative customers (20-50 people)
• Internal priorities: Cross-functional team (10-15 people)
• Technical tradeoffs: Engineering team

Step 4: Create Your Ranking Poll

Use a tool with drag-and-drop voting (like StackRank). Email or Slack the link. Give people 2-3 days to respond.

Pro tip: Randomize the order of options. Otherwise, people favor items at the top.

Step 5: Analyze Results

Look at average rank position:

• Average rank 1-3: Build these first (clear winners)
• Average rank 4-6: Build these next quarter (valuable but not urgent)
• Average rank 7+: Move to backlog (can wait)

Also watch for:

• Unanimous #1: Consensus feature, definitely build it
• Polarizing (some rank #1, others #12): Investigate why; might need different solution for different segments
• Bunched rankings: If everything averages 5-7, your list might be too similar; need more distinct options

Real Example: SaaS Company Prioritization

A B2B SaaS company had 10 features for Q1. They asked 12 stakeholders (4 sales, 4 support, 4 engineering) to rank them.

Results:

1. SSO/SAML login (avg rank 1.8) - Clear winner
2. Bulk import via CSV (avg rank 2.9)
3. Custom reports builder (avg rank 4.1)
4. Mobile app (avg rank 6.7) - Polarizing: Sales ranked it #2, Engineering ranked it #9
5. Dark mode (avg rank 8.3) - Can wait

Decision: Build SSO and CSV import in Q1. Deep-dive on mobile app (why the disagreement?). Push dark mode to Q2.

Common Pitfalls to Avoid

1. Ranking Apples and Oranges

Don't mix "2-day bug fix" with "3-month platform rewrite." Keep scope similar.

2. Too Many Options

Ranking 20 features is exhausting. Break into multiple polls if needed.

3. Ignoring Effort

A #1 ranked feature that takes 6 months might not be the right choice. Include effort estimates in descriptions.

4. One-and-Done

Re-rank quarterly. Priorities shift. New information emerges.

Conclusion

Stack ranking transforms feature prioritization from politics into data. Instead of the loudest voice winning, you get genuine consensus on what matters most.

The key: keep your list focused (5-12 items), write clear descriptions with effort estimates, and analyze results for both consensus and disagreement.