Prioritize: Feature Ranking and Scoring
Score and rank features, initiatives, or backlog items using established PM frameworks. Auto-detects the right framework and mode from context.
When to Activate
- User says "prioritize", "rank these", "what should we build next?"
- User asks for RICE, ICE, WSJF, or any scoring framework
- User needs to make scope cuts or trade-off decisions
- User has a list of features and needs to decide order
Modes
Auto-detect from user phrasing. If ambiguous, ask.
| Mode |
When |
Output |
| Stack rank |
"What should we build next?" |
Ordered list with reasoning |
| Scoring |
"Score these 10 features" |
Framework table with scores |
| Opportunity assessment |
"Where's the biggest opportunity?" |
Gap analysis, underserved areas |
| Trade-off analysis |
"Should we do A or B?" |
Side-by-side comparison |
| Scope cut |
"We need to cut scope" |
Keep/cut/defer recommendations |
Detection heuristics
- "rank", "order", "what first", "what next" → Stack rank
- "score", "RICE", "ICE", "rate these" → Scoring
- "opportunity", "gap", "underserved" → Opportunity assessment
- "A or B", "trade-off", "which one", "compare" → Trade-off analysis
- "cut scope", "too much", "reduce", "what can we drop" → Scope cut
Frameworks
RICE (default for scoring mode)
Best for: Large backlogs, cross-team prioritization, when you need a defensible number.
| Feature |
Reach |
Impact |
Confidence |
Effort |
RICE Score |
| {name} |
{users/qtr} |
{0.25-3} |
{50-100%} |
{person-months} |
{R×I×C/E} |
- Reach: How many users affected per quarter
- Impact: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
- Confidence: 100% = high certainty, 80% = medium, 50% = low
- Effort: Person-months of work
ICE (default for quick decisions)
Best for: Fast prioritization, smaller teams, when RICE feels heavy.
| Feature |
Impact |
Confidence |
Ease |
ICE Score |
| {name} |
{1-10} |
{1-10} |
{1-10} |
{I×C×E} |
WSJF (Weighted Shortest Job First)
Best for: SAFe teams, flow-based delivery, when cost of delay matters.
| Feature |
User Value |
Time Criticality |
Risk Reduction |
Job Size |
WSJF |
| {name} |
{1-10} |
{1-10} |
{1-10} |
{1-10} |
{(UV+TC+RR)/JS} |
MoSCoW
Best for: Scope negotiation with stakeholders, release planning.
| Priority |
Features |
Rationale |
| Must have |
{list} |
Without these, the release has no value |
| Should have |
{list} |
Important but not critical for launch |
| Could have |
{list} |
Nice to have, first to cut if time runs short |
| Won't have |
{list} |
Explicitly out of scope for this release |
Value/Effort Matrix
Best for: Visual communication to stakeholders, quick alignment.
HIGH VALUE
│
Quick │ Big Bets
Wins ★ │ (plan carefully)
│
────────────┼────────────
│
Fill-ins │ Money Pit
(if idle) │ (avoid)
│
LOW VALUE
LOW EFFORT HIGH EFFORT
Categorize each feature into a quadrant with one-line reasoning.
Kano Model
Best for: Feature categorization, understanding user expectations vs delight.
| Feature |
Category |
Evidence |
| {name} |
Must-be / Performance / Attractive / Indifferent / Reverse |
{why} |
- Must-be: Expected. Absence causes dissatisfaction. Presence does not delight.
- Performance: More is better. Linear satisfaction curve.
- Attractive: Unexpected delight. Absence does not disappoint.
- Indifferent: Users do not care either way.
- Reverse: Some users actively dislike this.
Weighted Scoring
Best for: Custom criteria, when standard frameworks do not fit.
- Ask user to define 3-5 scoring criteria (e.g., strategic alignment, revenue impact, technical feasibility)
- Ask for weights (must sum to 100%)
- Score each feature 1-10 on each criterion
- Weighted score = sum of (score × weight)
Process
Step 1: Gather Items
If the user provides a list, use it. If not, ask:
- What items need prioritizing?
- What is the context? (quarterly planning, scope cut, new initiative)
- Any constraints? (team size, deadline, dependencies)
Step 2: Select Framework
Auto-select based on mode and context:
| Context |
Recommended Framework |
| "Score these features" (no other context) |
RICE |
| "Quick prioritization" |
ICE |
| SAFe team, mentions "cost of delay" |
WSJF |
| Scope negotiation, release planning |
MoSCoW |
| Stakeholder presentation |
Value/Effort Matrix |
| Understanding user expectations |
Kano |
| Custom criteria mentioned |
Weighted Scoring |
If the user asks for a specific framework, use that one.
Step 3: Score and Rank
For each item:
- Score against the framework dimensions
- Show your reasoning for each score (one line)
- Flag low-confidence scores with
[Assumption]
Step 4: Present Results
Scoring mode: Framework table + ranked list + recommendation
Stack rank mode: Ordered list with one-line reasoning per item
Scope cut mode: Keep/Cut/Defer table with impact assessment:
| Feature | Decision | Impact of Cutting | Recommendation |
|---------|----------|-------------------|----------------|
| {name} | Keep/Cut/Defer | {what we lose} | {why} |
Step 5: Cross-Reference
After prioritizing, suggest:
- "Use
prd to spec the top-ranked item"
- "Run
market-research to validate assumptions in your scoring"
- "Use
lenny-podcast for prioritization frameworks (Sean Ellis on ICE, Shreyas Doshi on LNO)"
Rules
- Always show your reasoning for scores. A number without rationale is useless.
- Flag assumptions explicitly. Scoring with made-up confidence is worse than no scoring.
- Never present a single framework as the "right" answer. Frameworks are lenses, not truth.
- If two items score within 10% of each other, call it a tie and recommend the user make the judgment call.
- For scope cuts, always quantify what is lost by cutting, not just what is saved.
- Prefer fewer, better-scored items over exhaustive lists with thin reasoning.
1---2name: prioritize3description: Feature and initiative prioritization using 7 frameworks (RICE, ICE, WSJF, MoSCoW, Value/Effort, Kano, Weighted Scoring). Auto-detects mode: stack rank, scoring, opportunity assessment, trade-off analysis, or scope cut. Triggers on: "prioritize", "rank these features", "RICE score", "what should we build next", "scope cut", "trade-off".4---56# Prioritize: Feature Ranking and Scoring78Score and rank features, initiatives, or backlog items using established PM frameworks. Auto-detects the right framework and mode from context.910## When to Activate1112- User says "prioritize", "rank these", "what should we build next?"13- User asks for RICE, ICE, WSJF, or any scoring framework14- User needs to make scope cuts or trade-off decisions15- User has a list of features and needs to decide order1617## Modes1819Auto-detect from user phrasing. If ambiguous, ask.2021| Mode | When | Output |22|------|------|--------|23| **Stack rank** | "What should we build next?" | Ordered list with reasoning |24| **Scoring** | "Score these 10 features" | Framework table with scores |25| **Opportunity assessment** | "Where's the biggest opportunity?" | Gap analysis, underserved areas |26| **Trade-off analysis** | "Should we do A or B?" | Side-by-side comparison |27| **Scope cut** | "We need to cut scope" | Keep/cut/defer recommendations |2829### Detection heuristics30- "rank", "order", "what first", "what next" → Stack rank31- "score", "RICE", "ICE", "rate these" → Scoring32- "opportunity", "gap", "underserved" → Opportunity assessment33- "A or B", "trade-off", "which one", "compare" → Trade-off analysis34- "cut scope", "too much", "reduce", "what can we drop" → Scope cut3536## Frameworks3738### RICE (default for scoring mode)39Best for: Large backlogs, cross-team prioritization, when you need a defensible number.4041| Feature | Reach | Impact | Confidence | Effort | RICE Score |42|---------|-------|--------|------------|--------|------------|43| {name} | {users/qtr} | {0.25-3} | {50-100%} | {person-months} | {R×I×C/E} |4445- **Reach**: How many users affected per quarter46- **Impact**: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal47- **Confidence**: 100% = high certainty, 80% = medium, 50% = low48- **Effort**: Person-months of work4950### ICE (default for quick decisions)51Best for: Fast prioritization, smaller teams, when RICE feels heavy.5253| Feature | Impact | Confidence | Ease | ICE Score |54|---------|--------|------------|------|-----------|55| {name} | {1-10} | {1-10} | {1-10} | {I×C×E} |5657### WSJF (Weighted Shortest Job First)58Best for: SAFe teams, flow-based delivery, when cost of delay matters.5960| Feature | User Value | Time Criticality | Risk Reduction | Job Size | WSJF |61|---------|-----------|-------------------|----------------|----------|------|62| {name} | {1-10} | {1-10} | {1-10} | {1-10} | {(UV+TC+RR)/JS} |6364### MoSCoW65Best for: Scope negotiation with stakeholders, release planning.6667| Priority | Features | Rationale |68|----------|----------|-----------|69| **Must have** | {list} | Without these, the release has no value |70| **Should have** | {list} | Important but not critical for launch |71| **Could have** | {list} | Nice to have, first to cut if time runs short |72| **Won't have** | {list} | Explicitly out of scope for this release |7374### Value/Effort Matrix75Best for: Visual communication to stakeholders, quick alignment.7677```78 HIGH VALUE79 │80 Quick │ Big Bets81 Wins ★ │ (plan carefully)82 │83────────────┼────────────84 │85 Fill-ins │ Money Pit86 (if idle) │ (avoid)87 │88 LOW VALUE89 LOW EFFORT HIGH EFFORT90```9192Categorize each feature into a quadrant with one-line reasoning.9394### Kano Model95Best for: Feature categorization, understanding user expectations vs delight.9697| Feature | Category | Evidence |98|---------|----------|----------|99| {name} | Must-be / Performance / Attractive / Indifferent / Reverse | {why} |100101- **Must-be**: Expected. Absence causes dissatisfaction. Presence does not delight.102- **Performance**: More is better. Linear satisfaction curve.103- **Attractive**: Unexpected delight. Absence does not disappoint.104- **Indifferent**: Users do not care either way.105- **Reverse**: Some users actively dislike this.106107### Weighted Scoring108Best for: Custom criteria, when standard frameworks do not fit.1091101. Ask user to define 3-5 scoring criteria (e.g., strategic alignment, revenue impact, technical feasibility)1112. Ask for weights (must sum to 100%)1123. Score each feature 1-10 on each criterion1134. Weighted score = sum of (score × weight)114115## Process116117### Step 1: Gather Items118If the user provides a list, use it. If not, ask:119- What items need prioritizing?120- What is the context? (quarterly planning, scope cut, new initiative)121- Any constraints? (team size, deadline, dependencies)122123### Step 2: Select Framework124Auto-select based on mode and context:125126| Context | Recommended Framework |127|---------|----------------------|128| "Score these features" (no other context) | RICE |129| "Quick prioritization" | ICE |130| SAFe team, mentions "cost of delay" | WSJF |131| Scope negotiation, release planning | MoSCoW |132| Stakeholder presentation | Value/Effort Matrix |133| Understanding user expectations | Kano |134| Custom criteria mentioned | Weighted Scoring |135136If the user asks for a specific framework, use that one.137138### Step 3: Score and Rank139140For each item:1411. Score against the framework dimensions1422. Show your reasoning for each score (one line)1433. Flag low-confidence scores with `[Assumption]`144145### Step 4: Present Results146147**Scoring mode**: Framework table + ranked list + recommendation148149**Stack rank mode**: Ordered list with one-line reasoning per item150151**Scope cut mode**: Keep/Cut/Defer table with impact assessment:152```153| Feature | Decision | Impact of Cutting | Recommendation |154|---------|----------|-------------------|----------------|155| {name} | Keep/Cut/Defer | {what we lose} | {why} |156```157158### Step 5: Cross-Reference159160After prioritizing, suggest:161- "Use `prd` to spec the top-ranked item"162- "Run `market-research` to validate assumptions in your scoring"163- "Use `lenny-podcast` for prioritization frameworks (Sean Ellis on ICE, Shreyas Doshi on LNO)"164165## Rules166167- Always show your reasoning for scores. A number without rationale is useless.168- Flag assumptions explicitly. Scoring with made-up confidence is worse than no scoring.169- Never present a single framework as the "right" answer. Frameworks are lenses, not truth.170- If two items score within 10% of each other, call it a tie and recommend the user make the judgment call.171- For scope cuts, always quantify what is lost by cutting, not just what is saved.172- Prefer fewer, better-scored items over exhaustive lists with thin reasoning.
mshadmanrahman