Choosing Your First AI Use Case

“Start small” is not selection advice. It rules out the largest candidate and leaves you with everything else. What you need is an ordering over the twelve ideas already on the list, and an ordering needs weights.

The question people ask first

The usual opening question is where could AI add the most value, and it produces a shortlist of the most valuable processes in the company: pricing, underwriting, clinical triage, the thing the business is actually made of. Those are the worst possible first projects — not because they are hard technically, but because they are where a wrong answer costs the most and where the approval path is longest.

The better opening question is where can we learn the most per week of elapsed time. A first project buys two things at once: a business outcome, and an organisational capability — a security review you have now been through once, a cost model you now know how to build, an evaluation harness that exists in a repository. For exactly one project the second is worth more than the first, and the rubric below is weighted accordingly.

The five axes

Five axes, each scored 1–5, each with a question that decides the score rather than a feeling that suggests it.

Note what is deliberately absent: technical novelty, strategic alignment, and executive enthusiasm. The first is not a benefit, the second is unfalsifiable, and the third is an input to whether a project survives rather than to whether it should be first.

Score the axes with the people who would do the work, not in a planning meeting, and score them one candidate at a time rather than one axis at a time. Both details matter more than they sound. The people doing the work are the only ones who know that the “single system” has three exports and a nightly job that fails on Mondays. And scoring by axis across candidates invites relative grading — this one is more measurable than that one — when what the rubric needs is an absolute judgement against the anchor definitions above, so that scores from different sessions can be compared at all.

The rubric

The weights, and the reason for each. These are the weights for a first project; the second one is scored differently, and the last section says how.

score = 0.30 * measurability
      + 0.25 * data_readiness
      + 0.20 * failure_cost      (inverted: cheap failure = 5)
      + 0.15 * blast_radius      (inverted: small radius  = 5)
      + 0.10 * value

each axis scored 1..5, so score lands in 1..5

Value is weighted lowest and that is not an oversight. On a first project the binding constraint is almost never the size of the prize; it is whether anyone will be able to tell what happened, and whether the project finishes before its sponsor’s attention moves. A high-value project you cannot measure produces an argument rather than a decision, and arguments are settled by seniority.

Measurability carries the most weight because it is the axis that turns this project into evidence for the next three. Data readiness is second because it is the axis most often scored optimistically — the honest score is not what exists in principle but what the pilot team can read on the day the pilot starts.

Two candidates, scored

Both candidates are invented for the example; the point is the shape of the result, not the specific numbers. Candidate A is drafting replies to inbound support email. Candidate B is summarising customer calls into the CRM.

axis             w     A: support drafts     B: call summaries
measurability  0.30    4  (handle time is    2  (no metric today;
                            already logged)       "CRM quality")
data_readiness 0.25    4  (one helpdesk)     2  (recordings in a
                                                  second system,
                                                  consent flags TBD)
failure_cost   0.20    4  (agent edits        3  (a wrong summary is
                            before sending)       read weeks later)
blast_radius   0.15    4  (one team,          2  (sales process
                            one screen)            changes)
value          0.10    5  (large team)        3  (nice to have)

A = .30*4 + .25*4 + .20*4 + .15*4 + .10*5 = 4.10
B = .30*2 + .25*2 + .20*3 + .15*2 + .10*3 = 2.30

A wins by a wide margin, and the interesting part is why. B is a perfectly reasonable idea and would survive a conversation about value. It loses on measurability and data readiness — the two axes that decide whether the project produces a decision at all, rather than how large the decision is. Score your own list and expect at least one reordering: the candidate everyone assumed was first usually loses on an axis nobody was scoring.

Change one input to see how sensitive the ranking is. If B’s team already tracked a CRM completeness metric with a year of history, its measurability goes from 2 to 5 and its total rises to 3.20 — still behind, but close enough that the data-readiness gap becomes the whole argument, which is a far more productive argument to be having.

The disqualifiers

Four conditions that remove a candidate from the list regardless of its score, because the rubric quietly assumes all four.

• No named owner on the receiving side. Not a sponsor — the person whose team’s work changes. If they have not agreed, the score is decoration.
• The output is unreviewable. If nobody can tell a good output from a bad one without redoing the whole task, you cannot evaluate it, cannot monitor it, and cannot attribute anything to it.
• It needs data you may not lawfully use for this. Special-category data, data collected under a purpose that does not cover this, or a customer contract that forbids a new sub-processor. That is a legal review question and it is far cheaper to ask before scoring than after building.
• It only works if the model is right every time. A task with no tolerance for a wrong answer and nowhere to put a reviewer is not a first project; it is a control-systems project wearing a first project’s clothes.

One last note on what changes for project two. Once the capability has been bought — review passed, cost model built, evaluation harness written — the weights invert. Measurability and blast radius matter less because the machinery now exists; value rises to the top because nothing structural is stopping you from going after it. Keep the rubric and reweight it deliberately, rather than letting the first project’s criteria harden into permanent policy.