Functional Requirements - Learning Module

Loading content...

0/273

Feature Prioritization

The Art of Strategic Saying No

Every product backlog contains more features than any team will ever build. Every system design challenge presents more possibilities than any architecture can optimally support. Prioritization is not an administrative task—it is the most strategic decision a team makes.

The difference between successful products and failed ones often comes down not to what was built, but to what was built first. Companies have collapsed because they prioritized the wrong features at the wrong time. Products have been abandoned by users who couldn't find the one feature they needed—a feature that was deprioritized in favor of seventeen features nobody wanted.

Principal Engineers don't just build systems; they ensure the right systems get built in the right order. This requires frameworks that transform subjective preference battles into objective analysis, and the wisdom to know when subjective judgment must override any framework.

What You Will Master

By the end of this page, you will understand: (1) why prioritization is harder than it appears, (2) the MoSCoW method for binary classification, (3) the RICE framework for quantitative scoring, (4) the Kano Model for customer satisfaction, (5) Value vs. Effort matrices for visual prioritization, (6) opportunity scoring for outcome-driven prioritization, and (7) how to navigate the politics of prioritization decisions.

Why Prioritization Is Harder Than It Appears

Prioritization seems simple: rank features from most important to least important, then build them in order. In practice, it's one of the most contentious and cognitively challenging activities in product development.

The Complexity Sources:

Why Simple Ranking Fails

•Multi-dimensional value — Features create value in different ways: revenue, retention, efficiency, risk reduction. Comparing revenue features to risk-mitigation features is comparing apples to fire extinguishers.
•Stakeholder interests diverge — Sales wants features that close deals. Support wants features that reduce tickets. Engineering wants technical debt reduction. Each stakeholder believes their priority is obvious—and they're all partially right.
•Effort is poorly estimated — A 'quick win' feature turns into a 6-month undertaking. A 'massive' feature takes a week. Prioritization based on incorrect effort estimates produces wrong answers.
•Dependencies constrain order — Feature B requires Feature A. Feature C requires B and D. Optimal priority order becomes a constraint-satisfaction problem, not simple ranking.
•Timing matters — A feature worth building before a competitor launches may be worthless after. A feature that doesn't make sense in v1 becomes critical in v2.
•Opportunity cost is invisible — Choosing Feature A means not building Feature B. The cost of the road not taken is often larger than the value of the road taken.
•Sunk cost bias — Features with significant work already done get prioritized because 'we've invested so much,' even when they should be abandoned.
•HiPPO problem — The Highest-Paid Person's Opinion often overrides analysis. Frameworks exist partly to defend against this.

The Role of Frameworks:

Prioritization frameworks don't solve these problems—they structure the conversation so that assumptions become explicit, trade-offs become visible, and decisions become defensible. A framework is not a calculator that outputs the 'right' answer; it's a thinking tool that ensures you're considering the right factors.

No framework eliminates judgment. But a good framework ensures your judgment is applied to the right questions.

Framework Worship Is Dangerous

Treating any prioritization framework as gospel leads to gaming the system. Teams learn to inflate scores for features they want. Frameworks should inform decisions, not make them. The final call requires human judgment about factors no formula can capture.

MoSCoW Method: Binary Feature Classification

The MoSCoW method is one of the simplest and oldest prioritization frameworks. Rather than ranking features numerically, it classifies them into four categories:

Must have — Non-negotiable requirements; without these, the project fails
Should have — Important but not critical; painful to leave out, but system works
Could have — Desirable enhancements; nice to have if time permits
Won't have (this time) — Explicitly out of scope for this release

The power of MoSCoW lies in its simplicity and its forcing function. Teams must make binary decisions: is this truly 'must have' or merely 'should have'?

MoSCoW Classification Guidelines
Category	Definition	Question to Ask	Typical %
Must Have	System cannot function or ship without it	If this is missing, do we have a product at all?	~60%
Should Have	Important but workarounds exist	Will users be significantly disappointed without it?	~20%
Could Have	Added value but not essential	Would this delight users but they could live without it?	~15%
Won't Have	Explicitly excluded from this scope	Have we agreed this is for later or never?	~5%

The MoSCoW Trap: Everything Is 'Must Have'

The most common failure mode is classifying too many features as 'Must Have.' When 90% of features are 'Must Have,' the method has failed—you've just renamed your backlog.

Techniques for Honest Classification:

Must Have Validation Tests

•The Shipping Test: Would you delay launch by 2 weeks to include this? If not, it's not Must Have.
•The Competitor Test: Would you ship without this if a competitor was launching tomorrow? If yes, it's not Must Have.
•The Stakeholder Test: Would the CEO accept shipping without this? If they'd understand, it's not Must Have.
•The User Test: Would users refuse to use the product without this? If they'd accept a workaround, it's not Must Have.
•The Revenue Test: Would customers refuse to pay without this? If they'd still pay, it might not be Must Have.

moscow-ecommerce.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
# MoSCoW Analysis: E-Commerce MVP Launch
 
## Context
First release targeting 10,000 beta users. Full launch in 6 months.
 
## MUST HAVE (Ship blockers)
| Feature              | Justification                                    |
|----------------------|--------------------------------------------------|
| Product catalog      | Can't sell without displaying products           |
| Shopping cart        | Can't buy multiple items without cart            |
| Checkout flow        | Can't complete purchase without checkout         |
| Credit card payment  | 95% of customers pay by card                     |
| Order confirmation   | Legal requirement + customer expectation         |
| Basic order status   | Support can't function without this              |
 
## SHOULD HAVE (Important but not blockers)
| Feature              | Justification                                    |
|----------------------|--------------------------------------------------|
| Search               | Users can browse categories instead              |
| User accounts        | Can launch with guest checkout only              |
| Order history        | Users can check email confirmations              |
| Wishlist             | Adds value but users can manage externally       |
| Product reviews      | Social proof helps but not essential at launch   |
 
## COULD HAVE (Nice enhancements)
| Feature              | Justification                                    |
|----------------------|--------------------------------------------------|
| Saved payment methods| Convenience, not critical for first orders       |
| Product comparison   | Power user feature                               |
| Social sharing       | Marketing nice-to-have                           |
| Gift wrapping        | Revenue add-on but not core                      |
| Live chat support    | Email support can cover initially                |
 
## WON'T HAVE (Explicitly out of scope for MVP)
| Feature              | Justification                                    |
|----------------------|--------------------------------------------------|
| Mobile app           | Web is mobile-responsive; native app v2          |
| Marketplace (3P)     | First-party only in v1                           |
| Subscription/recurring| Complex billing model for v2                    |
| International shipping| Domestic only for launch                        |
| Cryptocurrency       | <1% of potential customers                       |
 
## Validation
- Must Have: 6 features (54%)
- Should Have: 5 features (18%)  
- Could Have: 5 features (18%)
- Won't Have: 5 features (10%)
 
✓ Healthy distribution. Must Haves are genuinely ship-blocking.

Won't Have Is the Most Important Category

The 'Won't Have' list is often more valuable than the 'Must Have' list. It documents scope boundaries, prevents scope creep, and gives teams permission to say no. An empty 'Won't Have' list indicates the prioritization exercise was incomplete.

RICE Framework: Quantitative Prioritization

Developed at Intercom, the RICE framework provides a quantitative approach to prioritization. It produces a score that allows direct comparison between features, moving beyond subjective 'this feels more important' debates.

The RICE Formula:

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

Each factor is defined and scored as follows:

RICE Scoring Components
Factor	Definition	How to Measure	Scoring
Reach	How many users will this affect in a time period?	Count of affected users per quarter	Absolute number (e.g., 10,000 users/qtr)
Impact	How much will this affect each person?	Contribution to goal (conversion, retention, etc.)	Scale: 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal
Confidence	How sure are we about these estimates?	Evidence strength for reach and impact	Percentage: 100%=high, 80%=medium, 50%=low
Effort	How much work is required?	Person-months of work	Person-months (e.g., 2 = 2 engineer-months)

Understanding Each Factor:

Reach answers: 'How many people will experience this?' Reach is quantified in users or events per time period. A feature affecting 1,000 users per quarter has lower reach than one affecting 50,000 users per quarter.

Impact answers: 'How much will this move our key metric for each person who experiences it?' Impact uses a standardized scale because exact prediction is impossible. A 'massive' impact (3) might be a feature that 2x conversion, while 'minimal' (0.25) is a small convenience improvement.

Confidence answers: 'How sure are we?' This penalizes guesswork. A feature with high reach and impact based on assumptions is less valuable than a feature with moderate estimates supported by data.

Effort answers: 'What does this cost us?' Measured in person-months, effort is the denominator that converts impact into efficiency. High-impact features with low effort score dramatically higher than high-impact features requiring enormous effort.

rice-calculation.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
# RICE Analysis: Q3 Feature Prioritization
 
## Feature A: Smart Search Autocomplete
| Factor     | Value | Justification                                    |
|------------|-------|--------------------------------------------------|
| Reach      | 15,000| 15K users search per quarter                     |
| Impact     | 2     | High: find products faster, +15% conversion      |
| Confidence | 80%   | Similar feature at competitor showed +12-18%     |
| Effort     | 2     | 2 engineer-months                                |
 
RICE = (15,000 × 2 × 0.8) / 2 = 12,000
 
## Feature B: One-Click Reorder
| Factor     | Value | Justification                                    |
|------------|-------|--------------------------------------------------|
| Reach      | 5,000 | 5K returning customers per quarter               |
| Impact     | 3     | Massive: dramatically easier repeat purchase     |
| Confidence | 100%  | Requested by 40% of customer feedback            |
| Effort     | 1     | 1 engineer-month                                 |
 
RICE = (5,000 × 3 × 1.0) / 1 = 15,000
 
## Feature C: AR Product Preview
| Factor     | Value | Justification                                    |
|------------|-------|--------------------------------------------------|
| Reach      | 20,000| All mobile users per quarter                     |
| Impact     | 1     | Medium: cool factor, unclear conversion impact   |
| Confidence | 50%   | No data; competitor has it, unclear if it helps  |
| Effort     | 4     | 4 engineer-months                                |
 
RICE = (20,000 × 1 × 0.5) / 4 = 2,500
 
## Feature D: Guest Checkout
| Factor     | Value | Justification                                    |
|------------|-------|--------------------------------------------------|
| Reach      | 8,000 | 8K cart abandonments per quarter                 |
| Impact     | 2     | High: removes major friction point               |
| Confidence | 90%   | Industry benchmark: +25% conversion to checkout  |
| Effort     | 1.5   | 1.5 engineer-months                              |
 
RICE = (8,000 × 2 × 0.9) / 1.5 = 9,600
 
## Final Priority Order
| Rank | Feature              | RICE Score |
|------|----------------------|------------|
| 1    | One-Click Reorder    | 15,000     |
| 2    | Smart Search         | 12,000     |
| 3    | Guest Checkout       | 9,600      |
| 4    | AR Preview           | 2,500      |
 
Key Insight: AR Preview has highest reach but lowest RICE due to 
uncertainty (low confidence) and high effort. Validation research
could prove value, but shouldn't be built on faith alone.

RICE Limitations

RICE works best for product features with measurable user impact. It struggles with: (1) infrastructure work with indirect value, (2) strategic bets without historical data, (3) regulatory requirements that must be done regardless of score, and (4) features with long-term value that RICE's short time horizons undervalue.

Kano Model: Customer Satisfaction Analysis

The Kano Model, developed by Professor Noriaki Kano in the 1980s, classifies features based on how they affect customer satisfaction. Unlike other frameworks that assume more features = more satisfaction, Kano recognizes that features have different types of relationships with satisfaction.

The Five Kano Categories:

Kano Model Feature Categories
Category	Characteristics	If Present	If Absent	Example
Must-Be (Basic)	Users take these for granted; expected by default	No increase in satisfaction (expected)	Strong dissatisfaction (unacceptable)	E-commerce: can add items to cart
One-Dimensional (Performance)	Linear relationship; more = more satisfied	Satisfaction increases proportionally	Dissatisfaction increases proportionally	E-commerce: faster checkout process
Attractive (Delighters)	Unexpected features that delight	Disproportionate satisfaction increase	No dissatisfaction (wasn't expected)	E-commerce: personalized product recommendations
Indifferent	Users don't care whether present or not	No effect on satisfaction	No effect on satisfaction	E-commerce: internal SKU displayed on invoice
Reverse	Some users dislike the feature	Decreases satisfaction for some	Increases satisfaction for some	E-commerce: social login (privacy concerns)

The Kano Insight: Features Aren't Equal

Kano's fundamental insight is that feature investment should match feature type:

Must-Be features should be done adequately (not over-invested—no ROI on excellence here)
One-Dimensional features should be invested in proportionally to desired satisfaction
Attractive features provide the highest ROI—small investment, disproportionate satisfaction
Indifferent features should be deprioritized or cut entirely
Reverse features require segmentation—understand who likes vs. dislikes

Kano Evolution Over Time:

Critically, features migrate between categories over time. Yesterday's 'Attractive' becomes today's 'Must-Be.'

Feature Category Evolution Examples

•Smartphone touchscreen: 2007 = Attractive (wow!), 2010 = One-Dimensional (better = good), 2015+ = Must-Be (expected)
•Free shipping: 2005 = Attractive (what a deal!), 2010 = One-Dimensional (threshold varies), 2023 = Must-Be (why would I pay?)
•Two-factor auth: 2010 = Attractive (security conscious), 2018 = One-Dimensional (depends on context), 2023 = Must-Be (unsafe without)
•Dark mode: 2018 = Attractive (innovators), 2020 = One-Dimensional (preference), 2023 = Must-Be for many users

kano-questionnaire.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
# Kano Questionnaire: Feature Classification
 
## Methodology
For each feature, ask two questions:
1. "How would you feel if this feature IS present?" (Positive/Functional)
2. "How would you feel if this feature IS NOT present?" (Negative/Dysfunctional)
 
## Response Options
- I like it
- I expect it
- I'm neutral
- I can live with it
- I dislike it
 
## Evaluation Matrix
The combination of responses determines category:
 
                           DYSFUNCTIONAL (If absent)
                    | Like | Expect | Neutral | Live With | Dislike |
    FUNCTIONAL      |------|--------|---------|-----------|---------|
    Like            |  Q   |   A    |    A    |     A     |   O     |
    Expect          |  R   |   I    |    I    |     I     |   M     |
    Neutral         |  R   |   I    |    I    |     I     |   M     |
    Live With       |  R   |   I    |    I    |     I     |   M     |
    Dislike         |  R   |   R    |    R    |     R     |   Q     |
 
Legend:
A = Attractive
O = One-Dimensional  
M = Must-Be
I = Indifferent
R = Reverse
Q = Questionable (answers inconsistent)
 
## Example Feature: "Saved Payment Methods"
 
Survey Results (100 respondents):
- 60 users: Like if present, Neutral if absent → ATTRACTIVE
- 25 users: Expect if present, Dislike if absent → MUST-BE
- 10 users: Neutral if present, Neutral if absent → INDIFFERENT
- 5 users: Dislike if present, Like if absent → REVERSE
 
Categorization: Primarily ATTRACTIVE (60%)
- Investment: High ROI; this delights users
- Segment note: 5% dislike (privacy concerns)—make it optional
 
## Example Feature: "Mobile-Responsive Design"
 
Survey Results (100 respondents):
- 5 users: Like if present, Neutral if absent → ATTRACTIVE
- 85 users: Expect if present, Dislike if absent → MUST-BE
- 8 users: Neutral if present, Dislike if absent → MUST-BE
- 2 users: Neutral if present, Neutral if absent → INDIFFERENT
 
Categorization: Strongly MUST-BE (93%)
- Investment: Must be adequate; no ROI on exceeding baseline
- Risk: Not having this is a dealbreaker for most users

Kano for Strategic Investment

Use Kano to allocate effort strategically: ensure Must-Be features meet expectations (but don't over-invest), invest heavily in Attractive features (highest satisfaction ROI), and continuously improve One-Dimensional features. This maximizes customer satisfaction per engineering dollar spent.

Value vs. Effort Matrix: Visual Prioritization

The Value vs. Effort Matrix (also called an Impact/Effort Matrix or Priority Matrix) is a visual tool that plots features on two axes: the value they deliver and the effort required to build them. This creates four quadrants that suggest prioritization strategy.

The Four Quadrants:

Value/Effort Quadrant Strategies
Quadrant	Characteristics	Strategy	Priority
Quick Wins (High Value, Low Effort)	Maximum return on investment; easy wins	Do these first; build momentum	HIGHEST
Major Projects (High Value, High Effort)	Strategic initiatives; require commitment	Plan carefully; break into phases	HIGH
Fill-Ins (Low Value, Low Effort)	Minor improvements; low stakes	Do when capacity allows; don't obsess	LOW
Time Sinks (Low Value, High Effort)	Waste of resources; high opportunity cost	Avoid or defer indefinitely	AVOID

value-effort-matrix.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
VALUE/EFFORT MATRIX: Q4 Feature Prioritization
 
         ▲ VALUE (High)
         │
         │    MAJOR PROJECTS              QUICK WINS
         │    ┌──────────────────────────────────────────┐
         │    │                          │              │
         │    │  • Platform Migration    │ • Guest      │
         │    │    (12 months, strategic)│   Checkout   │
         │    │                          │   (2 wks)    │
         │    │  • Mobile App            │              │
         │    │    (6 months)            │ • 1-Click    │
         │    │                          │   Reorder    │
         │    │  • Recommendation        │   (1 month)  │
         │    │    Engine (4 months)     │              │
         │    │                          │ • Search     │
         │    │                          │   Filters    │
         │    │                          │   (2 wks)    │
         ├────┼──────────────────────────┼──────────────┤
         │    │                          │              │
         │    │  TIME SINKS              │ FILL-INS     │
         │    │                          │              │
         │    │  • Custom Fonts          │ • Updated    │
         │    │    (6 weeks, minimal     │   Footer     │
         │    │    user impact)          │   Links      │
         │    │                          │              │
         │    │  • Multi-Language        │ • Saved      │
         │    │    (8 months, <1%        │   Search     │
         │    │    current users)        │   History    │
         │    │                          │              │
         │    │  • Crypto Payments       │ • Animation  │
         │    │    (4 months, <0.1%      │   Tweaks     │
         │    │    demand)               │              │
         │    └──────────────────────────┴──────────────┘
     (Low)│
         └─────────────────────────────────────────────▶
              EFFORT (Low)           EFFORT (High)
 
PRIORITY ORDER:
1. Quick Wins (upper right): Guest Checkout, 1-Click Reorder, Search Filters
2. Major Projects (upper left): Schedule based on strategic timing
3. Fill-Ins (lower right): Only if team has spare capacity
4. Time Sinks (lower left): Challenge necessity; likely defer indefinitely
 
ACTION ITEMS:
• Guest Checkout: Start next sprint (2-week quick win)
• Platform Migration: Q1 initiative; requires exec sponsorship
• Custom Fonts: Push back; low value, moderate effort
• Multi-Language: Defer until international expansion decided

Handling Major Projects (High Value, High Effort):

The upper-left quadrant contains the most strategically important—and most difficult—decisions. These features are too valuable to ignore but too expensive to approach casually.

Strategies for Major Projects:

Phase into Quick Wins — Break the large project into deliverable increments that each provide value
De-risk before committing — Invest in prototypes, spikes, or research to validate the value thesis
Sequence strategically — Some Major Projects unlock other features; do those first
Accept the commitment — Some strategic initiatives must be done despite high effort; protect them from interruption

Beware Local Optima

The Value/Effort matrix can lead teams to only chase Quick Wins, never investing in Major Projects that drive long-term success. Quick Wins are efficient, but a portfolio of only Quick Wins builds a feature salad, not a strategic product. Balance short-term wins with long-term investments.

Opportunity Scoring: Outcome-Driven Prioritization

Opportunity Scoring, developed by Tony Ulwick as part of Outcome-Driven Innovation (ODI), prioritizes features based on customer outcomes rather than feature descriptions. It identifies where customers have underserved needs—gaps between how important an outcome is and how satisfied they are with current solutions.

The Formula:

Opportunity Score = Importance + (Importance - Satisfaction)

Or equivalently:

Opportunity Score = (Importance × 2) - Satisfaction

Where Importance and Satisfaction are rated on a scale of 1-10.

The score ranges from -8 to 18, with higher scores indicating larger opportunities.

Opportunity Score Interpretation
Score Range	Interpretation	Action
12+	Extreme under-service; critical gap	Prioritize immediately; major competitive opportunity
10-12	Significant opportunity; clear gap	Strong candidate for investment
6-10	Moderate opportunity; some gap exists	Consider if aligned with strategy
0-6	Appropriately served; needs are met	Maintain; don't over-invest
Below 0	Over-served; investing beyond need	Reduce investment; reallocate resources

opportunity-scoring.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
# Opportunity Scoring: File Sharing App Feature Prioritization
 
## Methodology
Survey 200 users asking for each job/outcome:
1. "How important is [outcome] to you?" (1-10)
2. "How satisfied are you with current ability to [outcome]?" (1-10)
 
## Results
 
| Outcome/Job to Be Done                      | Imp | Sat | Score | Status          |
|---------------------------------------------|-----|-----|-------|-----------------|
| Share files with people outside organization| 9   | 4   | 14    | UNDERSERVED     |
| Track who accessed shared files             | 8   | 3   | 13    | UNDERSERVED     |
| Find files quickly by content               | 9   | 5   | 13    | UNDERSERVED     |
| Collaborate on documents in real-time       | 8   | 6   | 10    | OPPORTUNITY     |
| Access files on mobile devices              | 7   | 5   | 9     | OPPORTUNITY     |
| Organize files in folders                   | 7   | 7   | 7     | SERVED          |
| Upload large files quickly                  | 6   | 6   | 6     | SERVED          |
| View previous versions of files             | 5   | 4   | 6     | SERVED          |
| Customize folder colors/icons               | 2   | 5   | -1    | OVER-SERVED     |
| See animated file previews                  | 1   | 3   | -1    | OVER-SERVED     |
 
## Opportunity Map (Visual)
 
    IMPORTANCE (10) ─────────────────────────────────────
                    │ ★ External sharing     │
                    │ ★ Content search       │ UNDERSERVED
                    │   ★ Access tracking    │ (Prioritize!)
                    │                        │
    IMPORTANCE (7)  ├────────────────────────┼────────────
                    │ ○ Real-time collab     │
                    │   ○ Mobile access      │ OPPORTUNITY
                    │                        │ (Consider)
                    │                        │
    IMPORTANCE (4)  ├────────────────────────┼────────────
                    │                        │
                    │ △ Versioning           │ SERVED
                    │ △ Folders              │ (Maintain)
                    │ △ Large uploads        │
    IMPORTANCE (1)  ├────────────────────────┼────────────
                    │                 × Colors/icons
                    │                 × Animated previews
                    │                        │ OVER-SERVED
                    │                        │ (Deprioritize)
                    └────────────────────────┴────────────
                       SAT (1)                  SAT (10)
 
## Strategic Implications
 
1. IMMEDIATE PRIORITY (Score 12+):
   - External sharing: Core user need, poorly met. Top investment.
   - Access tracking: Security requirement for enterprise. 
   - Content search: Productivity driver, competitive differentiator.
 
2. ROADMAP CANDIDATES (Score 10-12):
   - Real-time collaboration: Trending need, competition entering.
   - Mobile access: Table stakes becoming; don't fall behind.
 
3. MAINTAIN ONLY (Score 6-10):
   - Versioning, folders, uploads: Adequate. No investment needed.
 
4. REDUCE/STOP (Score < 0):
   - Decorative features: Users don't want; stop enhancing.
   - Consider removing to reduce complexity.

Outcomes Over Features

The power of Opportunity Scoring is that it focuses on outcomes users want ('find files quickly') rather than features users request ('add AI search'). Users know their problems better than solutions. This framework captures the problem; solution design remains with engineering.

Weighted Scoring Models: Custom Prioritization

When standard frameworks don't capture your organization's unique priorities, weighted scoring models allow you to define custom criteria and weights. This creates a prioritization system tailored to your strategic context.

Building a Weighted Scoring Model:

Define criteria — What factors matter for prioritization decisions?
Assign weights — How important is each factor relative to others?
Score each feature — Rate every feature on every criterion
Calculate weighted scores — Multiply scores by weights and sum
Rank by total score — Higher scores = higher priority

weighted-scoring-model.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
# Custom Prioritization Model: B2B SaaS Product
 
## Criteria and Weights
 
| Criterion              | Weight | Rationale                                      |
|------------------------|--------|------------------------------------------------|
| Revenue Impact         | 25%    | Direct path to business success                |
| User Adoption          | 20%    | Features users want get used                   |
| Strategic Alignment    | 20%    | Must support company direction                 |
| Effort Required        | 15%    | Lower effort = faster value (inverted)         |
| Tech Debt Impact       | 10%    | Reduces future costs                           |
| Competitive Response   | 10%    | Maintains market position                      |
                         ------
                          100%
 
## Scoring Scale (1-5)
1 = Very Low / Very Hard
2 = Low  
3 = Medium
4 = High
5 = Very High / Very Easy
 
## Feature Evaluation
 
### Feature A: Advanced Analytics Dashboard
 
| Criterion              | Score | Weight | Weighted  |
|------------------------|-------|--------|-----------|
| Revenue Impact         | 5     | 0.25   | 1.25      |
| User Adoption          | 4     | 0.20   | 0.80      |
| Strategic Alignment    | 5     | 0.20   | 1.00      |
| Effort Required        | 2     | 0.15   | 0.30      |
| Tech Debt Impact       | 3     | 0.10   | 0.30      |
| Competitive Response   | 4     | 0.10   | 0.40      |
--------------------------|-------|--------|-----------|
| TOTAL                  |       |        | 4.05      |
 
### Feature B: API Rate Limiting
 
| Criterion              | Score | Weight | Weighted  |
|------------------------|-------|--------|-----------|
| Revenue Impact         | 2     | 0.25   | 0.50      |
| User Adoption          | 3     | 0.20   | 0.60      |
| Strategic Alignment    | 3     | 0.20   | 0.60      |
| Effort Required        | 4     | 0.15   | 0.60      |
| Tech Debt Impact       | 5     | 0.10   | 0.50      |
| Competitive Response   | 2     | 0.10   | 0.20      |
--------------------------|-------|--------|-----------|
| TOTAL                  |       |        | 3.00      |
 
### Feature C: Single Sign-On Integration
 
| Criterion              | Score | Weight | Weighted  |
|------------------------|-------|--------|-----------|
| Revenue Impact         | 5     | 0.25   | 1.25      |
| User Adoption          | 3     | 0.20   | 0.60      |
| Strategic Alignment    | 4     | 0.20   | 0.80      |
| Effort Required        | 3     | 0.15   | 0.45      |
| Tech Debt Impact       | 2     | 0.10   | 0.20      |
| Competitive Response   | 5     | 0.10   | 0.50      |
--------------------------|-------|--------|-----------|
| TOTAL                  |       |        | 3.80      |
 
## Final Ranking
 
| Rank | Feature                    | Score |
|------|----------------------------|-------|
| 1    | Advanced Analytics         | 4.05  |
| 2    | Single Sign-On             | 3.80  |
| 3    | API Rate Limiting          | 3.00  |
 
## Sensitivity Analysis
If Strategic Alignment weight increased to 30% (reducing Revenue to 15%):
- Analytics: 3.95 (still #1)
- SSO: 3.90 (closes gap)
- Rate Limiting: 3.10 (improves slightly)
 
Minor weight changes don't alter priority order, indicating robust ranking.

Weighted Scoring Best Practices:

Building Effective Scoring Models

•Limit to 5-8 criteria — More criteria dilute focus and increase scoring burden
•Weights must sum to 100% — Ensures consistent comparison across features
•Include one cost/effort criterion — Prevents high-impact, impossible-to-build features from dominating
•Define scoring rubrics — 'What does a 4 mean for Revenue Impact?' prevents arbitrary scoring
•Review weights quarterly — Business priorities shift; weights should reflect current strategy
•Perform sensitivity analysis — Would reasonable weight changes alter your top priorities?
•Score as a team — Different perspectives catch biases; average or consensus scores are more reliable

Model Gaming

Any scoring model can be gamed by advocates who learn to inflate their feature's scores. Counter this by: (1) having multiple people score independently, (2) requiring evidence for scores, (3) reviewing outlier scores critically, and (4) remembering that models inform judgment—they don't replace it.

The Political Realities of Prioritization

No discussion of prioritization is complete without acknowledging that prioritization is political. Features represent investments, and investments create winners and losers. Understanding and navigating organizational dynamics is as important as mastering frameworks.

The Stakeholder Landscape:

Common Stakeholder Positions

•Sales prioritizes features that close immediate deals ('If we had X, we'd close this $500K contract')
•Marketing prioritizes features that differentiate in the market or enable campaigns
•Customer Success prioritizes features that reduce churn or support tickets
•Engineering prioritizes technical debt, developer experience, and architectural improvements
•Legal/Compliance prioritizes features mandated by regulations or contracts
•Executives prioritize strategic initiatives, even when unclear to others
•Customers each prioritize their own pain points, assuming everyone shares them

Strategies for Navigating Politics:

Political Navigation Strategies

•Use frameworks as neutral ground — Frameworks provide objective language. 'The RICE score says...' is less confrontational than 'I think your feature isn't important.'
•Make trade-offs explicit — 'We can do A or B this quarter, not both. Which serves our goals better?' forces honest discussion.
•Get executive air cover — When a framework produces priorities, get explicit executive sign-off. This protects decisions from lobbying.
•Acknowledge emotional investment — 'I know this feature is important to you. Help me understand the full impact so it scores correctly.'
•Create transparency — Publish the prioritization criteria, scores, and decisions. Sunlight reduces backroom dealing.
•Commit to cadence — 'We revisit priorities quarterly. If the situation changes, we'll re-evaluate.' Provides hope without caving.
•Reserve capacity for emergencies — Keep 10-15% of capacity unscheduled. This reduces pressure to reprioritize when urgent requests arrive.

Handling the HiPPO (Highest-Paid Person's Opinion):

When executives override prioritization frameworks, you have limited options:

If the override is occasional: Accept it. Executives have context you don't. Reserve your battles for clear mistakes.
If the override is constant: The framework is theater. Either get executive buy-in for the framework or stop pretending it drives decisions.
If the override is harmful: Document your concerns objectively. 'If we do X instead of Y, we risk [specific consequence].' You've done your job; the decision is theirs.

Authority Matters

Prioritization authority must be clear. Who has final say? If it's the PM, the PM must be empowered to make unpopular decisions. If it's an executive committee, the committee must actually meet and decide. Ambiguous authority leads to priority chaos.

Summary: Strategic Feature Prioritization

Prioritization transforms an overwhelming backlog into a focused roadmap. The right framework applied consistently enables teams to deliver maximum value with every sprint.

Key Takeaways

•Prioritization is strategic, not administrative — What gets built first determines product success more than what eventually gets built.
•MoSCoW provides binary clarity — Must Have, Should Have, Could Have, Won't Have forces honest classification. Don't let everything become Must Have.
•RICE quantifies comparisons — (Reach × Impact × Confidence) / Effort enables objective ranking. Useful for product features with measurable outcomes.
•Kano reveals satisfaction dynamics — Must-Be features need adequacy; Attractive features deliver disproportionate satisfaction. Invest accordingly.
•Value/Effort matrices visualize trade-offs — Quick Wins first, Major Projects planned carefully, Time Sinks avoided.
•Opportunity Scoring focuses on outcomes — (Importance × 2) - Satisfaction identifies underserved needs where investment delivers maximum value.
•Weighted scoring customizes frameworks — Build your own model when standard frameworks miss your unique criteria.
•Politics are real; frameworks provide cover — Use frameworks as neutral language; get executive buy-in; make trade-offs transparent.

What's Next:

With features identified, captured in user stories, and prioritized for maximum impact, one critical question remains: What is the smallest thing we can build that validates our assumptions and delivers value? The next page explores MVP Definition—the discipline of scoping minimum viable products that are truly minimal yet genuinely viable.

Page Complete

You now command a complete toolkit for feature prioritization—from simple classification (MoSCoW) to quantitative scoring (RICE) to customer satisfaction modeling (Kano) to visual mapping (Value/Effort) to outcome-driven analysis (Opportunity Scoring). More importantly, you understand that frameworks inform judgment rather than replace it, and that navigating organizational politics is as essential as analytical rigor.