Scoping the Feasibility Spike: The One-Week Bet That De-Risks an AI Feature

A feasibility spike is a timeboxed, throwaway investigation — usually three to ten days — built to answer one question: can we actually do the riskiest, most uncertain part of this AI feature? It ends in a decision, never a demo, and its scope comes from naming one killer assumption before day one.

Quick Answer: A feasibility spike buys one answer to one question, not a prototype or a proof of momentum. Name the killer assumption, define the pass/fail signal, timebox it to days not months, and pre-commit to what a fail actually triggers — before anyone opens an editor.

What a Feasibility Spike Is Actually For (and What It Isn't)

A feasibility spike converts unresolved risk into a decision, using the smallest real engineering investment that can produce a trustworthy answer. It is not a prototype built to excite stakeholders, not a sprint's worth of feature work pulled forward, and not open-ended research — it is a bet with an expiration date.

The distinction matters because each of these activities produces something that looks similar from the outside — a working demo, a piece of code, a slide with a chart — while optimizing for a completely different outcome.

Notice that a spike can succeed by failing. If the honest answer is "we can't hit the latency budget with this architecture," that is a complete, valuable result — it just isn't a demo you can show in a town hall, which is exactly why spikes get quietly turned into demos under pressure (more on that anti-pattern below).

Spikes earn their keep on AI features specifically because so much of the risk is empirical rather than logical. You can whiteboard a CRUD feature's feasibility with confidence; you often cannot whiteboard whether a retrieval pipeline, a fine-tuned classifier, or an agent chain will actually hit an acceptable accuracy and latency bar on your real data. That gap between "logically buildable" and "empirically good enough" is what a spike exists to close. For the broader discovery process a spike sits inside, see the complete guide to AI feasibility.

Name the Killer Assumption First

Every spike should be scoped backward from a single sentence: "This feature dies if ___ turns out to be false." That sentence is the killer assumption, and finding it is harder than it sounds — teams default to testing what's easy to test, not what's actually load-bearing.

A killer assumption is rarely "can we call an LLM API." It is almost always one of:

• A data assumption — the signal your model or retrieval step needs actually exists, at the volume and quality required, in production data (not a curated demo set).
• A latency or cost assumption — the feature can respond inside a budget users will tolerate, at a per-call cost the business can sustain at scale.
• A quality/accuracy assumption — outputs are correct or useful often enough that the failure mode doesn't erode trust faster than the feature builds it.
• An integration assumption — an existing system (a legacy API, a data warehouse, an identity provider) actually exposes what the design assumes it exposes.

Ask which of these, if it broke, would force a redesign rather than a fix — that's your candidate. If two or three feel equally load-bearing, that itself is a finding: you may need two small spikes, not one broad one, sequenced by which failure would be most expensive to discover late.

This is also where a feature's connection to the customer's actual workflow matters. An assumption that's technically risky but sits outside the core job the user is hiring the feature to do is a worse first bet than one that sits squarely inside it — easier to see clearly when the feature is mapped against a jobs-to-be-done breakdown of the underlying problem.

Where a tool can help you find it

Naming the killer assumption is a facilitation problem as much as a technical one. Most feature ideas arrive with five or six plausible risks tangled together, and the team's instinct is to test the one that's most fun or most familiar — not the one that would actually kill the feature.

Define the Pass/Fail Signal Before Anyone Opens an Editor

A spike without a pre-defined pass/fail signal isn't an experiment — it's a demo waiting to happen, because "did it work?" will get answered by whoever is most persuasive in the readout meeting instead of by the data. Decision analyst Douglas Hubbard, whose "value of information" framework underlies most rigorous uncertainty-reduction work, frames the pre-check simply: would knowing the answer actually change what you do next? If the answer is no regardless of outcome, you don't need a spike — you need a decision.

A workable pass/fail signal has three properties:

1. It's measurable, not vibes-based. "Feels fast enough" is not a signal; "p95 response time under 2 seconds on the real endpoint" is.
2. It's set against the real constraint, not a convenient one. If the feature will live inside a chat interface with a hard latency budget, test against that budget — not a comfortable local benchmark. For a concrete framework on setting that number, see how to set latency budgets for AI features.
3. It's written down before the spike starts, ideally in the spike brief itself, so nobody can retroactively lower the bar once results come in warmer than hoped.

A pass/fail signal that gets negotiated after seeing the results isn't a signal — it's a rationalization with a number attached.

Precision here also protects the spike's timebox. A vague signal invites "let's just try one more thing" indefinitely; a numeric threshold gives the team a clean, arguable stopping point on day five instead of a fuzzy sense that they're "close."

Timebox Hard — Why a Week Beats a Quarter

The timebox is not a scheduling nicety; it is the mechanism that forces the killer assumption to actually get tested instead of endlessly refined. Google Ventures popularized the five-day design sprint specifically because, as sprint originator Jake Knapp found repeatedly, unbounded timelines let teams debate an idea indefinitely without ever confronting it with reality. A spike borrows the same logic for a narrower, more technical question.

A useful rule of thumb: the timebox should be short enough that abandoning the work costs almost nothing, and long enough to get a real answer rather than a guess.

• 1-2 days for a narrow technical check (does this API return the field we need, at what latency).
• 3-5 days for the common case — enough to build a thin, disposable path through the killer assumption on real or realistic data.
• Up to 10 days for spikes that require assembling a non-trivial evaluation set before you can even measure pass/fail — but treat anything longer as a sign the spike is actually two spikes, or that scope has crept past the killer assumption.

Hard timeboxes also protect against a subtler failure: sunk-cost creep, where a team two days over budget convinces itself the answer is "almost there" rather than accepting an inconclusive result as itself informative. Set the end date in the brief, put it on the calendar, and treat a spike that runs long as a signal to stop and reassess — not as an invitation to extend.

Note that the killer assumption you're testing often traces back to a specific moment in the user's experience — a spike scoped without reference to where in the journey the risk actually bites tends to test the wrong slice of the problem. Mapping that first, even roughly, against a customer journey framework usually sharpens the timebox rather than extending it, because it narrows what "realistic" data and constraints actually mean for this feature.

The Anti-Pattern: When the Spike Quietly Becomes Production Code

The single most common way spikes fail isn't a bad result — it's a spike that never produces a decision because it drifted into becoming the actual feature. It starts innocently: the throwaway code "basically works," someone suggests just hardening it a little, and weeks later the team has shipped an unreviewed, untested version of the feature with no one having actually decided to build it.

Watch for these warning signs mid-spike:

• The demo gets scheduled for stakeholders before the pass/fail signal has been checked — this reframes the spike's goal from "answer a question" to "look impressive," and impressive code rarely gets thrown away.
• "Just one more day" repeats past the hard timebox, with no new information being gathered — the team is polishing, not testing.
• The branch doesn't get deleted or archived once the spike concludes, so it sits there as a tempting shortcut the next time someone needs "something like this fast."
• Error handling and edge cases start creeping in — a spike only needs to survive the happy path on the specific inputs the pass/fail signal defines; anything more is scope creep disguised as diligence.

The fix is structural, not willpower-based: decide and write down, before day one, that the spike's code is disposable regardless of outcome, and that a "pass" result triggers a separate, properly scoped build — with its own design, review, and staffing — rather than a silent promotion of the spike branch.

RAND Corporation researchers, examining why AI projects fail at markedly higher rates than typical IT projects, reported in a 2024 analysis that more than 80 percent of AI initiatives fail to deliver — roughly double the failure rate of non-AI IT projects — and pointed to skipped problem-formulation and validation steps as a recurring cause. A spike that quietly becomes production is this pattern in miniature: the validation step got skipped because the code already existed.

That same appetite for a working-looking thing is why Gartner, in a widely cited 2024 prediction, estimated that at least 30 percent of generative AI projects would be abandoned after proof-of-concept by the end of 2025, citing unclear business value and cost escalation once "it works in the demo" met production reality. A disciplined spike is cheap insurance against becoming one of those statistics — but only if its output stays a decision, not a shipped artifact.

The Spike Brief Template (With a Kill Criterion Baked In)

A spike brief is a one-page document, written before any code, that makes the killer assumption, the pass/fail signal, and the consequence of failure impossible to renegotiate mid-week. Product coach Teresa Torres's opportunity-solution-tree approach treats every assumption as independently testable and falsifiable; a spike brief is that discipline compressed into an artifact a whole team can align on in one sitting.

The kill criterion is the field teams most often skip, and it's the one that makes the whole document worth writing. Deciding "if this fails, we shelve it for two quarters" before you see the result removes the temptation to invent a face-saving interpretation of a bad number after the fact.

A short numbered process turns this template into a working spike:

1. Draft the killer assumption and pass/fail signal together with whoever will build and whoever will judge — usually a PM and a tech lead — so there's no gap between what gets built and what gets measured.
2. Write the kill criterion before writing any code. If you can't articulate what a "no" means for the roadmap, you're not ready to start the clock.
3. Set the timebox on the calendar, not just in the doc, with an owner accountable for calling time.
4. Run the spike against real or realistic data and constraints — a synthetic happy-path test answers a different, easier question than the one you actually need answered.
5. Deliver the verdict, not the code. The readout is a decision — build, don't build, or redesign — plus the evidence behind it, not a live demo of the spike branch.

Once a spike passes, its findings need to become something engineering can actually build from — a scoped, reviewable spec rather than the spike branch itself. That handoff goes more smoothly when the spec answers, up front, the questions engineering actually needs answered before committing to an AI feature, and when the data the spike leaned on has already been checked against a data-readiness audit for AI features rather than assumed to generalize from a curated test set.

Key Takeaways

• A spike's deliverable is a decision, not a demo — build, don't build, or redesign, backed by evidence against a threshold set in advance.
• Name the killer assumption first: the one belief that, if false, kills the feature — not the risk that's easiest or most fun to test.
• Write the pass/fail signal before any code exists, measured against real constraints (latency, cost, accuracy) rather than a comfortable benchmark.
• Pre-commit to a kill criterion. Decide what a "no" means for the roadmap before you see the result, so a bad number can't get quietly reinterpreted.
• Timebox in days, not sprints or quarters — the constraint is what forces a real test instead of endless refinement.
• Watch for the spike-to-production drift: a scheduled demo, a repeatedly extended deadline, or a surviving branch are all early warning signs.
• Treat the readout as a handoff point, not a finish line — a passed spike still needs a proper spec before engineering commits real time to it.