feature-prioritization

name	feature-prioritization
description	Use when you have a backlog of features and need to rank them for the next sprint — scores each feature using Impact × Confidence × Effort matrix with SQL tracking for transparent prioritization.
metadata	{"category":"product"}

Feature Prioritization

Stop arguing about what to build. Use a scoring matrix to make prioritization decisions fast, defensible, and transparent. Track everything in SQL so the decision logic is auditable.

The Matrix

Score each feature on three dimensions (1-5 scale):

Dimension	1 (Low)	3 (Medium)	5 (High)
Impact	Nice-to-have, <5% of users	Useful for core segment	Critical path, >30% of users or major revenue
Confidence	Hunch / no data	1-2 data points	Validated by user research / A/B test
Effort	5 = lowest (easy)	3 = medium	1 = highest (hardest)

Score = Impact × Confidence × Effort (higher = higher priority)

Note: Effort scoring is inverted — easy things score higher because ROI is better.

Setup

CREATE TABLE features (
    id TEXT PRIMARY KEY,
    title TEXT NOT NULL,
    description TEXT,
    impact INTEGER,          -- 1-5
    confidence INTEGER,      -- 1-5
    effort INTEGER,          -- 1-5 (5=easy, 1=very hard)
    score REAL,              -- impact * confidence * effort
    status TEXT DEFAULT 'backlog',  -- backlog | in_sprint | shipped | rejected
    notes TEXT,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

Workflow

Step 1: List and Describe Features

> I have the following feature requests for [product area]:
> [paste feature list or backlog items]
>
> For each feature, write a 1-sentence description of the user benefit.
> Then help me think through the scoring dimensions.

Step 2: Score Each Feature

> Let's score each feature against our prioritization matrix.
>
> For [Feature X]:
> - Impact: What % of users does this affect? Is it on the critical path to revenue?
> - Confidence: Do we have user research, data, or is this a hypothesis?
> - Effort: Engineering complexity estimate (S/M/L → 5/3/1)
>
> Challenge my assumptions if something seems over- or under-valued.

Alternative Frameworks

Impact × Confidence × Effort is the default because it is fast and transparent, but it is not the only valid framework. Switch when the situation calls for it:

Framework	Best for	Trade-off vs. this matrix
RICE (Reach × Impact × Confidence ÷ Effort)	Larger backlogs where reach varies widely (e.g., 50 users vs. 50,000)	Adds an explicit reach term instead of folding it into Impact
ICE (Impact × Confidence × Ease)	Fast, low-ceremony triage with a small team	Simpler but less precise than RICE or this matrix
MoSCoW (Must / Should / Could / Won't)	Scope-cutting inside a fixed release, not ongoing backlog ranking	Categorical, not a numeric score — pairs well with launch-strategy tiers
Kano Model (Basic / Performance / Delighter)	Understanding why a feature matters to satisfaction, not just urgency	Requires user surveys; slower than a team scoring session

If the backlog spans wildly different audience sizes, prefer RICE over this matrix. If the team needs a same-meeting decision, ICE is faster. Record which framework was used in the notes column so future prioritization stays comparable.

Step 3: Insert into SQL

INSERT INTO features (id, title, description, impact, confidence, effort, score) VALUES
  ('f1', 'SSO integration', 'Enable login via corporate SSO (Okta, Azure AD)', 5, 4, 3, 60),
  ('f2', 'Dark mode', 'UI theme toggle', 2, 3, 4, 24),
  ('f3', 'Bulk import', 'Import records from CSV', 4, 5, 3, 60),
  ('f4', 'Email digest', 'Weekly summary email to users', 3, 2, 5, 30),
  ('f5', 'Public API v2', 'REST API for third-party integrations', 5, 3, 1, 15);

Step 4: Generate the Priority Stack

-- Prioritized backlog
SELECT id, title, impact, confidence, effort, score,
       RANK() OVER (ORDER BY score DESC) as priority_rank
FROM features
WHERE status = 'backlog'
ORDER BY score DESC;

Step 5: Sense-Check with Copilot

> Here's our prioritized feature list:
> [paste SQL output]
>
> Does this ranking look right to you? Are there any features where
> the score doesn't match your intuition? Flag them and explain why.
>
> Also: are there any dependencies between features we haven't accounted for?

Step 6: Sprint Assignment

-- Move top 3 to current sprint
UPDATE features SET status = 'in_sprint'
WHERE id IN (
    SELECT id FROM features
    WHERE status = 'backlog'
    ORDER BY score DESC
    LIMIT 3
);

Adjustments and Special Cases

Must-Do Items (Compliance, Security)

Some features must be done regardless of score:

-- Force-rank compliance items
ALTER TABLE features ADD COLUMN is_mandatory INTEGER DEFAULT 0;
UPDATE features SET is_mandatory = 1 WHERE id IN ('gdpr-compliance', 'soc2-logging');

Query: mandatory items always come first, then by score.

Strategic Bets

For high-impact, low-confidence, high-effort features (score is low but strategically important):

> Feature [X] scores low because confidence is low. But strategically it could be
> a major differentiator. What's the cheapest experiment to raise confidence?

Example Run

> Score these 5 features from our Q2 roadmap:
> 1. Audit logs (compliance requirement, requested by 3 enterprise prospects)
> 2. Mobile app (requested by community, no revenue signal yet)
> 3. Faster search (top complaint in support tickets, affects all users)
> 4. Zapier integration (medium demand, very quick to build)
> 5. AI summaries (trendy, uncertain user value, long build time)

Expected output: Audit logs and Faster search rank first (high impact + confidence). Zapier ranks high despite moderate demand (low effort = high ROI). AI summaries rank low unless confidence can be raised.

Tips

• Score as a team: Alignment on scoring surfaces hidden assumptions
• Revisit quarterly: Scores change as you learn more and market shifts
• Track rejected features: Record why you said no — prevents relitigating
• Weight the dimensions: If velocity is critical, multiply effort score by 2
• Use SQL for transparency: Share the scored backlog with stakeholders