August 2

Why Design Sprints Don't Work

In far 2010 googlers introduced design sprints to the tech product world. The idea is simple: Map → Sketch → Decide → Prototype → Test. Read more here and let's move on.

What's Wrong with Design Sprints?

If you are familiar with the whole product process, you know that it is actually a loop when after the "Test" part you come back to one of the previous steps (sometimes even to those which are before the "Map" in the design sprint). But design sprints have clearly defined the start and the end, it doesn't nudge you to iterate and do it effectively (moreover, if you try to iterate with design sprints, you'll find yourself in a time-consuming process requiring all steps).

Not only do design sprints take you a whole week each, but every step is just one day. In 2010, the MVP idea was proliferated yet in product teams. Building a piece of crap, calling it a working prototype, testing it, and getting insights was a good idea. But now, when markets are not already nascent and pretty competitive, the MVP is replaced with MLPs (Minimum Lovable Products). Users already get used to good enough products. You can't just show them a hastily designed prototype and hope to get good insights. Users will be confused with laggy clumsy UX, bad UI writing, and obvious issues. And these "obvious issues" are insights you can only hope to get after.

Combining only these two design sprint issues, at the end of the test day, you get a bad prototype, obvious insights on which parts of this prototype are bad, and the feeling that you need to do it again (and 95% of the times you need to do over and over because it's a really rare scenario when you hit the bullseye on the first attempt).

Is the whole week worth it? In some cases, yes. But before telling why to use design sprints, let's focus a little more on this practice in B2B.

It Doesn't Work Good with B2B-products

How does the typical product process in B2B SaaS look like? Depends on how the team works with customers but often it is something like: continuous data gathering (read more in Teresa Torres's book Continuous Discovery Habits), making an agreement with customers, delivering a feature, seeing happy customers' faces, and only after the improving process.

Note, that when I'm saying "an agreement", I'm not talking only about signed-up contracts. An agreement can be a feature request by a client on a call or a task in Jira. The term means only that you prioritized something higher and want to make customers happier with it.

For example, I hardly can imagine when you promised a feature to a customer and are going to do it as good as possible from the first attempt by conducting extensive research, design sprints, and constantly changing technical specifications. In reality, you implement it as fast as possible almost at any cost bearing in mind that if this feature is really going to have a success, your team will iterate on it, and not once. Why is it so? Because in customers' eyes, developing a feature for a few months means that you've forgotten about them and just do not care anymore. Eventually, they will leave you (but cheer up, you've released a polished feature).

At some point, I contradict myself saying before that design sprints can't help you build a polished product but then talking about how it can be used to do exactly so. Let me explain myself. If you introduce design sprints as a part of the whole product process, they can be useful. But quite time-consuming as said above because of its flow strictness. And that's where it stops working for most B2B SaaS. But at the same time, it leads to my points on why and when you may use design sprints.

When Design Sprints Come in Handy

The biggest point of using design sprints in your processes is to make it a team-building activity with the focus on elevating the product mindset of the whole team. Everybody comes into one room to go through one short loop of the whole product process after which they start to understand how and why it should work exactly this way. Plus, it's a lot of fun.

The other way you can use it is when you need to work out a solution with two teams or some people who weren't before in your team. After only a week, newcomers will know how you think, how you work, and how you can be useful in their processes.