Prioritize Backlog

Use this when helping a client prioritize their feature backlog during a backlog review or workshop.

---

How it works

1. You provide the client name, backlog (list of features or items), objectives, and constraints
2. The skill selects the right prioritization framework for the team's context, then applies it
3. It returns a framework recommendation, scored and ranked backlog, and a prioritized shortlist ready for client discussion

---

Prompt

You are preparing a backlog prioritization deliverable for Kate's consulting engagement. Before writing, read knowledge/voice-tone-guide.md -- use the internal voice for the analysis and framework selection sections (direct, working-doc tone). The final prioritized list section should be ready for client sharing (compressed, outcome-oriented).

Inputs I will provide:

• Client: {{CLIENT}} (company name, team context, maturity level if known)
• Backlog: {{BACKLOG}} (list of features, initiatives, or items to prioritize -- can be a pasted list, spreadsheet data, or description)
• Objectives: {{OBJECTIVES}} (product objectives, OKRs, success metrics, or strategic goals the prioritization should serve)
• Constraints: {{CONSTRAINTS}} (timeline, team capacity, technical constraints, dependencies, budget, or other limiting factors)

Step 1: Pre-prioritization gate

Before choosing a framework, confirm the team can answer three foundational questions:

1. What problem are we solving? (If the team cannot articulate the problem, they are not ready to prioritize solutions.)
2. Who are we solving it for? (A ranked list without a named audience is just opinions.)
3. How are we measuring success? (Without a success metric, scores are theater.)

If the team cannot answer all three, stop. Help them articulate these first. Any first stab at prioritization is better than no prioritization -- but prioritizing without context is worse than both.

If the team presents an unranked bullet list and says "these are all important," push back. Unordered lists are a symptom of avoiding hard decisions. Add numbers to the list. It will force the most important conversation the team has all week.

Step 2: Select the right framework

Read knowledge/pm-prioritization-frameworks.md (all 9 frameworks). Do NOT default to a single framework. Instead, assess which framework fits this team's context:

Framework Selection Criteria:

Factor	Assessment	Best-Fit Frameworks
Data availability	Do we have customer survey data on importance/satisfaction?	Opportunity Score, Kano
Team maturity	Is the team new to prioritization or experienced?	ICE for new teams, RICE for experienced
Backlog size	How many items? (<10, 10-30, 30+)	ICE/MoSCoW for small, RICE/WSJF for large
Decision speed needed	Quick workshop decision or rigorous analysis?	ICE/MoSCoW for fast, RICE/Opportunity Score for rigorous
Strategic alignment focus	Is this about customer value, business value, or both?	Opportunity Score for customer, Value vs Effort for business
Stakeholder buy-in needed	Do we need the framework to convince skeptics?	RICE (transparent math), Kano (visual model)

Recommend 1 primary framework and 1 backup. Explain the selection in 2-3 sentences. If the inputs are insufficient to choose well, flag it: .

Step 3: Score the backlog

Apply the selected framework to each item. Reference knowledge/pm-prioritization-frameworks.md for the exact formula and scoring guidance.

If using Opportunity Score:

• Score each item on Importance (0-1) and current Satisfaction (0-1)
• Calculate: Opportunity Score = Importance x (1 - Satisfaction)
• Note: this prioritizes problems, not solutions. If the backlog is solution-focused, reframe items as the problems they solve.

If using ICE:

• Impact = value to the customer/business (1-10)
• Confidence = how sure are we this will work? (1-10)
• Ease = how easy is it to implement? (1-10)
• ICE Score = I x C x E

If using RICE:

• Reach = number of customers affected per quarter
• Impact = value per customer (0.25 / 0.5 / 1 / 2 / 3 scale)
• Confidence = percentage confidence (100% / 80% / 50%)
• Effort = person-months
• RICE Score = (R x I x C) / E

If using another framework, follow the formula from knowledge/pm-prioritization-frameworks.md.

For each item, document:

• The score
• Brief rationale (1-2 sentences)
• Key assumptions behind the score
• Confidence level (High / Medium / Low)

Step 4: Rank and group

Produce a ranked list. Then group into tiers:

• Tier 1: Do Now -- Highest priority, clear value, achievable within current constraints
• Tier 2: Do Next -- Strong candidates once Tier 1 is underway or complete
• Tier 3: Evaluate Later -- Promising but needs more data, higher risk, or blocked by dependencies
• Not Now -- Deprioritized with clear reasoning

Step 5: Check against objectives and constraints

Validate the ranking against {{OBJECTIVES}} and {{CONSTRAINTS}}:

• Does the Tier 1 set move the needle on the stated objectives?
• Does it fit within the stated constraints (capacity, timeline, dependencies)?
• Are there dependencies between items that affect sequencing?
• Is there a "must-do" item that scores low but is strategically mandatory? Flag it.

Read knowledge/services-canon.md and reference the user-storywriting-backlog-review service to ensure this deliverable aligns with Kate's stated service scope for backlog reviews.

Step 6: Produce the deliverable

Framework Selection

(2-3 sentences: which framework, why it fits this team, what alternative was considered)

Scored Backlog

Rank	Item	Score	Impact	Effort	Confidence	Rationale
1	(name)	(score)	H/M/L	H/M/L	H/M/L	(1-2 sentences)

(Adjust columns to match the selected framework)

Prioritized Tiers

Tier 1: Do Now

1. (Item) -- (one-line rationale)
2. (Item) -- (one-line rationale)

Tier 2: Do Next (same format)

Tier 3: Evaluate Later (same format)

Not Now (same format, with brief reasoning for each deprioritization)

Selling the Prioritization

When the ranked list meets resistance -- "these are all important," "we can't cut anything," "the business needs all of it" -- use these techniques:

• Unknowns shrink scope, not expand it: "We're less certain about items 5-8. Shipping 1-4 first gives us data to make better decisions about the rest."
• Smallest proof of value: "What's the smallest set that proves the strategy works? Ship that, measure it, then expand."
• Risk framing: "Every item we add to Tier 1 increases the risk that none of them ship well. Fewer items, higher quality, faster learning."
• Make the cut visible: "If we include item X, we lose item Y. Which matters more to [persona]?"

If the client can't agree on priorities, that's a signal -- the team may not have shared understanding of objectives or success criteria. Go back to Step 1.

Trade-offs & Dependencies

• Key trade-offs made in the ranking
• Dependencies that affect sequencing
• Items where the team needs more data before committing

Assumptions to Validate

Assumption	Affects	How to Validate
(assumption)	(which items)	(suggested validation method)

For individual stories, use the k8-user-story skill. Once the prioritized backlog is set, use that skill to break Tier 1 items into well-formed user stories with acceptance criteria.

To transform the prioritized backlog into an outcome-focused roadmap, use the roadmap-reframe skill.

---

Examples

Input

• Client: "TaskFlow, seed-stage B2B project management tool, team of 8 (3 engineers, 1 designer, 1 PM)"
• Backlog: "1. Recurring tasks, 2. Guest access for external collaborators, 3. Gantt chart view, 4. Slack integration, 5. Custom fields on tasks, 6. Time tracking, 7. Template library, 8. Mobile app"
• Objectives: "Primary metric: weekly active teams. Goal: increase from 200 to 500 WAT in 6 months. Secondary: reduce churn from 8% to 5%."
• Constraints: "3 engineers, 1 designer. No mobile expertise on team. Need to ship something meaningful every 2-week sprint."

Output (abbreviated)

Framework Selection: ICE. This is a small, fast-moving team with limited capacity and no customer survey data for Opportunity Score. ICE gives a quick, transparent ranking they can debate in a single session. Backup: MoSCoW for a faster workshop-style cut if the team prefers.

Scored Backlog (ICE):

Rank	Item	I	C	E	ICE	Rationale
1	Recurring tasks	8	9	8	576	High-frequency request, directly tied to daily habit formation (WAT driver)
2	Slack integration	7	8	7	392	Reduces friction for teams already in Slack; supports retention
3	Custom fields	7	7	7	343	Unlocks power users; differentiator for B2B teams with specific workflows
...	...	...	...	...	...	...
8	Mobile app	9	4	2	72	High impact but very low ease -- no mobile expertise on team

Tier 1: Do Now

1. Recurring tasks -- highest-frequency request, high confidence, directly drives WAT
2. Slack integration -- reduces activation friction for new teams

Not Now

• Mobile app --
• Gantt chart view -- scores well on impact but high effort for a 3-engineer team; evaluate after recurring tasks ship