'We need AI' is not a problem statement

Every AI council hears the same sentence sooner or later. We need AI.

It arrives with force behind it, a board directive or a CEO fresh from a competitor's keynote, and nothing ships from it, because there is nothing in it to ship. No baseline, no gap, no owner. It is ambition dressed as a decision.

Ask why enterprise AI projects fail and the post-mortems will blame the model or the change management. Both are real, and both are downstream. The cause that repeats sits upstream of every other: the project was never scoped, so there was never a definition of done. A pilot launched from "we need AI" cannot fail, exactly. It cannot succeed either. It can only run out of budget, and the council that funded it is left arguing about whether the demo felt promising, which is the one debate nobody wins.

In every one of these conversations I have had, the same pattern holds. Specificity beats ambition. The leaders who get AI into production fund a crisply stated business problem with a measurable outcome, and they are suspicious of anything that leads with capability breadth, from their own teams or from vendors. The suspicion is correct. Here is the procedure for acting on it. A CHRO can run it against her own council agenda this week.

The narrowing

Here is the vague ask, walked down step by step. The example is hiring because hiring is what I know best. The procedure works the same for claims or underwriting, and every question in it can be asked in a single council meeting by someone with no technical background at all.

Round one: which workflow? "We need AI in HR" names a function, and a function is too big to have a baseline. Push past it. Say the answer comes back: hiring for frontline sales roles.

Round two: what is the baseline? Pull it from your own systems, never from a vendor deck. Enterprise time-to-hire runs 60 to 120 days. The candidates worth fighting for accept offers inside 30 to 40. If your req-to-hire clock runs longer than the acceptance window, the people you most want are gone before your process finishes evaluating them. The gap is now stated in days.

Round three: what does the gap cost? Count the open seats in the workflow. Multiply by what an unfilled seat fails to produce each month; your finance team has that figure even if nobody in HR has ever asked for it. Add the mis-hires that rushed backfills create, at a reference cost of roughly $500K each. Sum it for the year. The gap now has a dollar figure attached.

Round four: what does success measure? A target on the same baseline: req-to-hire inside the acceptance window, within two quarters, on the dashboard the baseline came from. A project that proposes a new metric for measuring its own success is grading its own homework.

Round five: who owns the number? A name and a line of business. If the answer is "the AI council," nobody owns it. The council governs. The owner lives with the gap.

What comes out the other end reads like this: frontline sales hiring runs at the long end of that 60 to 120 day baseline, req to hire, against a candidate acceptance window of 30 to 40 days. The gap, costed seat by open seat, is a dollar figure the CFO has initialed. Success is req-to-hire inside the window within two quarters, on the existing dashboard. The VP of distribution owns the number.

Five rounds, and a sentence that could never have funded anything has become a problem statement that can survive a budget committee.

The system you end up owning

Scoping also decides what kind of system you own at the end. The unscoped project defaults to an assistant: a chat window that waits to be asked, whose value depends on what your busiest people remember to type into it. The scoped project points at a workflow, and a system pointed at a workflow can work proactively. It reads across every system the workflow touches, drafts the cross-system fix, attaches the cost of action and the cost of inaction, and waits for a human to approve, edit, or decline. That loop is the entire Nodes architecture, already written down at what we do, so I will not re-narrate it here. The council-level point is smaller and sharper: an assistant's ROI is a guess about usage. A workflow's ROI is arithmetic.

The gate is a number

Every proposed workflow states what it costs to run and what the inaction it replaces costs, and the council funds the spread. AI is expensive. Councils know this, and the good ones distrust any proposal that hides the expense behind vision. ROI framing lands because it is the language the rest of the capital-allocation process already speaks. A workflow that cannot state its own ROI is a demo with a steering committee.

Of the two costs, inaction is the harder one to compute and the more persuasive one to present. Inaction never appears as a line item. It appears as open seats and slipped quarters, dispersed across budgets nobody reconciles, which is why an unscoped project always looks expensive and a scoped one often looks overdue.

The gate is also where scoped problems prove out after they ship. The hiring example above is close to home. At a Fortune 500 insurance carrier, a problem scoped this way went into production, and the whole loop from req to hire compressed from 127 days to 38, with the hire rate moving from 14.0% to 27.7% across 6,053 hires. The evidence base is four years of production data and 10,765 agents in the study cohort; the methodology is published in Decision Traces. The council that approved that project approved a number. The ambition came along for the ride.

Map the process first

The discipline underneath all of this is older than AI: understand the process, then automate it. If nobody can draw the workflow today, who touches it and which systems it crosses, then no vendor can automate that workflow. A vendor can only automate a guess at it, and an automated guess is theater billed annually.

Mapping does double duty. It hardens the problem statement, since rounds two and three are impossible without it, and it reveals the sequence: which steps are administrative load that should go first, and which are judgment calls that should keep a human inside them. The sequencing argument deserves its own piece and has one: automate the grunt work first. For scoping purposes the rule is short. A problem statement that names a process nobody has mapped is only half scoped.

The same test, pointed at vendors

Specificity is also the fastest vendor filter you will run. A vendor who can do anything is impossible to evaluate; there is no claim to test and no baseline to beat. The vendor-side mirror of the problem statement is the specific wedge: this workflow, in your environment, against your baseline, measured on your dashboard. A vendor who accepts that framing is making a falsifiable claim and pricing their own accountability. A vendor who keeps widening the conversation is selling you back your own opening line.

Which team inside your organization should run that evaluation is a separate question with its own piece: the three doors into an enterprise covers the org navigation that this one leaves alone.

The checklist

For the next council meeting, run every AI item on the agenda through six questions.

1. Which single workflow does this touch? A function or a theme gets sent back for narrowing.
2. What is the baseline today, and which of our systems did it come from?
3. What does the gap cost per year, in a figure the CFO would initial?
4. What number defines success, on which existing dashboard, by when?
5. Who owns that number? A name and a line of business, never the council itself.
6. Has the process been mapped, by hand if necessary?

Expect most of the agenda to fail question one on the first pass. That is the gate working. Items that survive all six are problems, and problems ship. Items that fail go back for narrowing, which is work a council can assign in a single sentence. If a survivor needs a costed answer faster than an internal build can produce one, a diagnostic pilot is the instrument built for that.

"We need AI" will keep being said, and it should be. It is a fine opening line for a council. The work is the narrowing that follows, and the narrowing can be assigned this week: six questions against every item on the agenda. What comes back will have something no ambition has ever had. A definition of done.

---

Saad Bin Shafiq is the founder of Nodes. Anchor pilot: Fortune 500 insurance carrier, four years of production data, 10,765 agents. Methodology: Decision Traces.