You have 14 problems competing for attention. Some are already intents; some are just evidence piling up in the Inbox. Your team can ship two this sprint. Which ones?
If your answer involves a spreadsheet, a RICE score, or a "gut feel" conversation in your next planning meeting, you're guessing. And guessing is how teams ship features that nobody uses.
Problems carry their own evidence. The evidence tells you what matters. Stop scoring and start reading.
Why Traditional Prioritization Breaks Down
RICE, MoSCoW, Value vs. Effort: these frameworks share the same flaw. They ask you to estimate impact before you've built anything. The scores feel precise, but they're invented.
Evidence is different. A problem that real users keep hitting leaves a trail of friction, quotes, and metrics. That trail is your prioritization signal.
It matters more now that drafting is cheap. A coding agent can propose a spec for any of the 14 in minutes. The bottleneck is your review time, so spend it on the problems the evidence says are real.
The Method
Step 1: Count the Reviewed Evidence
The simplest signal: how much reviewed evidence points at this problem?
A problem backed by 9 reviewed friction reports, 3 user quotes, and a metric showing 40% drop-off is not the same as one resting on a single unreviewed feature request from your CEO.
Count what someone has reviewed, not what is merely linked. The intent list shows how many evidence items are linked to each intent, reviewed or not. An item nobody has reviewed is a lead, not a signal. Open the intents that matter and look at which claims read Backed.
| Problem | Reviewed evidence | Source diversity |
|---|---|---|
| Fix export flow | 9 friction, 3 quotes, 1 metric | Support, interviews, analytics |
| Add dark mode | 2 requests | Slack, 1 interview |
| Team permissions | 5 friction, 4 quotes | Interviews, sales calls |
Evidence count is not a score. It's a signal of how real the problem is.
Step 2: Check Source Diversity
Twelve evidence items from the same angry customer are not the same as twelve items from twelve different users across three channels.
Strong signal: friction appearing independently in support tickets, user interviews, AND analytics. Three unrelated sources converging on the same problem means the problem is structural, not situational.
Weak signal: multiple items from one source. Could be a power user with niche needs, a vocal minority, or a one-off incident.
Step 3: Read the Severity
Not all friction is equal. Evidence items carry emotional and operational weight:
- Blocking friction: The user cannot complete their task. ("The export button does nothing.")
- Degrading friction: The user completes the task, but it's painful. ("It takes me 20 minutes to set up a report.")
- Cosmetic friction: Annoying but not harmful. ("The icon looks weird on mobile.")
Three reviewed, blocking friction signals outrank ten cosmetic ones. Always.
Step 4: Find the Dependencies
Some intents unlock others. Before you prioritize in isolation, ask:
- Does this unblock anything else? If fixing authentication enables team features, collaboration features, and shared dashboards, it's a multiplier.
- Does this depend on something unbuilt? If your "real-time notifications" intent requires WebSocket infrastructure you don't have, the infrastructure comes first regardless of evidence weight.
The highest-evidence problem is not always the right one to build next. The one that unblocks the most downstream work often is.
Step 5: Drop the Stragglers
This is the step most teams skip. Look at the problems with:
- 1–2 evidence items
- A single source
- No new evidence in 30+ days
These are ideas, not problems yet. Don't hand them to an agent. Leave their evidence where new signals can join it. If the problem is real, the evidence will grow, and you'll start an intent with actual backing. If it doesn't resurface, you just saved your team from building something nobody needs.
If an agent has already proposed one of these, reject the proposal and say why. The rejection and its reason stay on the record, so the next person who raises the idea can see what was decided and on what evidence.
The Decision Framework
When two problems compete for the same sprint, run through this sequence:
- Evidence and diversity. Which one has more reviewed signal from more sources?
- Severity. Which one involves blocking friction?
- Dependencies. Which one unblocks more downstream work?
- Freshness. Is evidence still arriving, or did it peak three months ago?
You don't need a formula. You need to read the evidence and make the call. The evidence is there to make the call defensible, not to make it automatic.
💡 Tip: If you can't decide between two intents after reading their evidence, they might be the same problem expressed differently. Check whether the evidence overlaps. If it does, treat them as one.
Anti-Patterns
❌ The Roadmap Spec: Cramming a quarter of work into a single intent so it looks bigger. An intent is one problem with one set of outcomes. If it takes more than 2 weeks to build, break it apart.
❌ Priority by Loudness: The stakeholder who emails most gets their intent prioritized. Evidence doesn't care about org charts.
❌ The Score Sheet: Assigning numerical scores to evidence dimensions and summing them into a priority number. You're laundering guesswork through arithmetic. Read the evidence instead.
❌ The Frozen Backlog: Prioritizing once per quarter and never revisiting. Evidence is live. New friction arrives daily. Re-read your backlog every sprint.
Next Steps
- Audit your backlog: Open your intent list and your Evidence Inbox. For the top candidates, check how much of the evidence has actually been reviewed.
- Drop the ghosts: Find the problems with thin evidence and no recent activity. Stop spending review time on them, and reject any proposals already waiting.
- Check dependencies: Map which intents block others. See whether your current sprint order makes sense.