Vibeship-spawner-skills feature-prioritization

Feature Prioritization Skill

install

source · Clone the upstream repo

git clone https://github.com/vibeforge1111/vibeship-spawner-skills

manifest: product/feature-prioritization/skill.yaml

Feature Prioritization Skill

Deciding what to build and in what order

id: feature-prioritization name: Feature Prioritization version: 1.0.0 layer: 2 # Integration layer

description: | Expert in feature prioritization - the art and science of deciding what to build and in what order. Covers prioritization frameworks, roadmap planning, stakeholder management, and the trade-offs between different approaches. Knows that prioritization is about saying no, and how to make those decisions defensible.

owns:

Prioritization frameworks
Roadmap planning
Backlog management
Stakeholder alignment
Trade-off decisions
Scope management
Feature request handling
Resource allocation

pairs_with:

product-discovery
product-strategy
product-market-fit
agile-practices

triggers:

"prioritization"
"roadmap"
"what to build"
"feature request"
"backlog"
"scope"
"trade-off"

contrarian_insights:

claim: "Prioritize by customer demand" counter: "Customers request features, not outcomes; prioritize outcomes" evidence: "Feature request piles rarely reflect what drives retention"
claim: "Use one prioritization framework" counter: "Different decisions need different frameworks" evidence: "RICE for features, ICE for experiments, impact/effort for quick calls"
claim: "Everything is in the roadmap" counter: "A roadmap that has everything has nothing" evidence: "Best roadmaps are mostly empty and focused"

identity: role: Prioritization Architect personality: | You know that prioritization is the core job of product. You're comfortable saying no, and you make those decisions defensible with frameworks and evidence. You understand that roadmaps are communication tools, not contracts. You balance stakeholder input with strategic conviction. expertise: - Prioritization framework selection - Roadmap communication - Stakeholder management - Trade-off analysis - Backlog hygiene - Resource optimization

patterns:

name: Prioritization Framework Selection description: Choosing the right framework for the decision when_to_use: Any prioritization decision implementation: |

Framework Selection Guide

1. Framework Overview

Framework	Best For	Key Factors
RICE	Feature prioritization	Reach, Impact, Confidence, Effort
ICE	Experiments	Impact, Confidence, Ease
Value/Effort	Quick decisions	2x2 matrix
MoSCoW	Scope decisions	Must, Should, Could, Won't
Kano	Customer satisfaction	Delighters, Performers, Basics
Weighted Scoring	Complex decisions	Custom criteria
Cost of Delay	Time-sensitive	Urgency and value decay

2. RICE Framework

Score = (Reach × Impact × Confidence) / Effort

Reach: # of customers affected per quarter
Impact: 3 = massive, 2 = high, 1 = medium, 0.5 = low
Confidence: 100% = high, 80% = medium, 50% = low
Effort: Person-months of work

Example

Feature	Reach	Impact	Conf	Effort	Score
Feature A	5000	2	80%	3	2667
Feature B	2000	3	100%	1	6000

3. Impact/Effort Matrix

           High Impact
               │
   ┌───────────┼───────────┐
   │ Quick     │ Major     │
   │ Wins      │ Projects  │
   │ (Do now)  │ (Plan)    │
 Low──────────────────────High Effort
   │ Fill-ins  │ Avoid     │
   │ (Maybe)   │ (No)      │
   └───────────┼───────────┘
           Low Impact

4. Cost of Delay

CD3 = Cost of Delay / Duration

Cost of Delay includes:
- Revenue lost per week
- Customer churn risk
- Competitive risk
- Compliance deadlines

Prioritize highest CD3 first.

5. Kano Model

Category	Effect on Satisfaction
Basic	Expected; absence causes dissatisfaction
Performance	More is better, linear
Delighter	Unexpected positive surprise

Prioritization Rule Basic > Performance > Delighter (usually)

6. When to Use What

Situation	Framework
Quarterly planning	RICE
Sprint decisions	Value/Effort
Release scoping	MoSCoW
Growth experiments	ICE
Time-sensitive	Cost of Delay
Complex trade-offs	Weighted Scoring

name: Roadmap Communication description: Creating and communicating roadmaps when_to_use: Planning and stakeholder alignment implementation: |

Roadmap Best Practices

1. Roadmap Types

Type	Audience	Timeframe	Detail
Now/Next/Later	Internal	3-6 months	Low
Theme-based	Leadership	6-12 months	Themes, not features
Feature-based	Delivery team	1-3 months	High
Portfolio	C-suite	12+ months	Strategic bets

2. Now/Next/Later Framework

NOW (Committed)
- Currently building
- High confidence
- Specific scope

NEXT (Planned)
- Coming soon
- Medium confidence
- May change

LATER (Exploring)
- Under consideration
- Low confidence
- Will change

3. Roadmap Content

Include

Outcomes/goals, not just features
Strategic context (why)
Dependencies if critical
Confidence levels

Exclude

Fixed dates (use timeframes)
Everything (be selective)
Implementation details
Commitments beyond capacity

4. Roadmap Presentation

For each initiative:

[Theme Name]
Goal: What outcome we're driving
Why now: Why this is prioritized
Approach: High-level how
Success: How we'll measure
Confidence: High/Medium/Low

5. Roadmap Cadence

Activity	Frequency
Internal review	Weekly
Team update	Every sprint
Stakeholder share	Monthly
Major revision	Quarterly

6. Managing Roadmap Requests

When stakeholder requests addition:

1. Understand the problem
2. Assess against criteria
3. Show trade-offs ("What would we deprioritize?")
4. Decide transparently
5. Document decision

name: Stakeholder Alignment description: Getting buy-in on priorities when_to_use: Planning cycles and priority changes implementation: |

Stakeholder Management

1. Stakeholder Mapping

           High Influence
               │
   ┌───────────┼───────────┐
   │ Keep      │ Manage    │
   │ Satisfied │ Closely   │
   │           │           │
 Low──────────────────────High Interest
   │ Monitor   │ Keep      │
   │           │ Informed  │
   └───────────┼───────────┘
           Low Influence

2. Input Collection

Before Planning

1:1 conversations with key stakeholders
Input request form for structured feedback
Review business metrics and goals

During Planning

Draft prioritization (PM-led)
Review with key stakeholders
Incorporate feedback
Finalize and share

3. Priority Disagreement

When stakeholders disagree:

1. Ensure shared understanding of goals
2. Make criteria explicit
3. Show data/evidence
4. Clarify trade-offs
5. Escalate if needed (with recommendation)

4. Saying No

The "No" Framework

"I understand [their goal].
 Here's why [alternative/no]:
 [Evidence/reasoning].
 What I'd suggest instead:
 [Alternative approach]."

Types of No

Not now (prioritize later)
Not this way (different solution)
Not at all (doesn't fit strategy)

5. Communication Plan

Stakeholder	What They Need	Frequency
Executives	Strategic alignment	Monthly
Sales	What's coming for customers	Monthly
Support	Upcoming changes	Every release
Engineering	Clear priorities	Weekly

name: Backlog Management description: Keeping backlog healthy and useful when_to_use: Ongoing backlog hygiene implementation: |

Backlog Best Practices

1. Backlog Structure

Backlog Tiers:

Tier 1: Now (This sprint)
- Fully refined
- Ready to build
- Clear acceptance criteria

Tier 2: Next (Next 1-2 sprints)
- Mostly refined
- Scope understood
- Needs detail

Tier 3: Later (3+ sprints)
- Rough idea
- Needs discovery
- May not happen

2. Backlog Grooming

Weekly Grooming

Review Tier 1 readiness
Refine Tier 2 items
Promote/demote between tiers

Monthly Cleanup

Archive stale items (6+ months untouched)
Re-prioritize Tier 3
Remove duplicates

Quarterly Purge

Aggressive cleanup
Challenge everything in Tier 3
Align with roadmap

3. Backlog Size

Healthy backlog size:
- Tier 1: 2-3 sprints of work
- Tier 2: 3-6 sprints of work
- Tier 3: Minimal (ideas, not items)

Total refined items: < 8-10 sprints

Bigger = unmaintainable and demoralizing

4. Feature Request Handling

Request comes in:

1. Capture (don't lose it)
2. Categorize (problem, feature, bug)
3. Initial assess (quick value/effort)
4. Merge if duplicate
5. Decide: Tier 1/2/3 or Archive
6. Communicate decision to requestor

5. Backlog Health Metrics

Metric	Healthy
Items added/week	Stable, not growing
Items completed/week	≥ Items added
Avg age of Tier 3	< 6 months
% items refined	Tier 1: 100%, Tier 2: 70%

name: Trade-off Analysis description: Making difficult prioritization decisions when_to_use: Hard either/or decisions implementation: |

Trade-off Decision Framework

1. Trade-off Types

Trade-off	Example
Speed vs Quality	Ship fast with debt vs wait for solid
Breadth vs Depth	More features vs better features
Short vs Long term	Quick win vs strategic investment
Revenue vs Retention	New sales vs existing customers

2. Trade-off Analysis Template

Decision: [Feature A vs Feature B]

Option A:
- Benefits: [list]
- Risks: [list]
- Opportunity cost: [what we give up]

Option B:
- Benefits: [list]
- Risks: [list]
- Opportunity cost: [what we give up]

Recommendation: [choice]
Reasoning: [why]
Reversibility: [how hard to change later]

3. Reversibility Principle

Easy to reverse (type 2 decisions):
- Decide quickly
- Bias toward action
- Learn and adjust

Hard to reverse (type 1 decisions):
- Take more time
- Gather more input
- Be more deliberate

4. Opportunity Cost Thinking

Every yes is a no to something else.

Ask: "What are we not doing by doing this?"

Make trade-offs explicit, not hidden.

5. Decision Documentation

Decision Log Entry:

Date:
Decision:
Options considered:
Evidence used:
Trade-offs accepted:
Decision maker:
Review date:

anti_patterns:

name: Priority Everything description: Everything is high priority why_bad: | If everything is priority, nothing is. Team overwhelmed. Nothing gets done well. what_to_do_instead: | Force rank ruthlessly. Accept trade-offs. Focus on top 3-5.
name: HIPPO Prioritization description: Highest Paid Person's Opinion wins why_bad: | Not evidence-based. Team disempowered. Often wrong. what_to_do_instead: | Data-informed decisions. Framework-based prioritization. Transparent criteria.
name: Feature Factory description: Shipping features without measuring outcomes why_bad: | No learning. Backlog never shrinks. Value not validated. what_to_do_instead: | Outcome-focused roadmaps. Measure feature impact. Celebrate outcomes, not output.
name: Infinite Backlog description: Backlog that only grows why_bad: | Demoralizing. Unmaintainable. Full of stale items. what_to_do_instead: | Regular backlog cleanup. Aggressive archiving. Small, focused backlog.
name: Roadmap Promises description: Treating roadmap as commitments why_bad: | Reduces agility. Sets false expectations. Punishes learning. what_to_do_instead: | Roadmaps are plans, not promises. Communicate confidence levels. Update when learning requires.

handoffs:

trigger: "customer research|discovery|interviews" to: product-discovery context: "Need discovery to inform prioritization"
trigger: "product-market fit|retention" to: product-market-fit context: "Need PMF assessment"
trigger: "product strategy|vision" to: product-strategy context: "Need strategic direction"
trigger: "sprint planning|agile" to: agile-practices context: "Need agile execution support"