Discovery Sprint

A Discovery Sprint is a short, strictly time-limited phase in product development. A small team tackles an open question and answers it within a few days. A week is typical, sometimes even just three days. The question is not “How do we build this?” but rather “Should we even build this?”. At the end there is no finished software, but a decision: continue, rework, or discard. The word Sprint emphasizes the fixed time frame, not frantic haste.

Why braking for a week pays off

The most expensive mistake in software development is a product nobody needs. A team can work cleanly for six months and still build past the target. Such months cost salaries, server expenses, and above all time that competitors can use. A Discovery Sprint moves the uncomfortable question of value to the very beginning. There, a wrong answer is cheap.

This is especially important for AI features. Many companies currently want to build something with language models, meaning programs like ChatGPT that generate text. But whether customers would actually use such a feature is unknown beforehand. A sprint turns this assumption into a testable statement.

For investors and managers, this has a second benefit. A Discovery Sprint produces a visible interim result after a short time. So instead of relying on trust for a whole year, one can course-correct early.

The process from question to user test

At the start stands a sharply formulated assumption. One example: “Small trade businesses would pay 30 euros a month for an AI to write their quotes.” This assumption is concrete enough to be wrong. That’s exactly the point. Vague goals like “better customer experience” don’t work as a sprint question.

Afterward, the team collects solution ideas, usually first individually, then together. From these ideas it selects one and builds a prototype. A prototype is a mock-up: a clickable sequence of screens that looks like an app but is empty inside. Sometimes a human even sits behind the supposed AI and types the answers. This mock-up is created in one to two days instead of months.

The last day belongs to the users. Five to six people from the target group receive the prototype and use it to solve a real task. The team observes where they get stuck and what they ignore. Five test subjects may seem like little, but experience shows they uncover most of the major problems. The separation is important: a Discovery Sprint clarifies the whether, a normal development sprint afterward clarifies the how.

Discovery Sprints in startups and corporations

The format was popularized by Google Ventures around 2016 under the name Design Sprint. Today it’s used by startups, banks, insurance companies, and agencies. The term appears regularly in job postings for product managers or UX designers. Consulting firms also sell Discovery Sprints as a standalone offering, usually as a package spanning one week.

In business news you tend to encounter the format indirectly. When a company announces it has “discontinued an AI idea after initial user tests,” this is often exactly the kind of process behind it. Conversely, a sprint that confirms an idea serves internally as an argument for budget.

A common misconception is that a Discovery Sprint saves development work. It doesn’t. It only prevents the wrong development work. And it works poorly when upper management has already made the decision and only expects the sprint to serve as confirmation.