The discovery sprint — three days to a build-ready spec
What goes into the locked spec, why we charge for discovery, and the questions we always end up asking — even when founders think they've answered them.
A 7-day build sprint is the loud half of our engagement. The quiet half is the three days that come before it — what we call discovery. It's shorter, it's cheaper, and it's often the difference between a sprint that ships and a sprint that thrashes.
Most founders want to skip it. We understand why. If you've been living with the product in your head for six months, every conversation about it feels like a delay. You have Figma files. You have a Notion doc. You have answers. Why are we spending three days on questions?
Because the answers in your head are not yet the shape an engineering team can build from. The job of discovery isn't to generate new ideas; it's to translate what you already know into an unambiguous artefact, find the handful of things you haven't actually decided, and decide them before the meter starts.
What comes out the other side
A discovery sprint produces one document. We call it the locked spec. It has a shape we've refined over a lot of projects:
- The problem. One paragraph. What hurts, for whom, and why now. This is the paragraph the engineering team rereads when a scope question comes up mid-build.
- The user types. Typically one to three. Named. Described. Each with a primary job they're doing in the product.
- The core loop. The one flow that, if it works, the product works. This is the flow we build first and test hardest.
- The object model. Not an ERD yet — a short list of the nouns the product cares about. "A Deal has many Tasks, which belong to a Workspace." If the founder and the team can't agree on this list, nothing else matters.
- The integrations. Named. With account ownership identified. Anything that needs third-party approval gets flagged here.
- The non-goals. Explicit. "Not in this sprint: team features, billing, mobile, public API." The non-goals are where the sprint gets protected.
- The deferred decisions. The two or three things the founder hasn't decided, which don't need to be decided to start, but which we're committing to a default for. This list is shown to the founder, they sign it, and the sprint can start.
That's it. No twenty-page PRD. No Gantt chart. No "phase two roadmap." The spec describes what the sprint will build, cleanly and completely, and nothing else.
Why we charge for it
A discovery sprint is a real piece of work for three of our people. It's also, frankly, the part of the engagement where we earn our money twice: once by doing the discovery, and once by giving the founder permission to stop the engagement if it reveals they don't have a 7-day project.
If discovery shows us that the idea needs another month of customer validation, or that the MVP is actually two MVPs, or that the founder hasn't yet decided anything load-bearing, we'll say so. Sometimes we hand a founder a spec and the first line is "we don't recommend you start the build yet, here's why." We'd rather do that than sell a sprint that won't land.
Free discovery, which some teams do, changes the incentive. A free discovery wants to conclude with a yes, because the seller isn't paid until the build starts. A paid discovery is happy to conclude with a no, and that makes the advice honest.
The questions we always end up asking
After many discovery sprints, the questions have converged. These are the ones that most consistently surface something the founder hadn't decided:
"Who is this for, specifically, not aspirationally?"
The real user. Not the TAM. The first fifty people who will use it. The answer often reveals that the product the founder wants to build is subtly different from the product the first fifty people need.
"What does a user do on day one, day seven, and day thirty?"
The answer describes the core loop, and reveals whether there is one. A lot of early products have a great day one and no day seven. If day seven is empty, we're building a demo, not a product.
"What will make you kill this?"
The founder's line in the sand. If the answer is "it won't get killed," we keep asking. Every honest MVP has a kill condition. Naming it up front makes the build better, because every feature can be judged against "does this help us learn whether the kill condition is true?"
"If we built one flow, which one?"
The forcing question. The answer is always the core loop. If it isn't, the founder has mixed up the core loop with the marketing surface, and we've got work to do before the build starts.
"Who owns the Stripe account?"
Or the domain. Or the Google Workspace. Or the AWS bill. Every founder has at least one account they haven't set up that will block something. We find them in discovery, not on day six.
"What do you want to be doing in week three?"
The founder answers this one honestly, and it tells us what the MVP is actually for. "Showing investors" needs one set of features. "Running real customers through it" needs a different set. "Running myself through it to prove to myself it works" is a third. All legitimate; all change the spec.
What a good discovery feels like from the inside
A well-run discovery sprint is uncomfortable for about a day, then sharp for the rest. The first day is where the founder's internal model meets ours, and a lot of "what I meant by that was…" happens. By day two the vocabulary is shared. By day three the document is writing itself.
When we hand the spec over, the best reaction a founder has is "this is what I've been trying to say." The worst — and also valuable — is "I didn't realise I hadn't decided that." Both of those are wins. Either we've captured the product clearly, or we've found the gap in time to fix it.
What we don't want is "sure, looks good." That usually means they haven't read it. We re-run the conversation until the founder can push back on a specific line. If the spec isn't worth pushing back on, it isn't specific enough.
The lock
The last thing discovery produces is a mutual agreement that the spec is locked for the build sprint. New requests go on a sprint-two list. We don't disappear when the lock happens — the daily check-ins still exist — but the lock is the reason we can promise a timeline in the first place.
Locks sound rigid. In practice they're the opposite. A lock gives the founder permission to stop revising, stop second-guessing, and let the team build. More than a few founders have told us the lock is the part of the process that felt most like relief.