Two ways POCs die
Most enterprise AI POCs do not die of technology. They die of two openings. The first: an impressive demo — the model summarizes, answers and generates fluently in the meeting, and two weeks later nobody opens it again. The second: an oversized scope — the POC becomes a smaller version of the big system, with requirement reviews, permission design and system integration piling in until it stalls like any full project. Both share one root cause: treating the POC as a capability showcase instead of a question to answer.
The one question a POC answers
A POC worth running answers exactly one question: if AI enters one action, will the improvement be observable, repeatable and judgeable by the owner? Each word is a gate. Observable means there is a baseline to compare against, not a feeling of “seems faster”. Repeatable means the improvement appears again when the same input recurs, not a one-off stroke of luck. Judgeable means the business owner can say “this counts” or “this does not” by their own standard. If any word fails, the POC ends with an experience nobody can decide on.
Exclude first, compare second
Before scoring candidates, apply three exclusion rules. Exclude high risk: actions that send externally, are irreversible or compliance-sensitive should not host the first validation. Exclude low visibility: if nobody uses the output, even a great optimization will not be adopted. Exclude ownerless: if no one is willing to own the adoption outcome, no one will pick it up when the POC ends. Exclusion matters more than scoring — it prevents exceptions made because something is technically interesting.
Value: an estimate, not a feeling
Value does not need precision, but it needs decomposition: how often the action happens, how much time each occurrence consumes, and what errors or rework cost. Multiply the three and you get a magnitude colleagues can discuss, not a slogan. Also ask in reverse: if nothing changes, what does a year of inaction cost? Some actions save minutes but happen fifty times a day; others run twice a year but are expensive to get wrong. Different magnitudes, different priorities.
Feasibility: inspect the input, not the model
Feasibility is about starting conditions, not model capability. Is the input bounded — can you state what comes in, what it looks like and where it comes from? Is the data obtainable — can consent, format and samples all be secured? Can the output be checked — can someone quickly judge usability? The most common sign of poor feasibility: three system changes must land before validation can start. Then either pick a slice that does not depend on them, or treat the change itself as the first project.
Risk: ask what happens when it errs
Risk is not “will the model err” — it will — but “what happens when it does”. How wide is the blast radius, is it externally visible, can it roll back. Prefer read-only actions for a first validation: AI drafts, suggests and summarizes; a person confirms before anything is written back or sent. A system whose errors live only in a draft and one whose errors reach customers deserve entirely different validation strategies.
Adoption complexity: the ignored dimension
The first three dimensions can be discussed in a meeting room; adoption complexity only becomes visible on site. It asks: whose working habits change? Does the output need approval? How does it coexist with existing systems? A technically simple POC that asks sales reps to change habits fails far more often than a moderately technical one embedded in the existing flow. The assessment is plain: bring in the people who run the action and ask, “if this extra step existed every day, would you do it?”
Write the validation plan before starting
Five things must be written down before the POC starts: the baseline — current time, error rate or latency; where the evaluation set comes from — which samples judge quality; who confirms the result — the judge and their standard; when to stop — the time box or failure condition; and under what conditions to expand — what must be true before growing from one action to the process. Without this plan the closing discussion is about impressions; with it, the discussion is a reviewable conclusion.
Two weeks is a fair time box
Set the first validation's time box at two weeks. Two weeks is not enough for a conclusion, but enough for signals: real usage counts, the rate at which people edit AI output, and the owner's direct feedback. These three signals are more honest than any report. If after two weeks there are no signals at all — nobody uses it, nobody edits it, nobody comments — that is itself the result: the problem is not the model but the process choice or the adoption conditions.
Four common anti-patterns
First, starting with the hardest process — most valuable, and least likely to run inside a time box. Second, starting with model selection — the direction is decided by the process; models affect cost and quality at the margin. Third, turning the POC into a procurement argument — validation exists to learn whether, where and how, not to endorse a shopping list. Fourth, having no “do not adopt” option — a POC that will “succeed” regardless of results is not a validation but a ritual.
When the model enters
Model selection has its place — after the process judgment. Swapping a stronger or cheaper model into the same workflow changes unit cost and error rate; but if the process is not worth doing, no model rescues it. Fix the action, the boundaries and the judgment standard first, then keep the model a swappable variable — which is why a healthy POC never hard-codes the model.
Write the judgment as one shareable page
This exclusion-and-scoring exercise should not stay in the meeting room. Write it as one page: candidate processes, scores on the four dimensions, exclusion reasons, the definition of the first slice, and the validation plan. The page exists so colleagues who missed the meeting can challenge your judgment — a choice that survives challenge is one worth two weeks. The opportunity map we deliver in a guided diagnostic is, in essence, the complete version of this page.