How to write an AI problem statement.

Why the problem has to exist on paper before the technology

The single most-documented cause of AI project failure is not the model, the data, or the platform. It is misunderstanding what the project was for. When RAND interviewed 65 practitioners and put the failure rate of AI projects above 80% — roughly twice the rate of IT projects that don't involve AI — their number-one cause was "misunderstandings and miscommunications about the intent and purpose of the project." Not the technology. The problem statement. (rand.org, RRA2680-1)

Downstream, that shows up as spend with nothing to show for it. MIT's NANDA project found that roughly 95% of organizations show no measured P&L impact from their generative-AI spend. That study is preliminary and contested, so use it in exactly its bounded form: not "95% fail," but "almost nobody can show the money on a P&L." (primary PDF) The common thread between the two findings is a document that was never written. You cannot show the money on a P&L if you never named the P&L line the project was supposed to move.

A problem statement is a cheap instrument for an expensive failure. It takes an afternoon and it costs nothing, and it is the one artifact that a vendor, a board, and your own operators can all argue with before money is committed. Everything downstream — the baseline, the acceptance test, the go/no-go — is built on it. If it is wrong, or missing, or written by the party selling you the cure, none of the later discipline can save you. This page is how you write it yourself.

What a real problem statement contains

Five parts. Each one is a specific claim your own people can check, and each one is a place a hollow project falls apart. Miss any of the five and you have a wish, not a problem statement.

The fifth part is the one every vendor-written statement quietly omits — because it is the part that can cost them the sale.

The method

An afternoon, in order. Do not skip to the technology; the technology is not on this page for a reason.

1. Write the complaint first, then strip it. Start with how the problem is actually described in the hallway — messy, specific, human. Then delete every noun that is a technology or a vendor. What survives is a candidate for the one-sentence problem.
2. Find the P&L line before you find the metric. Ask which line of the income statement or which cost center moves if this goes away. If you can't name one, stop — this may be a real annoyance but not a fundable problem. Naming the line first keeps the metric honest.
3. Put a number on the pain from a system of record. Pull the count from the system that already logs it — the ERP, the CMMS, the order system — not from memory and not from a vendor deck. Tag it [counted]. Where you must estimate, do the arithmetic in the open and tag it [estimated]. A metric that cannot be baselined cleanly does not belong in the statement.
4. Name the decision and the person who makes it. Write the sentence "When this works, [name/role] will [do what], and stop [doing what]." If you can't complete it, you have found the hole: nobody has decided what would actually change.
5. Write the kill rule while it is cheap to be honest. Set the pass/fail line and the date now, before anyone is attached to the outcome. Agree it out loud with the person who owns the P&L line. This is the number the acceptance test will later be built against.
6. Read it back with the person who signs the metric. The last check is whether the person who owns that P&L line agrees the statement is fair — the pain, the number, the line, the decision, the kill rule. If they won't sign the problem, you will never get them to sign the result.

A worked example

Clean-room and synthetic — a made-up company, invented numbers, no real operation. Watch what the five parts do to a vague ask.

What landed on the President's desk: "We should use AI to automate our order entry — the vendor says it'll cut errors and save the order desk a ton of time." That is a use case wearing a problem's clothes. It names a technology, promises a benefit, and carries no number, no P&L line, and no way to know if it worked. Run it through the five parts:

Notice what the statement did. It never mentioned AI. It converted "too many orders go out wrong" into a number the CFO can find, a decision the ops manager can act on, and a line in the sand the vendor now has to clear on Meridian's data — not on a demo. The vendor's original pitch ("cut errors, save time") is now measurable, killable, and owned by the buyer. That is the whole job of the problem statement: it moves the pen from the seller's hand to yours. (The pass/fail line then becomes a full vendor acceptance test; the number in part three is the sponsor-signed baseline everything else gets measured against.)

The template

Copy this, fill the blanks, delete the guidance in parentheses. If a blank won't fill, that empty blank is your finding — do not paper over it. One page is the ceiling.

AI PROBLEM STATEMENT — [initiative name]
Owner (signs the metric): [name, role]     Date: [date]

1. THE PROBLEM (one sentence, no technology named)
[Describe the cost, delay, error, or risk you carry today. It must
still make sense with the words "AI," "model," and every vendor name
deleted. If it doesn't, you're describing a solution — rewrite.]

2. THE P&L LINE IT TOUCHES
[Name the single line of the P&L or the cost center that moves if this
is solved — e.g. expedite freight, overtime, scrap, warranty, DSO,
revenue. Precise enough that [finance owner] could point to it.]

3. THE CURRENT PAIN, ON OUR OWN NUMBERS
Volume / rate:  [number] [counted | estimated]  — source: [system of record]
Dollar impact:  $[number] [counted | estimated]  — how derived: [arithmetic]
Measurement window: [e.g. last quarter, trailing 12 months]
[No industry benchmark. No vendor slide. If you can't put any number
here, that blank IS the finding — say so.]

4. THE DECISION THIS WILL INFORM
When it works, [name/role] will [take this action]
and stop [doing this thing they do today].
[If nothing changes downstream, nothing was solved. Name the change.]

5. THE KILL RULE (written before we start)
Pass/fail line: [the metric] must reach [threshold] on [frozen sample]
By this date: [date / pilot length]
If missed: [we stop — no renewal, no "tune it and retry." Say it here.]

Sign-off: the owner above confirms this statement is FAIR — the pain,
the number, the line, the decision, and the kill rule — before any
vendor is engaged.
[signature / date]

The trap: the vendor wrote your problem statement

The most common way this document goes wrong is that it arrives already written — on the vendor's letterhead, inside the proposal, phrased as "the challenge you're facing." It will be articulate, it will flatter your situation, and it will be shaped, in every line, so that the vendor's product is the obvious answer. The party that diagnoses your problem usually sells you the cure — and the diagnosis will always fit the cure.

This is not a claim that vendors are dishonest. It is a claim about incentives. Whoever holds the pen on the problem statement controls what counts as a solution, which numbers get measured, and which kill rule — if any — makes it into the room. A vendor-authored statement will reliably omit part three's honest number (it invites comparison shopping), soften part four's decision into "better visibility" (unmeasurable, so unkillable), and quietly drop part five entirely (a kill rule is a way to lose the renewal). What's left reads like diligence and functions like a sales close.

The defense is not distrust; it is authorship. Write the five parts yourself, on your own numbers, before the first vendor call. Then a vendor can react to your statement, argue your number, or decline the job — all fine. What a vendor must never be is the author of the problem you are paying them to solve. This is exactly why Tektari sells no implementation and takes no vendor commissions: a firm that profits from the cure cannot be trusted to write the diagnosis, so we publish the buyer's-side method instead of selling you the build. (the charter is the promise; this page is the proof.)

Frequently asked

How long should an AI problem statement be?

One page is the ceiling, not the target. The five parts — one-sentence problem, the P&L line it touches, the current pain on your own numbers, the decision it will inform, and the kill rule — fit on a single page with room to spare. If it runs longer, you are either describing more than one problem, or you are describing a solution. Both are failures of the statement, not a case for more pages.

Who should write the AI problem statement — us or the vendor?

You write it, before you talk to a vendor. If the vendor writes your problem statement, the diagnosis will fit their cure — that is not a character flaw, it is the incentive. The party that defines the problem controls what counts as a solution. Keep the pen. A vendor can react to your statement, argue a number, or decline the job; a vendor should never be the author of the problem you are paying them to solve.

What is the difference between a problem statement and a use case?

A use case names a technology and a place to put it — "use AI to triage inbound orders." A problem statement names a cost you are carrying and the number that proves it — "mis-keyed order lines cost us re-work and expedite freight; here is last quarter's count and dollar figure." The use case assumes the answer; the problem statement earns it. If you can write the use case but not the problem statement, you do not yet have a project — you have a solution looking for a justification.

What is a kill rule and why does the problem statement need one?

A kill rule is the condition, written down before you start, under which you stop — a pass/fail line and a date, agreed while nobody is invested in the answer. Without one, pilots do not fail; they fade, get quietly extended, and consume budget without ever producing a decision. The kill rule is what turns a pilot into a decision instead of a habit. Write it when it is cheap to be honest, not after the sunk cost makes it expensive.

Do we need the baseline number before we can write the problem statement?

You need a first, honest number — even a rough one, tagged as an estimate — before the statement is worth anything. "Mis-keyed order lines cost us money" is a complaint; "roughly 4% of order lines were mis-keyed last quarter, ballpark $90,000 in re-work and expedite freight [estimated]" is a problem statement. If you cannot put any number on it, that is itself the finding: you are about to buy a solution to a problem you cannot measure, which means you will never be able to prove it worked.

Where this sits in the guide

This is spoke 01 of the Verification Field Guide. The problem statement is the first artifact; the rest of the guide builds on it. Two you'll want next:

When you're ready to have someone put a problem statement, a signed baseline, and an acceptance test on one real initiative — from a firm barred from selling you the build, with part of its fee riding on the result — that's the Problem-Definition Audit ($12,500 fixed, $2,500 of it invoiced only when the scoped pilot passes its acceptance test). Not sure you're ready? Start with the free Industrial AI Scoreboard and see which band you're in first.