⚠️ Read this first: these are not a client's numbers. This is a composite worked example built from patterns I see repeatedly — no client data, no real engagement, nothing under NDA. The use cases are the ones that come up in almost every mid-size company; the scores are mine, invented for illustration. What is real is the method: the axes, the scoring rubric, and the arguments that follow. I would rather show you a transparent fake than an anonymised real one you cannot check.
What the matrix is for
A use-case feasibility matrix plots every candidate initiative on two axes — business value and technical feasibility — so that a portfolio argument can be had with evidence instead of enthusiasm. That's the textbook definition, and it undersells what actually happens.
Here is what actually happens. Someone's favourite project lands in the bottom-left, in front of everyone, with the reasoning attached. That is the entire value of the exercise. The plot is not the deliverable — the plot is the device that makes a conversation possible which otherwise gets settled by whoever is most senior in the room.
So the scores have to be defensible. Two of the four columns below are the ones people skip, and they are the ones that do the work.
The scoring rubric
Four dimensions, each 0–5. Value and feasibility set the position on the plot; data readiness and risk decide the sequencing within a quadrant, which is where most of the real argument lives.
| Dimension | What a 5 means | What a 1 means | Evidence I ask for |
|---|---|---|---|
| Business value | Moves a number an executive already reports on | Interesting; nobody's target depends on it | The metric, its current value, and who owns it |
| Technical feasibility | Buildable with the team and platform you have now | Needs capability you do not have and cannot quickly hire | A named person who could start it on Monday |
| Data readiness | The data exists, is accessible, and is trusted today | Data is theoretical, or trapped, or known-bad | A query someone has actually run |
| Risk | Low — failure is cheap and visible | High — regulatory, safety, or silent-failure exposure | What happens when it is confidently wrong |
That last cell is deliberate. For anything with a model in it, the question is never "does it work?" but "how will we know when it stops working, and what does it cost us in the meantime?" A use case that fails loudly is far safer than one that fails quietly, and the rubric should say so.
The eight candidates, scored
A composite mid-size company: roughly 400 staff, a warehouse that works, a small data team, and a board that has asked what the AI plan is.
| # | Use case | Value | Feasibility | Data | Risk | Quadrant |
|---|---|---|---|---|---|---|
| 1 | Support ticket triage & summarisation Route inbound tickets, draft a summary for the agent. | 3.6 | 4.2 | 4.0 | Low | Quick win |
| 2 | Document intake extraction OCR plus structured extraction from supplier paperwork. | 3.8 | 3.6 | 3.4 | Low–Med | Quick win |
| 3 | Churn prediction Flag accounts at risk of not renewing. | 4.0 | 3.4 | 3.6 | Med | Quick win |
| 4 | Automated financial reporting Replace the monthly spreadsheet assembly. | 3.2 | 3.8 | 4.2 | Low | Quick win |
| 5 | Demand forecasting Inventory planning across regions. | 4.5 | 2.4 | 2.2 | Med | Strategic bet |
| 6 | Real-time personalisation Per-session content and offer selection. | 4.4 | 1.8 | 2.0 | High | Strategic bet |
| 7 | Natural-language BI (“chat with your data”) Ask questions of the warehouse in plain English. | 2.8 | 2.0 | 2.8 | High | Trap |
| 8 | Sales-call transcript insights Themes and objections from recorded calls. | 2.2 | 3.9 | 3.2 | Low | Fill-in |
Bubble size is data readiness — bigger means the data is more ready. That third dimension is why #5 and #6 sit where they do: they are not hard because the modelling is hard, they are hard because the data underneath them is not there yet.
Reading the quadrants
- Quick wins — high value, high feasibilityDo these now. They fund the credibility you will need for the strategic bets.
- Strategic bets — high value, low feasibilityWorth doing, not worth starting yet. Each needs a named blocker removed first.
- Fill-ins — low value, high feasibilityCheap and easy. Do them when there is slack, never at the cost of a quick win.
- Traps — low value, low feasibilityDemo well, fail in production. The most important quadrant to name out loud.
The three arguments the scores make for you
1. The two biggest ideas are blocked on data, not on AI
Demand forecasting (#5) and real-time personalisation (#6) have the highest business value on the board — 4.5 and 4.4. They also have the lowest data readiness — 2.2 and 2.0. That is not a coincidence, and it is the single most useful output of the exercise.
Neither is an AI problem. Forecasting is blocked on regional inventory history that lives in three systems with no shared SKU identifier. Personalisation is blocked on the absence of any real-time event pipeline at all. Buying a model does nothing for either. The correct recommendation is to fund the data work and be explicit that it is the prerequisite for both of the board's favourite ideas — which is a far easier sell than "we need better data plumbing," because it now has two named payoffs attached.
2. Natural-language BI is the trap, and it is the one that will be argued about
Use case #7 will be the most contested cell on this page, because it demos beautifully. Someone types a question, a number appears, the room nods.
It scores 2.0 on feasibility and High on risk for one reason: it is the only use case here that fails silently. A wrong join in a generated query does not throw an error — it returns a plausible, nicely formatted number that someone puts in a board pack. Ticket triage failing is visible and annoying. Text-to-SQL failing is invisible and expensive, and the verification cost lands on exactly the analysts the tool was meant to free up. I scored the interface question in more depth in the Architecture Radar assessment on analytical interfaces, where text-to-SQL scores lowest of four options on verifiability.
💡 The reframe that usually lands: the honest version of #7 is not "chat with your data" — it is "a governed semantic layer, with natural language as one interface onto it." That moves the work to the metric definitions, which are valuable regardless of whether anyone ever types a question. Same budget, durable asset, and the demo still works.
3. The obvious quick win is not the best first project
Automated financial reporting (#4) has the best data readiness on the board at 4.2 and the lowest risk. Instinct says start there. I would not.
It scores 3.2 on value, the second-lowest of the quick wins, and finance-adjacent work carries a review burden that eats calendar time without teaching the team much. Ticket triage (#1) has higher feasibility, comparable risk, a visible internal audience, and — the part that matters — it exercises the deployment and monitoring path the team will need for everything else. Sequence the first project for what it teaches the organisation, not only for what it returns. First projects are infrastructure for the second and third.
The sequence that comes out
| Phase | Do | Why this order |
|---|---|---|
| Weeks 1–8 | #1 Ticket triage | Builds the deploy, eval and monitoring path on a low-stakes, visible use case |
| Weeks 6–16 | #2 Document extraction, in parallel | Reuses the same path; different enough to prove the path generalises |
| Weeks 8–20 | Identifier and event-pipeline work | The blocker under both #5 and #6. Starts now because it is the long pole |
| Weeks 16–28 | #3 Churn prediction | First use case where a wrong answer reaches a customer; wants the monitoring to exist |
| Quarter 3+ | #5 Demand forecasting | Only once data readiness clears roughly 3.5. Re-score before committing |
| Not scheduled | #6, #7, #8 | #6 revisits after the event pipeline; #7 reframed as a semantic layer; #8 when there is slack |
Note what the sequence does with the strategic bets: it does not schedule them, it schedules the thing that unblocks them, and sets a numeric threshold for revisiting. A roadmap that says "demand forecasting, Q3" is a wish. One that says "demand forecasting once data readiness clears 3.5, and here is the work that gets it there" is a plan.
What I would want you to push back on
Three honest weaknesses in this method, because a framework that has no failure modes is being sold rather than described.
The scores are judgement, not measurement. A 3.6 is not meaningfully different from a 3.8. The decimals order things; they do not measure them. If two use cases sit within about 0.4 of each other, treat them as tied and decide on something else — the same discipline I apply on the Architecture Radar.
Business value is the softest axis and gets gamed. Everyone's project is high value when they are the one scoring it. The defence is the evidence column: name the metric, its current number, and its owner. Use cases whose value cannot survive that question tend to drop by a point on their own.
A matrix is a snapshot, and feasibility moves. Half of what makes something infeasible today is a missing pipeline that a quarter of work removes. That is exactly why the sequencing section is longer than the plot — the plot tells you where things are, the sequence tells you what changes it.
📋 This is one of four artifacts in a two-week Data & AI Readiness Assessment — alongside a current-state baseline, a north-star target state, and a gap analysis. If the assessment doesn't change a decision you were about to make, we stop there and you owe nothing further. Schedule a briefing if you want to talk through your own list.