Life after a Design Sprint

Design Sprints are great. You get into a room, you’re hyper focused, you’re getting it done. After only one week, you gathered a lot of insights around a hard problem, created a vision of a bright new world that your users will be in and can’t wait to ship it. But then you’re back in the normal day-to-day and you’ll ask yourself: what now?

I have always found this to be the hardest question. Running Design Sprints is easy, bringing the outcomes to life is hard. After doing a few of these and not only running them but being responsible for getting the vision that was created out on the streets, I gathered many learnings on what to do but more importantly, what not to do. Let me share with you the most common pitfalls I saw and how to avoid them.

Trying to ship the outcome of the Sprint

I think this is probably the biggest threat that you’ll run into and the basis of all others. You built a prototype, you validated it — you surely are going to ship it! And with this, you’re going to forget all the principles you were so focused on during the Sprint.

See the outcome of the Sprint as direction, not as solution. It gives you a vision, a better picture of how the world will look like in the future. But definitely not an exact picture. Treat this as your guiding star, and work hard with the right principles in mind to get there.

Stopping to validate

Another big pitfall that people regularly run into is that they stop to validate. You did validate your prototype in the sprint, so now you can just go ahead and build it, right?

The important piece here is that the Sprint’s outcome is insights-based on a quickly pieced-together prototype. This should serve as basis for further iteration and testing.

Creating a project to get the Sprint’s outcome on to the street

Everyone is so excited about the opportunities and the future that is painted through the outcome of the Sprint that you just go hands on to ship it. You realize that it’s big and you need a ton of resources to get it out on the street. You believe so much in it that you’re finding yourself creating a gantt chart, dependency mapping, allocating resources and suddenly, the whole company is involved in this (believe me, I’ve been there). What will happen next is that you’re running into a lot of problems coordinating these people — because the group working on it is just so big.

If you see yourself doing this, ask yourself these questions: What is the one problem that you’re trying to solve? Where is your strongest hypothesis for value? Are all of the teams and people that are currently involved needed in order to get a first version out the door?

If you live in a world similar to mine, the answer usually goes somewhere along the lines of “But if we do it this way, we will simultaneously increase our growth, revenue and retention! That’s why it makes sense to make a project out of it!” The reasoning usually makes a lot of sense and it is very tempting to go down this path. BUT: it rarely works this way (because it’s too good to be true). You either nail the selling and don’t nail the retention or vice versa. Or even worse: something gets lost in the middle due to the alignment overhead and everything is late. Most likely, you’re late anyways because humans tend to underestimate.

This problem is not an easy one to solve. The biggest mistake I made in this category is not having a clear game plan and letting it even come this far. How I do it now is as follows:

After a design sprint, I do a debrief with important stakeholders and executives to agree on what happens next. In this, I focus on these things:

The Sprint Question — what was the challenge we wanted to address?

User Insights — what were the insights and opportunities we found?

Sequencing — how do the insights build up on each other? Is there for example one thing that everything else is based on? Is there a natural order of things? Are there any easy wins that can be done right away? Anything that has high potential and high risk that needs more validation?

I’ll try to break the different insights and learnings down into different buckets, see what addresses the initial sprint question the most and how it makes sense to orchestrate things in this broken down way.

Coming with a plan like this, you’ll have a clear strategy on how to move forward that doesn’t include a months-long multi-team project.

Forgetting to integrate

Usually when doing a Sprint, you’re very negligent with the environment your product lives in. What happened to me was that we built a completely new experience, we validated it with new and existing users. It was great! But: we forgot that it might have an impact on the purchase funnel. We didn’t test early on if this would actually sell, which led to a few tense weeks when we finally ran the test.

Luckily, the outcome was positive. However this was a lesson for me to never forget to ask myself: where else does this have impact? Is there any other place in the product or any other user that I didn’t think of that is affected by these changes?

Not breaking it down / Not creating timeboxes

This is basically reiterating on Parkinson’s law — “Work expands so as to fill the time available for its completion.” This is so true and one of the biggest learnings I made over the past years.

Especially in a Sprint, you first come up with a concept. Then, you’ll try to build a part. Eventually, you figure out that something is way more complex than initially anticipated. My mistake was that I usually just accepted it. What else was there to do?

What usually happened to me and my team is that somehow, an external timebox came on to us. We needed to ship by X. This doesn’t sound like something good, however, it actually was. It forced us to think creatively. To really break things down. To never accept that something is too big and always ask ourselves the question: How can we make it smaller? Or: Do we really need to build this? It is very easy to see things you once set out to build as a given. It is very healthy to take steps back and ask yourselves: is this worth the investment? Is this the most crucial thing? Is there any way to get more certainty faster?

Later, I started to create timeboxes and push myself and my team hard to ask those questions. They are always uncomfortable. But also, always worth being asked, again and again. Because most of the time, you just don’t make your iteration small enough.

Summing it up

A Design Sprint creates great motivation and momentum, and I believe the following are the most important things to do afterwards to keep both going:

1. Break your insights down into individual pieces and components — don’t treat it as one big concept that can’t live without all those parts
2. Prioritize the easy wins and further validation of the biggest opportunities
3. Be clear about any remaining risk and how you plan to address it
4. For everything you do — be sure you understand how it will affect your ecosystem (other parts of the product, other teams in the company, etc.)
5. Set yourself timeboxes. How much time are you willing to invest to figure it out? Is it cheaper to build or to run another validation?
6. Treat your Sprint outcome as a “North Star Vision” for your team, not as what you are actually going to build.

Design Sprints are a great tool to create a shared vision and generate buy-in. Make the most out of them by having a clear game plan afterwards.