Moving from Design Sprints to the AI Sprint™
For many years our team has led Design Sprints, modeled after the Google Design Sprint. We used it to help our clients get to an answer quickly about how – and whether – to solve a particular problem. At the core of the methodology is getting to a solution that checks all the boxes in the DVF product trifecta: Desirability, Viability, and Feasibility. Kind of.
“Traditional” design sprints nail desirability and give you a glimpse into business viability (as long as you’re making the right assumptions.)
But feasibility—whether you can actually build it in your tech stack—we didn’t typically get to touch that in the Design Sprint, we could really only hypothesize. *
And that problem is a big part of why we see so many AI projects die. They live forever in "pilot purgatory" because not enough was done to understand how to make them production-ready.
AI Sprints™ get to a degree of clarity on all three in two weeks. We ship working prototypes in whichever environment proves DVF fastest; your stack, ours, or a hybrid. Not demos. Not mockups. Real code that proves the concept works where it needs to work.
And, yes! Blank Metal legitimately trademarked this methodology, because we’ve got a ton of confidence in how it’s helping our clients so far.
The Pilot Purgatory Problem
Every enterprise has at least some of the same problems – AI pilots that showed promise but never shipped.
When we don’t spend enough time considering feasibility, even at a high level, it greatly reduces the chances of our solutions coming to life inside a locked-down enterprise environment. Pilots get shelved because the teams needed to support moving it into production already have a backlog 10 miles long. So it waits and waits and over time the business case changes and the champions move on.
We flip this. Start with your constraints. Try to understand what needs to be true inside your tech stack from day one. If it works in production-like conditions during the sprint, it works when you scale.
The Challenge of Just . . . Starting
We also see companies facing the challenge that comes right before pilot purgatory – just getting started. They have a massive pile of use cases or pain points, but don’t have a process to prioritize which ones to test solutions for, and how to test it.
The AI Sprint™ solves for that as well. Leading up to the sprint, we conduct work sessions to identify the biggest pain points, turn those into sprint-sized use cases, and help our clients prioritize what to work on first, and why. We help them understand the business case of solving the problem, so that all of their AI development efforts are not just building new skills on their team, but creating financial momentum and evidence that the emerging technology can have real business impact.
Our hypothesis is that the momentum you start to build will ultimately lead to solving increasingly complex use cases, and that is where real organizational transformation starts to show.
What This Changes
Validating feasibility in days (not weeks or months) fundamentally tightens engineering estimates. By surfacing real integration challenges early, we trade guesses about complexity for evidence-based sizing.
Who This Is For
So who should do an AI Sprint™? Obviously the easiest answer is everyone! But for reals – if you feel seen (or attacked) by any of these statements, you should get in touch with us to start sprinting:
My company hasn’t really done anything meaningful in AI and we feel behind
My company (or team) has done some experiments, but then nothing else happened
We aren’t sure how AI could help us in our work
We’re not happy with our current partner/vendor/consultancy and their POV or approach around AI
We have cultural resistance to adopting AI tools in our organization
*Let the record show that I typed this from my brain, and my brain used em dashes, not Claude.
 | A guest post by
|