How to Prioritize AI Use Cases (the Durable AI Index)

To prioritize AI use cases, score each candidate on three axes, not one: Impact (the business value if it works), Feasibility (how hard it is to build and integrate), and Stickiness (whether your team and process will actually adopt and keep using it). We call this the Durable AI Index. Most teams rank ideas on impact alone, greenlight the flashiest ones, and watch them stall after the demo. The right sequence is to plot use cases on impact versus feasibility, filter the winners through Stickiness, and build from the top-right corner inward: high impact, high feasibility, high adoption first.

Why is ranking AI use cases by impact alone the wrong move?

Impact is seductive because it is easy to imagine. Someone sketches an AI agent that rewrites your entire support queue, the number attached to it is huge, and it jumps to the top of the list. So you build it.

Then it dies. Not because the model was bad, but because nobody restructured the work around it, the reps did not trust it, and the handoffs never changed. This is the pattern behind the MIT finding that 95% of AI pilots deliver no measurable business impact. The pilots were not scored wrong on impact. They were never scored on adoption at all.

Impact tells you what a use case is worth if it lands. It says nothing about whether it will land. Feasibility tells you what it costs to build. Stickiness tells you whether it survives contact with your actual team. You need all three, because a high-impact use case that no one adopts is worth exactly zero, and a zero does not care how big the multiplier in front of it was.

What are the three axes of the Durable AI Index?

Score each candidate use case from 1 to 5 on each axis.

Impact. How much does this move a metric you actually report on: revenue, retention, margin, cycle time, cost to serve? Be specific about which metric. "Improves efficiency" is not an impact score. "Cuts first-response time on tier-1 tickets by half" is.

Feasibility. How hard is this to build, integrate, and maintain? Consider data readiness, the number of systems it has to touch, model reliability for this task, and the compliance surface. A use case that needs clean data you do not have is not feasible yet, no matter how simple the model looks.

Stickiness. This is the one everyone ignores, and it is the reason we built the index. Will the people who are supposed to use this actually use it, week after week, once the novelty wears off? Stickiness is high when the tool sits inside an existing workflow, replaces a task people already hate, has a clear owner, and does not ask anyone to change five habits at once. It is low when adoption depends on goodwill, discipline, or a training session everyone forgets.

A use case that scores 5 on Impact, 4 on Feasibility, and 1 on Stickiness is not a priority. It is a future post-mortem.

How does the impact-versus-feasibility 2x2 fit in?

Start with the classic grid because it is fast and it forces a first cut. Put Impact on the vertical axis and Feasibility on the horizontal, so higher and further right is better. You get four quadrants:

• Top-right, high impact and high feasibility: your quick wins. Do these first.
• Top-left, high impact and low feasibility: big bets. Sequence these deliberately, one at a time.
• Bottom-right, low impact and high feasibility: fillers. Fine for building momentum, easy to overdo.
• Bottom-left, low impact and low feasibility: cut them. No exceptions.

The 2x2 is a great filter and a terrible finish line. It answers "is this worth the work" but not "will this stick." Two use cases can sit in the exact same spot on the grid, and one will thrive while the other rots, entirely because of adoption. That is why the 2x2 is step one, and Stickiness is the step everyone skips.

Why do most teams over-index on impact and ignore stickiness?

Because impact is visible and stickiness is not. Impact shows up in the pitch deck, the board update, the business case. It is the number that gets a project funded. Stickiness only shows up later, quietly, when usage flatlines in month six and no single meeting is responsible for noticing.

There is also a skills gap. Estimating impact feels like finance, and every team has someone who can do it. Estimating stickiness means predicting human behavior inside your specific org: which reps will trust the tool, which manager will quietly route around it, whether the process even has room for the new step. That is harder, less quantifiable, and easy to wave away as a "change management" problem to solve later. Later never comes.

This is why McKinsey found that end-to-end workflow redesign is the number one driver of AI value. The value does not come from the model. It comes from rebuilding the process so the model is load-bearing and adoption is not optional. Stickiness is that insight, turned into a score you apply before you build instead of a regret you file after.

How do you sequence the work: build from the top-right in?

Once every use case has three scores, sequence like this:

1. Rank by Durable AI Index. Combine the three scores, but treat any use case with a Stickiness of 1 or 2 as disqualified until you can raise it, regardless of impact. A brilliant idea nobody will use does not belong at the top of a roadmap.

2. Start where all three are high. The top-right of the grid, filtered for stickiness, is your first build. High impact, real feasibility, strong adoption. These prove the program works and buy you credibility for the harder bets.

3. Build inward. From that corner, move toward use cases that are strong on two axes and fixable on the third. Often the fixable axis is Stickiness, and the fix is process redesign, a clear owner, or embedding the tool where people already work. Do that redesign as part of the build, not after.

4. Sequence big bets one at a time. High-impact, low-feasibility use cases are worth doing, but running three at once guarantees none get the adoption work they need. Land one, make it stick, then start the next.

The point of building from the top-right in is compounding trust. Each use case that actually sticks makes the next one easier to adopt, because the team has stopped assuming AI is a demo that disappears.

Frequently asked

How many use cases should we score at once? Start with 8 to 15. Fewer and you are not really prioritizing; more and the scoring turns into theater. Cast a wide net for candidates, then score honestly and cut hard. Most of the list should not survive the first pass, and that is the process working.

Who should assign the scores? Not one person, and not just the AI enthusiasts. Impact should involve whoever owns the target metric. Feasibility needs someone technical who knows your data and systems. Stickiness needs the people who will actually use the tool, or their frontline manager, because they are the only ones who can honestly predict adoption.

What if a use case has huge impact but low stickiness? Do not build it yet. Treat the low Stickiness as a design problem to solve first: redesign the workflow, find a real owner, shrink the behavior change you are asking for. If you cannot raise Stickiness, the impact is theoretical and the project will join the roughly 80% of AI efforts that RAND found fail to meet their goals, far more than typical IT projects.

Is the Durable AI Index just a fancy priority matrix? The impact-versus-feasibility part is standard. The difference is the third axis. A normal matrix optimizes for what is worth building; the Durable AI Index optimizes for what will still be running a year from now. That one addition changes which use cases reach the top of the list.

Where to start

Prioritizing well is the difference between an AI roadmap that compounds and a graveyard of good demos. Score your candidates on all three axes, cut the ones that will not stick, and build from the top-right in. If you want help running the exercise on your own use-case list, see our services, browse use cases by function on the AI-for hub, or get in touch. To go deeper on the method and the mistakes it prevents, read what a Durable AI Index is and why AI pilots fail.