You have seen this wall. Forty candidate ideas on stickies, two axes in marker, and the top-right quadrant filling up with winners — the quick wins. Everyone leaves relieved. A portfolio has been chosen.
I have run this exercise myself, more than once, and never questioned the axes. The value axis is fine. The feasibility axis is the problem.
Fig. 1 — The most familiar ritual in enterprise AI. Everyone argues about where the dots go; the axes get a free pass.
Ask what earns a high feasibility score, and it is always the same story. The data is available because someone already curated it. One team is involved because the workflow was cut at the team boundary. Integration is easy — there is none. Legal has no concerns; the pilot never gets near a decision that matters. Score each criterion honestly and they all measure the same thing: how little of the organisation the pilot touches.
Fig. 2 — Each criterion is reasonable on its own. Together they select for the same thing.
So the wall fills up with pilots that route around the mess, and the ones that would have to face it never make the cut. A year later, leadership asks why a dozen pilots succeeded and nothing changed. The pilots were chosen for their inability to cause change.
I have watched this from the inside. The first chatbot we built at a large enterprise would have scored perfectly on feasibility: a retrieval layer over a curated set of documents, one team, no integrations. It worked. It also taught us almost nothing about the organisation, because it was constructed to avoid it. The second solution needed the same knowledge — the same procedures, the same work instructions — and there the learning started: copied sources drift, ownership was unclear, three versions of the truth. The first build gave us a working service and not much else. The findings were all in the second.
The friction the matrix avoids is the information. A pilot that breaks because the ERP cannot supply real-time data has produced a finding — here is where the organisation cannot yet support the work it wants AI to do. The one that sails through confirms what everyone already knew. AI reveals the organisation whether invited to or not, and a selection tool that minimises contact with it is a way of learning as little as possible per euro spent.
- The demoFlawless. Applause in the steering committee.
- The findingsNone. Everything it touched was already solved.
- A year laterStill running. Still alone.
- The demoRough. Questions in the steering committee.
- The findingsWhere real-time work fails. Who owns the data. Which workaround was load-bearing.
- A year laterThe fixes it forced carry the next five solutions.
Fig. 3 — The break is not the cost of the pilot. It is the yield.
I should be careful here, because “pick the hard ones” is bad advice. A broken pilot pays only under discipline, and the discipline is a narrow gate with a failure mode on each side.
On one side, the permanent workaround. The pilot breaks, the team routes around the break to hit the demo date, the workaround stays. Ten pilots later the workarounds are a system of their own — fragile, undocumented, and now the foundation everything else is built on. The break was found, and then buried.
On the other side, paralysis. The break becomes an argument that nothing can start until the foundations are fixed — a two-year data programme before the first service ships. The organisation learns nothing while it waits.
Route around the break, hit the demo date, move on. Ten pilots later the workarounds are the architecture.
Enough repair to keep the pilot moving — and every finding written down with a name, an owner, and a decision date, so it cannot be forgotten.
Nothing starts until the foundations are fixed. Learning waits for perfect conditions, which never arrive.
Fig. 4 — A broken pilot pays only through the gate. Both failure modes bury the finding — one under a workaround, one under a programme.
A pilot run through that gate delivers three things, and the service is only the first.
Fig. 5 — Count all three, and the portfolio changes shape on its own.
So I have started replacing the feasibility question. Instead of how feasible is this? — what will this pilot force us to make true? It forces a system to expose its data, two teams to agree on one version of a procedure, an unwritten rule to get written down at last. Asked this way, a pilot stops being a bet on a demo and becomes a rehearsal: a small, run-once version of the organisation you are trying to become. Some rehearsals should be easy — early on, when the point is confidence. But a portfolio of nothing but easy rehearsals is a decision to stay the organisation you already are.
There is a test, and it takes one meeting. Take your last three AI pilots and write down, for each, what it forced the organisation to fix — a system exposed, an owner named, a procedure reconciled, a workaround retired. Three real answers, and your portfolio is teaching you something. Three blanks, and the matrix has been protecting you from your own findings — the next pilot should be chosen by a different question.
Sources: MIT NANDA — State of AI in Business 2025 (95 percent of pilots without measurable return; the failure detail traces to brittle workflows and missing organisational context, not the models)