AI Use Case Canvas

Most AI ideas die because nobody wrote down what would make them succeed. The 2025 MIT State of AI in Business report (the NANDA study) reviewed 300 disclosed pilots, 150 leadership interviews, and 350 employee surveys, and found that 95% of organizations saw no measurable return from their generative AI initiatives despite an estimated $30–40 billion in spending. The recurring cause was organizational. Teams started to build before the problem, the data, and the success measure were defined.

The canvas exists to catch that gap on one page, before the budget is spent. Each field forces a question that an excited pitch usually skips. What is the problem in real units. What does the status quo already cost. Would a plain rule or report do the job. Does the data even exist. Where does a human stay in control. How will we know, by when, that it worked. The discipline is cheap. Filling the canvas takes twenty minutes; discovering the same gaps after a quarter of engineering takes a quarter.

There is a second, sharper reason to fill it. The same MIT study found that pilots built on purchased tools succeeded about two-thirds of the time, while in-house builds succeeded only about one-third of the time. The build-or-buy field is on the canvas because the default answer is usually buy, and teams that skip the question tend to build generic capability they could have rented. The 5% of pilots that worked shared a pattern the canvas is designed to reproduce: a single well-defined pain point, a specialized tool rather than a from-scratch build, and a measurable target set before any code was written.

Picture Priya looking at four AI ideas her team has floated. Without a canvas, the loudest idea wins, or the one with the most confident ROI slide. With a canvas, the idea that cannot fill in "data and inputs" or "success signal" reveals itself in twenty minutes, and the budget goes to the one that can.

The canvas only works if each entry is concrete enough to be checked later. The difference between a strong canvas and a weak one is almost always specificity. Walk the fields in order; the early ones set up the later ones.

Problem statement. Write the pain, not the product. A weak entry reads "we want to use AI to improve support." A strong entry reads "40% of our ~120 weekly tickets are the same repeat questions, and they sit unanswered for hours during busy periods." The strong version names a who, a frequency, and a felt cost. If your first sentence contains the word "AI," you are describing a solution and have skipped the problem.

Current cost of doing nothing. This is the baseline every later benefit is measured against, so it has to be a number. Weak: "support is slow." Strong: "two engineers lose ~6 hours each per week and median first response is 4 hours." Without this, you cannot prove a win even if you get one.

Why AI, and not a simpler tool. This is the field that kills the most use cases, on purpose. Many ideas pitched as AI are really a missing report, a stale FAQ, or a process fix. A strong entry earns the model: "the questions are phrased a hundred different ways, so keyword routing misses them, and matching intent across phrasings is what a language model is good at." If a WHERE clause or a scheduled report would solve it, name that and stop. AI is the expensive answer; reach for it only when the cheaper ones genuinely fail.

Data and inputs. Be honest about access and quality, because data readiness is the single most common reason AI projects stall. Weak: "we have lots of data." Strong: "18 months of resolved tickets in a system we own and can export, messy but labeled by category, with names we will redact first." A blank or hand-wavy answer here is a finding, not a formality.

Human in the loop. Name the review point, the person, and the authority they keep. Strong: "the assistant drafts a reply and cites the doc it used; a support engineer approves before it sends; AI never auto-sends." Weak: "a human will check it sometimes." If any step lets AI act without review, write that down explicitly and justify it, because that is where the real risk lives.

Success signal and horizon. Pick one measurable signal, a target, and a date. Strong: "median first response on the top 5 question types drops from 4 hours to under 30 minutes within 8 weeks, with no rise in reopened tickets." Weak: "improve customer satisfaction." Aim the horizon at the use case, not at a calendar. A common trap is judging everything on a 12-month payback, which quietly rejects a slower structural win; for an initial pilot, a 6–12 month signal is healthy, and you break anything longer into sub-12-month checkpoints.

Build or buy. Default to buy for generic capability and reserve build for what is specific to you. A strong entry gives the reason: "two vendors already ship suggested-reply features that read our docs; building a custom pipeline would take a quarter to match a two-week pilot." Building generic capability you could rent is one of the most expensive mistakes on this page.

Risks, then decision. Name what a confidently wrong answer breaks, who it hurts, and how you would catch it, including privacy and bias. Then record an actual decision with an owner: back it now, defer it with a named condition, or drop it. A canvas with every field full and no decision at the bottom is a note, not a decision.

The canvas can feel finished while the thinking is still hollow. A few traps recur.

• The solution masquerading as a problem. The first field reads "use AI to summarize tickets." That is a feature, not a pain. Restart and describe what hurts and what it costs, or you will optimize a solution nobody needed.
• The ROI horizon that rejects a good slow win. A use case with a strong three-year payoff fails a rigid 12-month screen and gets dropped. Set the horizon to fit the use case and break long bets into checkpoints, so a real structural improvement is not killed by an arbitrary deadline.
• Building what you could buy. The same 2025 MIT study found in-house builds succeeded roughly half as often as purchased tools. A canvas that defaults to "build" for generic capability is pointing at a likely failure. Make "buy" the starting assumption and force "build" to argue for itself.
• A confident success number with no baseline. If "current cost of doing nothing" is blank, the ROI slide is fiction. You cannot show a 70% reduction without the original figure.
• No human-in-the-loop entry for a high-stakes action. If the AI can send a message, change a record, or move money, and the review field is empty, that is the most dangerous gap on the page, not the least.

On a team, the canvas turns "which AI idea do we fund" from a debate into a comparison. When Priya runs four candidates through the same nine fields, they line up side by side, and the one that cannot fill in data or a success signal stops being a contender. A practical portfolio split many teams use is to put the bulk of effort into quick, high-feasibility wins that build confidence, a smaller share into a strategic bet, and a slice into deliberate learning, with nothing going to the idea that fails its own canvas.

Keep the filled canvases. At the pilot review you reopen the artifact, write the real numbers into the success field, and let the decision line record whether you expand, hold, or stop. That history is what stops the same rejected idea from being re-pitched every quarter as if it were new.

When the decision is "back it now," hand off to the next artifact. If you are building, the AI Coding Session Brief scopes the first session so the assistant gets the goal, the files, and the constraints. If the use case lets AI take action on its own, run the Agent Readiness Checklist before you wire it up, and the MCP Readiness Checklist before you connect it to a real tool. For the success-signal field, the Outcome Over Output note in Better Ways of Working is the companion read. On your next real idea, fill just the first three fields, problem, current cost, and why AI; if you cannot, you have your answer before you have spent a dollar.