danielpradilla Priority Decision System
Apply the right prioritisation framework to any backlog and produce a clear, defensible ranking with rationale - not just a sorted list.
Required Inputs
Ask the user for these if not provided:
- List of features or initiatives to prioritise
- Goal or metric being prioritised against (OKR, launch, sprint)
- Preferred framework (or recommend based on context below)
- Team data: reach estimates, effort estimates, velocity (for RICE)
Framework Selection Guide
Ask the user which framework they prefer, or recommend based on context:
| Situation | Recommended Framework |
|---|---|
| Need a quick, data-driven score | RICE |
| Stakeholder alignment meeting | MoSCoW |
| Understanding customer delight vs expectations | Kano |
| Early-stage startup, fast decisions | ICE |
| Identifying underserved customer needs | Opportunity Scoring |
| Strategic portfolio decisions | Value vs Effort Matrix |
RICE Scoring
Formula: (Reach × Impact × Confidence) ÷ Effort
| Factor | Definition | Scale |
|---|---|---|
| Reach | Users impacted per quarter | Actual number |
| Impact | Effect on goal per user | 0.25 / 0.5 / 1 / 2 / 3 |
| Confidence | How certain are you? | 50% / 80% / 100% |
| Effort | Person-months required | Actual number |
Output table:
| Feature | Reach | Impact | Confidence | Effort | RICE Score | Priority |
|---|
MoSCoW Method
Categorise each feature as:
- Must Have - non-negotiable for launch/sprint; product fails without it
- Should Have - important but not critical; workarounds exist
- Could Have - nice to have; include only if time allows
- Won't Have (this time) - explicitly out of scope now; may revisit
Always ask: "Must have for what?" - define the scope (launch, sprint, quarter) before categorising.
ICE Scoring (Startup/fast mode)
Formula: Impact + Confidence + Ease (each 1–10)
Quick, subjective - good for early decisions before data exists.
Kano Model
Classify features into:
- Basic (Must-be): Expected; absence causes dissatisfaction
- Performance: More = better satisfaction; linear relationship
- Excitement (Delighters): Unexpected; creates delight; absence is neutral
- Indifferent: Users don't care either way
- Reverse: Some users want it, others don't
Recommend building: all Basic features first → Performance features for key use cases → 1–2 Excitement features per release.
Output Format
Feature Prioritisation - [Product/Team] - [Date]
Framework Used: [RICE / MoSCoW / ICE / Kano / Custom] Scope: [Sprint / Quarter / Release] Goal being prioritised against: [Metric or objective]
[Scored table using selected framework]
Recommended Build Order:
- [Feature] - [1-line rationale]
- [Feature] - [1-line rationale]
- ...
Explicitly Deprioritised:
- [Feature] - Reason: [brief]
Assumptions Made:
- [Any estimates or judgements used in scoring]
Guidelines
- Always anchor prioritisation to a specific goal or metric - never prioritise in a vacuum
- Flag when two features have similar scores but very different risk profiles
- If stakeholder politics are influencing prioritisation, name it explicitly and suggest separating the framework score from the final decision
- Recommend revisiting priorities every 2 weeks minimum
- Never produce a single-column ranked list without rationale - explain the top 3 and bottom 3 decisions
Quality Checks
- Every item is scored against the same goal or metric (not different goals per item)
- Deprioritised items are explicitly listed with reasons (not just absent from the ranked list)
- Assumptions used in scoring are documented
- Stakeholder politics or personal preferences are separated from framework score
- Prioritisation is anchored to a specific scope (sprint / quarter / launch)