The 2-Week AI Strategy Sprint, in Detail

Most AI engagements we get start the same way: “We have a bunch of AI ideas, we are not sure which ones are real, and we want someone smart to tell us.” We take this work as a fixed-fee two-week sprint. The deliverable is a written report that decides what to build, what to buy, and what to skip. This post walks through what actually happens day by day, what we hand over at the end, and the three outcomes a sprint typically produces.

Why a sprint, not a project

A traditional consulting engagement on this question would run six to twelve weeks, cost six figures, and produce a 60-page deck. Most of that is theater. The actual decision-grade work fits in two weeks if the consultant has done it before.

The constraints are intentional. Two weeks is short enough to keep the leadership team’s attention. It is long enough to inventory the backlog, score it, sketch architectures for the top candidates, and write a defensible report. Anything more is the consultant padding the bill.

The sprint produces three artifacts:

1. A scoring matrix for every AI use case the organization is considering.
2. Architecture sketches and build/buy/skip recommendations for the top five.
3. A 12-month roadmap with budget estimates and dependencies.

That is enough to get an engineering team unblocked and a finance team comfortable.

Day-by-day

Day 1-2: Inventory

We start by cataloging every AI idea floating around the organization. Email threads, Slack channels, leadership offsites, customer requests, the unfinished project that the previous CTO started, the thing the head of marketing keeps mentioning. The goal is 15 to 30 candidate use cases, each captured in a single line of description.

We get this from interviews. Three to five 30-minute calls: CEO, CTO or eng lead, head of the most-AI-curious department, head of the most-AI-skeptical department, and one customer-facing leader. We ask the same five questions in each. The pattern of answers is more useful than any individual answer.

By end of Day 2, the inventory is in a spreadsheet. No analysis yet. Just the list.

Day 3-4: Scoring

Every use case gets a 1-5 score on five dimensions:

1. Technical feasibility. Is the AI capability mature enough to ship this? GPT-5-class can summarize a meeting (5). It cannot reliably plan a multi-step business process (2).
2. Data readiness. Is the data available, clean, and labeled enough for the use case? Internal documentation that already exists in Confluence (5). Data that lives in PDFs only an analyst can interpret (2).
3. Business impact. Does this matter? An automation that saves the support team 200 hours a month (5). An automation that saves the legal team 4 hours a month (2).
4. Regulatory exposure. How much risk does shipping this create? Internal-only operational tool (5, low risk = high score). Customer-facing healthcare advice (1, high risk = low score).
5. Time-to-value. How fast can this ship? RAG over a known document set (5, weeks). Autonomous agent that handles complex multi-day workflows (2, six months minimum).

Sum each row. Sort descending. The score gives you a defensible ranking that survives leadership review. It is not the final word, but it puts every conversation on the same axis.

Day 5-6: Architecture sketches for the top 5

For each of the top-ranked use cases, we write a one-page architecture document. Not a beautiful diagram. A page of bullet points covering:

• Data sources (where it comes from, what shape, how clean)
• Model choice (which provider, why, what the alternatives are)
• Retrieval or fine-tuning approach (how the model learns about your domain)
• Integration points (which existing systems this touches)
• Eval strategy (how you know it is working)
• Three biggest unknowns (the things we cannot answer without more information)

The unknowns matter most. Every AI project we have shipped had at least one assumption that turned out to be wrong. The sprint surfaces those assumptions in writing while it is still cheap to fix them.

Day 7-8: Build/buy/skip per use case

For each top use case, we evaluate three options: build it custom, buy a vendor solution, or skip it.

Build is the right call when:

• No vendor solves the specific problem
• The data is sensitive enough that hosting matters
• The capability is core enough that owning it gives competitive advantage

Buy is the right call when:

• A vendor solves 80% of the problem at 20% of the cost
• The capability is not core (e.g., transcription)
• The vendor’s data privacy story matches your requirements

Skip is the right call when:

• The use case is not actually painful enough to justify any work
• The technology is not mature enough yet
• The team that would have to maintain it does not exist

We surface the cost, time, and lock-in tradeoffs of each. We recommend one explicitly with a one-paragraph rationale. The rationale matters more than the recommendation. Six months later, when the chosen vendor changes their pricing, the team needs to know why they picked that vendor in order to evaluate whether the reasoning still holds.

Day 9-10: Writing the report

The report is the actual deliverable. It is one document, structured as:

1. Executive summary (one page). Top three recommendations, top three risks, total estimated investment.
2. Scoring matrix (one page). Every candidate use case with all five scores and the total.
3. Build/buy/skip recommendations (3-5 pages). One section per top use case, with the architecture sketch, the recommendation, and the rationale.
4. 12-month roadmap (one page). Quarter-by-quarter view of what gets built, in what order, with what dependencies.
5. Appendix (as needed). Vendor comparisons, technical deep-dives, anything that does not fit in the main flow but might be referenced later.

The report is written to be readable by a non-technical CEO and trusted by an engineering lead. Both audiences must come out of it with the same understanding of what the company should do.

Day 11-12: Stakeholder review

We walk leadership and the engineering lead through the report separately. The reviews surface different things. Leadership pushes back on impact estimates and timelines. Engineering pushes back on architecture choices and feasibility scores.

We capture pushback in writing. We update the report. We re-circulate. About 30% of sprints have a meaningful update at this stage, usually around the build/buy decision for one or two use cases.

Day 13-14: Final delivery and decision

We deliver the final document on Day 13. On Day 14, we run a 90-minute decision meeting with all stakeholders. The output is a signed-off list of which use cases get built, by whom, with what budget, and on what timeline.

The sprint is done. The next call is either an SOW for the build phase, or a follow-up six months later when the company has executed and wants to plan the next round.

Three outcomes

About 40% of the sprints we run conclude with the company picking 2-4 use cases and either contracting us to build them or hiring internally with our sketches as the starting point. This is the modal outcome.

About 35% conclude with the company deciding to wait. Either the technology is not mature, the data is not ready, or the priority is somewhere else this year. The sprint paid for itself by saying so in writing, anchored on real analysis. Saying “wait” loosely is hard. Saying “wait, here is the scoring that supports it” is much easier.

About 25% conclude with the company picking a vendor for everything. We tell them which one and why. We are not in the vendor-implementation business, so we do not lose money on this outcome; the report gives them enough to negotiate and integrate without us.

All three outcomes are wins for the client. The losing outcome is “we spent six weeks and don’t know what to do.” That is what the sprint is designed to avoid.

What we won’t do in a sprint

A few things the sprint deliberately does not include:

• Build a prototype. Two weeks is not enough time to ship anything real. If the report says “build this,” the build is a separate engagement.
• Negotiate with vendors. We can recommend a vendor. We do not handle procurement.
• Train the team. Knowledge transfer is part of any build engagement. It is not part of the strategy sprint.
• Predict the future. We give a 12-month roadmap, but the AI landscape changes faster than that. Re-running the sprint after 12 months catches what changed.

The point of the sprint is to convert “we have a bunch of AI ideas” into “we have a written plan.” That is enough. Anything beyond that is build phase, and build is its own engagement.