Prioritizing Use Cases & Reading the True Cost

Nearly everyone now has access to the same AI. Almost no one is capturing value from it. The evidence is blunt: MIT Project NANDA's GenAI Divide study (2025) found roughly 95% of enterprise generative-AI pilots delivered no measurable P&L return — and the cause was not weak models but how organizations chose and integrated them.

That failure rate traces back to two executive decisions that get made badly:

1. Choosing the wrong use cases — launching the flagship project where it is visible rather than where it pays, or spreading effort thin across a dozen shallow pilots none of which moves a number.
2. Misreading the cost — approving a budget built around the wrong line items, then watching the real money go somewhere the business case never modeled.

This lesson hands you the two instruments leaders use to get both right: a prioritization framework (what to do and in what order) and a true-cost model (what it actually costs to run, not just to buy). Neither requires a single line of code. Both are squarely your job — not IT's.

"There is no standalone AI strategy. There is only business strategy, strengthened by AI." Prioritization is how you point the capability at the strategy.

The workhorse prioritization tool is a simple 2x2. Plot every candidate use case on two axes:

• Value (business impact) — how much it moves a real number: revenue, cost, customer experience, risk. Tie it to a strategic priority, not to 'using AI.'
• Feasibility (the inverse of effort/risk) — how hard it is to deliver: data readiness, integration complexity, change-management load, governance burden.

That produces four quadrants, and each has a different verdict:

The sequencing rule is the whole point. Do the quick wins first — high-value, high-feasibility work like support assist, internal knowledge search, coding assist, marketing-content drafting, or finance reporting. They pay back fast, prove the model to skeptics, and earn you the political capital to fund the hard things. Then take on the transformational bets — the end-to-end agentic workflows in core functions (claims, underwriting, supply chain, customer journey) that need data foundations, governance, and multi-year commitment.

Doing this in reverse — leading with the moonshot — is how programs stall before they ever show a result.

And re-prioritize quarterly. This is not a one-time exercise. Capabilities, prices, and feasibility shift fast: a use case that was a 'low-feasibility bet' last quarter can become a 'quick win' once a vendor ships a feature or inference gets cheaper. Treat the matrix as a living board, reviewed every quarter.

A single matrix tells you what's worth doing. A horizon allocation tells you how to balance the whole book so you are neither all short-term nor all moonshot. Think of it like an investment portfolio across three time horizons:

The percentages are indicative, not sacred — calibrate them to your maturity and risk appetite. A first-year program might weight near-term even more heavily to bank credibility; a mature program shifts toward capability-building and invention. The discipline is the structure: deliberately spreading bets across horizons so you capture value now and build for later, rather than letting the urgent (productivity) crowd out the important (capability).

Pair this with the same quarterly re-prioritization cadence. As quick wins land and foundations mature, money should migrate up the horizons — from 'make work faster' toward 'reinvent the work' and 'invent new offerings.'

Here is the economics most boards get wrong. Traditional software cost intuition says the big spend is up front — build it, then run it cheaply. AI inverts that.

• Training a model is a large, one-time, CapEx-like spike — and for almost every enterprise, the model maker pays it, not you. You rarely train a frontier model.
• Inference — running the trained model to get each answer — is an ongoing meter that ticks on every single use, forever. Large operators reportedly spend 10-20x more on inference than on training over a model's life.

So the cost you must govern is the running cost, not the building cost. And inference is only part of it. The real money — the part business cases routinely omit — sits in post-deployment operations:

The headline finding: roughly 85% of organizations misestimate AI project costs by more than 10%, and nearly a quarter underestimate by 50% or more (IBM analysis — time-stamped, verify live). The BCG 10-20-70 rule doubles as a budget reality check: only ~10% of effort goes to algorithms and ~20% to tech and data, while ~70% goes to people and process — the part finance loves to leave out of the spreadsheet.

You do not need token math, but you should recognize the three pricing shapes vendors put in front of you — because each has a different budgeting and risk profile.

A durable strategic point sits behind all three: the cost of intelligence is collapsing. The inference cost to reach a given quality level fell roughly 280x in about 18 months (~$20 to ~$0.07 per million tokens, late 2022 to late 2024; Stanford HAI AI Index — time-stamped, verify live). Open-weight models have nearly closed the quality gap.

The implication for every pricing shape: do not lock in long, rigid price commitments, and architect for model portability (the ability to swap the underlying model). What you over-commit to buy today gets dramatically cheaper next year. Keep optionality.

The single most common — and most expensive — early mistake is buying per-seat licenses for the entire workforce on day one.

It feels decisive and egalitarian: roll out the copilot to everyone, declare the company 'AI-enabled.' But the reported reality is sobering: 30-40% of blanket per-seat licenses sit unused within 90 days (industry reports — time-stamped, verify live). You have converted a large, fixed, recurring cost into shelfware, and you've learned nothing about where the tool actually creates value.

The disciplined alternative is the same logic as the value x feasibility matrix, applied to who gets access:

1. Start with high-value cohorts — the teams and roles where the evidence says value concentrates (support, engineering, marketing, finance), not the whole org.
2. Instrument adoption and outcomes — measure usage and whether a real metric moved (quality, throughput, time saved), not just seat counts.
3. Expand on evidence — grow the license footprint where the data shows payback; don't fund seats on faith.

This connects directly to a deeper measurement trap: seat counts and login numbers are vanity metrics. They can even be inversely correlated with value — a single orchestrator running fifty agents shows fewer 'seats' than a department of underusing license-holders. Track the three-tier stack instead: (1) adoption, (2) workflow efficiency, then (3) business/P&L impact. Stopping at seat counts is the trap.

You will not build the matrix or the cost model yourself — your teams will. Your leverage is asking the questions that expose a weak proposal before it gets funded. Keep these on a card:

On prioritization

• Which strategic priority (growth, cost, CX, risk) does this use case move — and what's the number?
• Where does it sit on value x feasibility — is it a quick win we should do now, or a transformational bet we should sequence later?
• Is our portfolio balanced across horizons, or are we all short-term productivity with nothing building capability?
• When did we last re-prioritize this list? (If the answer is over a quarter ago, that's a flag.)

On cost

• Is this a license quote or a true total-cost-of-ownership model? Where are inference-at-scale, data, integration, monitoring, compliance, and the 70% people-and-process cost?
• What happens to cost as adoption — and therefore inference — grows? Does the business case survive success?
• Which pricing shape is this, and are we locking into a long price commitment on a commodity that's getting cheaper?
• Are we buying seats for everyone on day one, or starting with high-value cohorts and expanding on evidence?

On measurement

• Are we tracking seat counts and logins, or actual workflow efficiency and P&L impact? What's the baseline we measured before we started?

A proposal that can't answer these isn't ready — and asking them is the cheapest risk control you have.