The discovery sprint: cheap certainty before expensive tooling.

Hardware punishes optimism. Software teams can ship a wrong guess and patch it Thursday; a wrong guess in hardware is cut into tool steel, ordered in volume and shipped in cartons. Yet most programs still start the expensive part (CAD, prototypes, tooling conversations) on the strength of a pitch deck and collective enthusiasm. Generative tools make that habit easier to fall into, not harder: when a convincing render is quick and nearly free, it's easy to commit before anyone has checked whether the product should exist.

The expensive default

The default failure mode isn't building the product badly. It's building the wrong product well. Teams fall into execution because execution feels like progress: geometry grows, suppliers respond, the burn chart moves. Nobody is assigned to the questions that actually decide the outcome: who exactly buys this, what it must do that incumbents don't, what it can be built for, and which physics problem will dominate the program.

What a sprint answers

A discovery sprint takes those questions and runs them hard for two to four weeks: a structured pass over the market and the technology, conversations with real operators in their real environment, and a feasibility read that puts honest ranges on cost and risk. Not a workshop. Not a vision document. A short program of work that ends in artifacts: a framed opportunity, explicit success criteria, an architecture recommendation and a risk register ranked by consequence. AI-assisted desk research can now cover more of the market and the technology in less time, which frees more of the sprint for the part no model can do from a desk: time in the field with the people who will live with the product.

The kill-list is the product

The most valuable page in a sprint readout is usually the list of directions we recommend not funding, with reasons. Every killed direction is tooling not cut, months not spent, capital not converted into inventory nobody wants. A good sprint should feel slightly disappointing. It trades imagined possibilities for a smaller set of real ones. That trade is the point.

The agent-native lens: two new questions for the sprint

If buyers send an assistant to shortlist. Discovery has always asked who buys and why. It now has to ask who does the shortlisting. In more categories, an AI assistant may compare options before a person ever opens a product page, and it can only weigh what it can read and check: published specifications, compatibility, certifications, support terms, price. A sprint should test whether the proposed product can win that comparison on facts, and which of its claims could be verified at all. If its real advantage is how it feels in the hand, that's fine, but then the plan has to get the product into a person's hand, and the readout should say so.

If the team runs the sprint with agents. Agents can make a sprint denser: summarising interview transcripts overnight, scanning the competitive set, keeping the risk register current as evidence arrives, drafting the reasons behind each kill. What they shouldn't do is decide which direction dies. Keep the raw evidence attached to every synthesised claim so a person can check the source, mark which conclusions were machine-drafted, and have the sprint lead sign the readout. A kill-list nobody signed is just a suggestion with good formatting.

When not to sprint

If the decision is already made and no evidence would change it, don't pay for theatre, and be honest that you're not doing discovery, you're doing execution. If credible research already exists, a sprint should audit and extend it, not repeat it for the invoice. We've told teams on the first call that they don't need one. That's part of the service too.

As making things gets cheaper to start and no cheaper to undo, the sprint matters more, not less. Discovery sprints are the front door of our strategy & research practice (fixed fee, fixed length, real artifacts) and the first loop of the evidence-loop process every larger program runs on.