Innovation sprint consulting is the design and running of time-boxed engagements that take one question, usually about an AI use case, from “someone thinks this is interesting” to a recorded go or no-go decision inside a fixed calendar. Vivaldi has advised on innovation and growth since 1999. The sprint is our lowest-commitment entry point: a few days of structured work that either scopes a build or writes down, in a form the next team can find, why there will not be one.
- Since 1999strategy, innovation and growth consulting
- 200+published case studies
- 10 officeson four continents
- 5xWirtschaftsWoche Best of Consulting, Strategy and Innovation
When companies bring us in
- A long list of candidate AI use cases exists and nobody can say which one to do first, so none of them start.
- The organization has run workshops and hackathons, has slide decks and demos to show for them, and has shipped nothing.
- A pilot is already running past its original end date because no one agreed in advance what result would end it.
- An executive has committed publicly to an AI initiative and the team needs evidence before the next board meeting rather than after it.
- Sprints are already happening in three business units with three different definitions of what a sprint is, and the results cannot be compared.
Why most AI sprints do not change anything
The standard sprint is built to demonstrate. Five days, a cross-functional team, a working demo on Friday, applause. The demo proves the technology functions, which in 2026 was rarely the thing in doubt. The week produces an artifact and no decision, and the artifact goes into a folder.
A sprint earns its cost when it is built to disprove. The question at the start is not what could we build. It is what would have to be true for this to be worth building, and what is the fastest way to find out that it is not. That framing changes who needs to be in the room and what gets built in it, and it usually means building far less than a working prototype.
AI has made this worse before it made it better. When generating a concept, a synthetic customer panel or a rough working version costs hours instead of weeks, the output side of the sprint gets cheap and the decision side does not. Teams now produce more candidate ideas per week than their governance can absorb, which feels like progress and reads, a year later, as a pile of unresolved pilots. The binding constraint has moved from the cost of trying things to the sequencing of what to try and the authority to stop.
What our innovation sprint consulting includes
1. Sprint portfolio sequencing
Before any sprint runs, we sort the candidate use cases by what a sprint could actually settle. Some questions are not sprintable: they need a year of data, a regulatory opinion, or a decision someone is avoiding. Naming those early is worth more than running a week on them. The output is an ordered list with a reason attached to the order.
2. Pre-sprint scoping and decision design
We name the assumption the whole idea rests on, which is frequently not the one the team expects, and we agree in advance what evidence would settle it. We also agree who decides and on what date. A sprint that ends in a recommendation to a committee has not ended.
3. Running the sprint
Days, not weeks, with a fixed end. We build only what the test requires, put it against real conditions rather than a curated demonstration case, and resist the pull toward making the thing look finished. The discipline is subtractive: most of the work is deciding what not to build this week.
4. AI in the loop, where it changes the answer
We use AI inside the sprint where it compresses something real: synthesizing research and prior decisions, generating and pressure-testing concept variants, drafting the working version that the test runs against. We do not use it to manufacture evidence. A model’s opinion of your customers is a hypothesis, not a finding, and we label it that way in the record.
5. The decision and the decision record
Every sprint ends in one of three states: a scoped build, a documented stop, or a named condition that would change the answer. All three are written down with the reasoning, so the organization can find out why six months later without re-running the week.
6. Handoff, or standing the format up internally
Where the answer is build, we hand the scope to whoever builds. Where a company intends to run several of these a year, the more valuable output is the format itself, and the work moves toward making it a standing internal capability rather than a repeated engagement.
- ScopeWhich question this settlesThe assumption the idea rests on, and the evidence agreed in advance as sufficientUsually assumed
- BuildThe smallest thing that produces evidenceEnough to test against real conditions, and no more than thatUsually strong
- DecideGo, stop, or what would change itMade on the agreed date by the person who can approve the next stepUsually deferred
- RecordWhy the decision was madeThe reasoning, retrievable by whoever scopes the next sprintUsually absent
Not sure which use case to sprint first?
Start with a short working session. We will take your candidate list, separate the questions a sprint can settle from the ones it cannot, and tell you which one to put a week against and what result would end it.
How an innovation sprint engagement works
- Sequence. We review the candidate use cases, discard the ones a sprint cannot settle, and order the rest by how much the answer would change what the business does next. The output is a ranked list with the reasoning attached.
- Scope. One question, one named assumption, one agreed standard of evidence, one decision date and one named decision maker. This is written down before the sprint starts and does not move during it.
- Run. Days, not weeks. We build only what the test needs, run it against real conditions, and bring the result to the decision maker on the agreed date rather than to a steering group afterward.
- Record and route. Go, stop, or the condition that would change the answer, written down with the reasoning. A go routes into a scoped build; a stop routes into the next sprint on the list.
Why companies choose Vivaldi for innovation sprints
We are a strategy firm, not a build shop, and that shapes what a sprint with us is for. We have no implementation revenue waiting at the end of the week, so a documented stop is a successful outcome here rather than a lost sale. That matters more than it sounds: the structural reason sprints keep ending in “promising, let us continue” is that somebody in the room is paid by the continuation.
The second difference is the sequencing work in front of the sprint. Most providers sell the week. The judgment that is actually scarce is which week to spend, in what order, and that judgment comes from having argued about innovation portfolios with executive teams since 1999 rather than from the sprint format itself, which is not proprietary and which we will happily teach you to run without us.
How to evaluate an innovation sprint consultant
- Ask what happens if the sprint says no. If the answer is vague, the sprint is a sales process with a timebox around it.
- Ask who decides, and when. If the engagement ends with a readout to a steering group, nothing has been decided and the clock restarts.
- Ask what gets built. A provider who promises a working prototype in every sprint has pre-committed to the expensive answer before knowing the question.
- Ask what the sprint produces beyond the week itself. A decision record the next team can read is worth more than the demo and costs almost nothing to produce.
- Ask how they choose which use case goes first, and whether they will say no to one of yours. Sequencing judgment is the part you cannot easily hire back later.
Innovation sprint consultancy vs design sprint agency vs internal innovation lab?
| Criterion | Innovation sprint consultancy | Design sprint agency | Internal innovation lab |
|---|---|---|---|
| What the week is for | Settling one business assumption well enough to decide go or stop | Moving a concept from idea to tested prototype | Keeping a portfolio of exploratory bets alive and visible |
| Typical output | A decision, the evidence behind it, and a written record of the reasoning | A clickable prototype and user test findings | A pipeline review and a set of running pilots |
| Who has to be present | The person who can approve or kill the next step | Designers, researchers and a product owner | The lab team, with the business reviewing later |
| How a no is treated | A successful result, recorded and reused | Usually an iteration brief | Often an unresolved pilot that keeps a budget line |
| Best when | You have more candidate AI use cases than conviction, and decisions are the bottleneck | The decision to build is already made and the design is open | Exploration is a standing function with its own mandate |
Related work
A sprint is a format, not a method. Four neighbors, with the line between them stated:
- Business experimentation when the harder problem is designing the test itself rather than fitting it into a timebox. Experimentation owns test design and what counts as evidence; a sprint owns the calendar, the room and the decision.
- Prototyping and testing when the thing in question genuinely needs something built and put in front of real buyers. A sprint will often conclude that this is the right next step, and hand over to it.
- AI innovation capability consulting when you intend to run sprints continuously and want the format, the governance and the decision record to live inside the organization rather than inside an engagement.
- Workforce transformation and AI when the question is not whether a use case works but what it does to roles, and which capabilities the organization has to change to absorb it.
For the wider technology agenda a sprint feeds into, see AI strategy and new technology and enterprise AI training and workshops. This work sits inside our AI innovation capability group, part of the People, Culture and Capabilities practice at Vivaldi, the strategy firm behind the Demand Landscape and the Interaction Field.
Innovation sprint consulting in the US and worldwide
We run sprints out of ten offices on four continents, with the US team in New York. Where a client operates in several markets, we prefer to run the sprint in the market with the most awkward conditions rather than the friendliest one, because a use case that survives the hardest regulatory or operational environment in the portfolio can be rolled toward the easier ones, and one validated in the easy market usually cannot. Which market that is tends to be a finding in itself, and it belongs in the decision record.
Put a week against the thing you are least sure about
In one working session we will look at your candidate AI use cases, identify which assumption is actually load-bearing, and agree what result would end the argument. You leave knowing which sprint to run first and what it has to produce.