Most AI roadmaps aren't short on ideas. Every team we walk into already has a list — a dozen use cases, a workshop's worth of sticky notes, a slide with three columns of "opportunities." What they don't have is a way to tell which three to actually build first that will still look right in six months.
The framework below is the one we use to get a roadmap from "everything sounds promising" to a short, defensible list. It scores each candidate on three axes, independently, before anyone is allowed to argue for their favorite.
Why enthusiasm-based prioritization fails
Left alone, roadmaps get prioritized by whoever argues loudest in the meeting, or by which use case is easiest to demo. Both produce the same failure mode: a project that looks great in a slide and stalls six weeks into engineering, once someone discovers the data doesn't exist in a usable form, or the "win" was never worth the integration cost. Scoring each use case on the same three axes, before the room debates it, catches that earlier and cheaper.
The three axes
- Business value. What does this use case actually move — revenue, cost, risk, or a customer-facing metric someone already tracks? A use case with no owner asking for it and no metric it touches doesn't score well here no matter how technically interesting it is.
- Data readiness. Does the data this use case depends on exist, and is it accessible, labeled, and clean enough to build on? "We could probably get it eventually" is a different score than "it's already in the warehouse."
- Feasibility. Given the team's current skills, tooling, and the state of the underlying technology, can this actually ship in a reasonable timeframe — not in principle, but with the people you have.
Score each axis 1–5, independently, before combining them. Scoring in sequence, one use case at a time across all three axes, anchors the group on the previous use case's score instead of judging each axis on its own terms.
Scoring, and where it goes wrong
Multiply, don't average. A use case that's a 5 on business value and a 1 on data readiness isn't a middling 3 — it's a project that will stall the moment someone tries to build it. Multiplying the three scores together punishes exactly that combination, where averaging hides it.
The trap: scoring feasibility from a demo
A working proof of concept is not evidence of feasibility at production scale. Score feasibility against what it takes to run reliably in production — monitoring, failure handling, the data pipeline holding up under real volume — not against what it took to get a demo working once.
Who scores, and how
- Score independently, then compare. Have each stakeholder — product, engineering, and whoever owns the data — score every use case on their own before the group discusses it. The disagreements are more informative than the average.
- Where scores diverge most is where to spend the meeting. If engineering rates feasibility a 2 and product rates it a 4, that gap is the actual conversation worth having — not a formality to average away.
- Revisit the scores as you learn. A use case's data readiness score is a snapshot, not a fact. Update it once someone has actually looked at the data, not just asked whether it exists.
What the top of the list should look like
The use cases that score well on all three axes are rarely the most exciting ones in the room. They tend to be narrower in scope, closer to data that already exists, and tied to a metric someone is already accountable for. That's a feature of the framework, not a limitation — it's optimizing for what ships and compounds, not what photographs well in a pitch deck.
The goal of the scoring isn't to produce a number. It's to force the disagreement about priorities to happen on three specific axes, instead of in the abstract.
Have a list of use cases and no confidence in the order? Talk to us — we'll run the framework with your team in a single working session.