agentleFS
drvossdrvoss/everything-copilot-cli/skills/product/feature-prioritization/SKILL.md

feature-prioritization

Skill48 starsChanged 17 days agoMITView on GitHub

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.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Stop arguing about what to build.

    line 11
  2. Very specific:

    If the backlog spans wildly different audience sizes, prefer RICE over this matrix.

    line 83
  3. Very specific:

    If the team needs a same-meeting decision, ICE is faster.

    line 84
  4. Distinctive:

    Before committing serious resources, run a free-AI reproducibility check: can the core deliverable or value proposition be reproduced with …

    line 157
  5. Distinctive:

    If yes, treat that as a risk signal, not an automatic dead verdict

    line 161
  6. Distinctive:

    Weight the dimensions: If velocity is critical, multiply effort score by 2

    line 193

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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):

Dimension1 (Low)3 (Medium)5 (High)
ImpactNice-to-have, <5% of usersUseful for core segmentCritical path, >30% of users or major revenue
ConfidenceHunch / no data1-2 data pointsValidated by user research / A/B test
Effort5 = lowest (easy)3 = medium1 = 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:

FrameworkBest forTrade-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 teamSimpler but less precise than RICE or this matrix
MoSCoW (Must / Should / Could / Won't)Scope-cutting inside a fixed release, not ongoing backlog rankingCategorical, not a numeric score — pairs well with launch-strategy tiers
Kano Model (Basic / Performance / Delighter)Understanding why a feature matters to satisfaction, not just urgencyRequires 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?

Before committing serious resources, run a free-AI reproducibility check: can the core deliverable or value proposition be reproduced with a single prompt to an off-the-shelf frontier model?

  • If yes, treat that as a risk signal, not an automatic dead verdict
  • Raise the evidence bar on three follow-up questions:
    1. What meaningful differentiation exists beyond the raw capability?
    2. What distribution or go-to-market advantage helps us reach users?
    3. What proprietary assets, workflows, or data make the offer harder to clone?

Also correct for a common false positive: demand does not equal access. Users wanting something is not proof that you can capture that demand. Incumbents, distribution barriers, switching costs, or already-dominant solutions may absorb the opportunity first. Positive signals such as active user requests or live paid advertising in the category mean "the market exists," not "we have a wedge."

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 and assign a short named kill pattern such as no distribution moat, commodity capability, or demand without access so repeated failure modes become recognizable instead of being relitigated
  • Weight the dimensions: If velocity is critical, multiply effort score by 2
  • Use SQL for transparency: Share the scored backlog with stakeholders

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.