How Product Discovery and Design Sprints work together

One of the core messages I constantly repeat when talking about Adaptable Product Discovery is the amount of time product teams should spend on understanding the problem space compared to thinking about solutions during. A tool that is often mentioned in that context is a Design Sprint (DS).

So, let's take a closer look at how a Design Sprint and the broader activity of Product Discovery (can) play together.

In its original version, the linear 5-day Design Sprint process looks like this:

If we map those days and activities to the possible phases of a Product Discovery, we end up with a rough allocation like this:

80% of a Design Sprint is spent in the solution space. It's about creating ideas, prioritizing them, creating prototypes, and validating them (at least from a qualitative angle).

This means that a Design Sprint represents a compressed version of the Discovery activities Ideation, Creation, and Validation. Of course, you're cutting many corners while working through these phases during a DS, but that's the idea.

Now, I believe that a DS isn't a full replacement for a Product Discovery. There are some (clickbait-y) resources out there that proclaim that it's the one-stop-shop for building digital products. For the majority of problems that get (rightly) selected for a Design Sprint, I think this is misleading.

But from my experience, this is only the marketing side of the story. In reality, a lot of the Discovery activities like alignment, more thorough qualitative and quantitative research, quantitative validation, and refinement/backlog creation are still needed to transition a promising idea into effective delivery.

In cases where you can immediately implement an idea coming out of a Design Sprint, much work has been done behind the scenes (or this idea was too small for a Design Sprint).

Even AJ&Smart, one of the most popular DS service providers I'm aware of, doesn't believe in solving it all in those five days. Instead, even they sell clients a 4-week package containing additional upfront research, one DS, an iteration DS, and a week for refinement and delivery of assets/concepts.

When I am comparing that with the 6-week time box for getting started with Product Discovery, which I (and others) recommend to clients, you that it doesn't differ that much. You can easily add the (needed) parts of alignment, quantitative validation, actual concept refinement, backlog build-up, and, of course, iterations in-between to this number.

So, while the Design Sprint is one way to cycle through a couple of Discovery phases, it can't do everything in 5 days. It stands on the shoulders of other activities.

Product Discovery and Design Sprints are not competing. If the intention and context are clear, a Design Sprint can be a handy tool for a specific part of Product Discovery.