免费在 GitHub 公开

prioritization

Prioritize a feature backlog or list of ideas. Use when the user says "help me prioritize", "prioritize this backlog", "RICE score these", "MoSCoW", "opportunity solution tree", "what should we build first", "rank these features", or has a list of items and needs to decide order - even if they don't explicitly say "prioritization".

中文简介正在准备中。当前显示原文说明。

qa-aman/claude-skills

查看安装方法

包含的文件（1）

SKILL.md3.4 KB

SKILL.md（原文）

安装前可以查看交给 AI 代理的指令内容。

Overview

Based on Continuous Discovery Habits by Teresa Torres + RICE scoring. Torres's key insight: teams prioritize solutions when they should be prioritizing opportunities (unmet user needs). Map opportunities first, then generate solutions. Use RICE to score which opportunity is worth pursuing.

Workflow

Step 1: Separate opportunities from solutions

Before scoring anything, sort the backlog into:

Opportunities - unmet user needs, pain points, desires ("users can't track their progress")
Solutions - specific things to build ("add a dashboard")

Prioritize at the opportunity level. For each opportunity, generate 2-3 possible solutions. This prevents locking into one solution prematurely.

Step 2: Build the Opportunity Solution Tree (optional, for complex backlogs)

Outcome (what business result do we want?)
  └── Opportunity 1 (unmet user need)
        └── Solution A
        └── Solution B
  └── Opportunity 2
        └── Solution C

Step 3: RICE Score each opportunity

Opportunity	Reach	Impact	Confidence	Effort	RICE

Reach - Users affected per period (number)
Impact - Effect per user: 0.25 / 0.5 / 1 / 2 / 3
Confidence - How sure are you: 100% / 80% / 50%
Effort - Person-weeks (number)
Formula: (Reach x Impact x Confidence) / Effort

Step 4: Apply MoSCoW for stakeholder alignment

Use RICE scores to inform MoSCoW bucketing:

Must Have - Highest RICE, directly tied to outcome
Should Have - High value, not critical this cycle
Could Have - Nice to have, cut if pressed
Won't Have - Explicitly out this cycle

Step 5: Identify assumption gaps

Torres's approach: before committing to a solution, list the riskiest assumptions. Flag items where confidence is low and assumptions are untested.

Step 6: Recommend clearly

State: "Focus on X, Y, Z this cycle. Reason: [one sentence per item]."

Anti-Patterns

1. Prioritizing solutions before opportunities Bad: "Should we build a dashboard or a report export?" Good: "The opportunity is: users can't track progress. Which solution best addresses that?"

2. Scoring without assumptions Bad: RICE scores presented as facts. Good: "Confidence = 50% because we haven't validated this with users yet."

3. Everything is Must Have Bad: Stakeholders protect everything by labeling it critical. Good: Force constraint: "You have 3 Must Have slots. Pick 3." Scarcity reveals real priorities.

4. No connection to outcome Bad: Prioritizing features that don't tie to a measurable business outcome. Good: Every top-priority item maps to an explicit outcome at the top of the tree.

Quality Checklist

Opportunities separated from solutions before scoring
RICE scores have stated assumptions
Confidence reflects actual evidence level
MoSCoW: no more than 40% of items in Must Have
Top priorities connect to a stated business outcome
Clear recommendation with reasoning at the end

评价

还没有评价。欢迎分享你的使用感受。

无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

同一仓库的技能

11-star-framework

免费

Rate any product, feature, or experience on the 11-star scale (Brian Chesky's Airbnb thought experiment). Use when user says "rate this experience", "11-star", "star rating", "experience audit", "how good is this", "experience rating", "product audit", "quality assessment", or wants to evaluate product quality and identify improvement paths. Also trigger when user wants to benchmark a feature, assess where a product stands, or map out what "great" looks like - even if they don't explicitly say "11-star".

中文简介正在准备中。当前显示原文说明。