The sprint that dies in the demo
Here's the failure mode I see most at growth-stage B2B companies. A team runs a four-week "AI sprint," and on the final Friday they present a polished demo: the model answers a sample question beautifully, everyone nods, the deck gets shared, and then nothing ships. Three months later the workflow it was supposed to fix is still being done by hand. The sprint produced a demo, not a working system — and the gap between those two things is where most of the money disappears.
A demo runs once, on data someone cleaned the night before, with the founder driving the keyboard. A workflow runs forty times a week, on messy live inputs, with a support rep or an analyst driving — someone who will abandon it the first time it confidently invents an answer. McKinsey's State of AI research and IBM's Institute for Business Value AI capabilities research keep landing on the same point: the value shows up when AI is wired into how work actually moves, not when it's demoed in isolation. So the test for a 30-day sprint is brutally simple. By day 31, are real people doing real work through it without you in the room? If not, you bought a demo.
That constraint also tells you what to pick. At a 50-to-200-person company you don't have the slack to attempt the moonshot in a month. The right candidate is narrow, repetitive, painful, and — this is the part teams skip — reviewable, meaning a human can glance at the output and know in five seconds whether it's wrong. Ticket triage, account research before a sales call, first-draft proposal sections, CRM hygiene, finance variance notes, knowledge-base intake. Pick the one your team already complains about on a Tuesday.
What weeks two and three actually decide
The sprint week that separates a scale decision from a dead demo isn't the build week — it's the week you make the boring governance calls, because those are the ones that bite at volume. I treat NIST's AI Risk Management Framework as the working agenda here, not as a compliance afterthought: map the context, measure the behavior, manage the risk, and name who owns the workflow after the consultants or the internal champion move on. You decide these in week two of a four-week sprint, not after scale, because every one of them changes the build.
Make them concrete. Say a 90-person services firm is building AI-assisted ticket triage. Before a single prompt gets tuned, somebody answers: What source data does it read — only the ticket text, or customer history and contract tier too? When the source is stale or contradicts itself, what does the model do? Where's the line it cannot cross with customer data? When it's unsure, does it escalate to a human or guess? Who reviews the first two weeks of live output, and what's the kill switch? PwC's Responsible AI survey makes the case that this has to be designed into adoption rather than bolted on — and the practical reason is that retrofitting a data boundary onto a workflow forty people already use is ten times the work of setting it on day eight.
The output of this week isn't a policy PDF. It's four small artifacts that travel with the workflow: a reviewer checklist, a source list, one written risk boundary, and a metric dashboard that's been measuring real usage since the system went live — not a number you generate on the last day to justify the spend.
Day 31: scale, fix, or stop
A sprint that can't end in a clear verdict wasn't really a sprint. The deliverable on the last day is one of three sentences. Scale it — real users adopted it, the metric moved, governance held, so widen the rollout. Fix the inputs first — the workflow works but the source data is too messy or the boundary too leaky to trust at volume, so the next 30 days go to the inputs, not to a second use case. Stop — the value didn't justify the review burden, so kill it and bank the learning. That last verdict is a win, not a failure; finding out in 30 days that a use case is weak beats finding out in two quarters.
Notice what that decision is not: a backlog of twelve theoretical use cases ranked by a scoring matrix. A growth-stage company doesn't get value from a roadmap of things it might do. It gets value from one workflow that's actually running and a defensible call about whether to do it again.
If you're scoping your first sprint, the work upfront is choosing the right lane — narrow enough to finish, painful enough to matter. That's the job of a QuickStart AI Audit: pick the workflow and write the governance constraints before week one. When a sprint proves out and you want a sequenced plan for the next several, an AI Transformation Blueprint turns one win into an operating roadmap.
