Table of Contents
Most businesses stuck on AI aren’t stuck on capability. They’re stuck because nobody wants to sponsor a twelve-month program for a technology they’ve never seen work in their own building, on their own data, with their own people for their first AI win.
That’s a proof problem, not a technology problem. And proof is what a first AI win is for.
Two weeks is enough to produce it — but only if you’re ruthless about what “it” is. Here’s what the fourteen days actually contain.
Days 1–3: Audit — find out what’s actually slow
Not a technology audit. A time audit.
The work is talking to the people doing the job and asking one narrow question: what takes longer than it should, and what are you doing while it takes that long?
You’re listening for a specific shape. Repeats weekly. Mostly finding or reformatting information that already exists. And a named person can put a number of hours to it.
What comes out is usually five or six candidates, most of them too big. That’s the expected result — the audit isn’t hunting for the most valuable problem, it’s hunting for the most finishable one.
The mistake here is running it as a survey. People describe their jobs as they believe they should be, not as they are. Ask what they did yesterday and you get a different, truer answer.
Days 4–5: Pick — one problem, defensibly chosen
One. Not a phase one of three.
The test is whether you can write it in a sentence containing a person, a frequency, and a consequence:
“Our estimator spends about a day a week finding comparable past jobs, and quotes go out late because of it.”
That’s a scope. “Improve our quoting process” is a wish.
Two checks before it’s locked:
- Is the data usable as it is? Not perfect — usable. If no, this is the wrong first problem however appealing it looks.
- Would anyone notice if it worked? If the improvement is invisible without a report proving it exists, you’ll struggle to get a second project funded.
The mistake here is picking the most important problem instead of the most finishable one. The most important problem touches four systems and three departments. It is not a two-week job, and attempting it is how first projects become last projects.
Days 6–12: Build — narrow, real, and left alone
Seven days. Half the timeline, and the part that surprises people by being the least eventful.
That’s the point. Building is rarely what makes first projects overrun — moving targets are. A scope agreed on day five and genuinely left alone is what makes seven days sufficient. The engineering isn’t faster than anyone else’s; the requirements just stopped changing.
Three things govern whether this holds:
It runs on the real data, not a sample. Sample data hides the problems that matter — the inconsistent field, the records that came across in an acquisition, the exception nobody documented. Better to hit those on day eight than after handover.
It solves the one problem completely rather than four partially. Narrow is not the same as small. Narrow is what finishes.
Nothing gets added. Every “while you’re in there, could it also…” is a request to restart day four. The answer isn’t no — it’s next project, written down where it won’t get lost.
This is also where assumptions start failing, which is uncomfortable and useful. It’s common to discover the data is in better shape than feared in one place and considerably worse in another. Both are worth knowing before anyone commits real budget.
Days 13–14: Handover — make it somebody’s
The stage most often skipped, and the reason pilots die quietly.
Handover means three things. The people who’ll use it have used it — on their own work, with someone present to answer questions. Somebody owns it, and that somebody is a name rather than a department. And what it does and doesn’t cover is written down, so the first person to hit its limits doesn’t conclude the whole thing is broken.
The mistake here is treating the demo as the finish line. A tool nobody has used on real work isn’t finished. It’s built, which is not the same thing.
What two weeks genuinely cannot do
Worth stating plainly, because the honest version of this framing is “a win,” not “a transformation.”
Fourteen days won’t remediate structurally messy data. It won’t integrate four systems. It won’t produce something that scales across the business without further work. And it won’t rescue a problem nobody can describe — no amount of delivery speed compensates for an undefined target.
It also doesn’t suit every business. If your best candidate depends on records that need real cleanup first, the honest sequence is cleanup, then this. That’s a longer conversation and a different post.
The output that matters most isn’t the tool for your first AI win
It’s what you learn about your own operation.
Almost every first project ends with at least one assumption overturned — data that was supposedly clean and wasn’t, a process that three people described differently, a bottleneck that turned out to sit one step upstream of where everyone pointed.
That’s not a side effect. It’s the most valuable thing you get, because it means your second project is chosen with information rather than guesswork. And the second project is usually the one that’s actually worth money.
The tool is the proof. The learning is the return.
Frequently asked questions about AI wins
How small does a first AI win need to be? Small enough that one person can describe it in a sentence and you can finish it without a second phase. If explaining the scope takes a diagram, it’s too big for a first project.
Who needs to be involved? Fewer people than most companies assume. The person doing the work, someone who can make a decision without escalating, and whoever can grant access to the data. A steering committee at this stage is a sign the scope is too large.
What happens after the two weeks? Usually one of three things: extend it to more of the same use case, apply the same pattern elsewhere, or stop. Stopping is a legitimate outcome and cheap at this scale — which is rather the point of starting small.
Where to start
You don’t need a roadmap. You need one problem written in a sentence with a person and a number of hours in it.
If you can write that sentence, you’re ready. If you can’t, that’s the work — and it costs nothing but a few honest conversations with the people doing the job.
Contact us
Not sure you have a problem worth two weeks?
Tell us what’s actually slow — who does it, how often, and what happens when it’s late. We’ll tell you honestly whether it’s a good first project, whether something needs fixing first, or whether you’re better off leaving it alone for now.
All three are real answers we give.
CDO Advisors
Office: 832-819-5744
sales@cdoadvisors.com
