Design Sprints Help Increase ROI. How?

Published in

The Startup

8 min readOct 26, 2018

This article has a simple example of John Doe to present why you should adapt Design Sprint to increase ROI. There is nothing fancy in this article.

It’s been almost 2 years since the book Sprint launched. It’s become the New York Times Bestseller. Before launching the book, the creators of Design Sprint process Jake Knapp, John Zeratsky, and Braden Kowitz, tested it with more than 150 startups.

Many people read the book and tried to implement the Design Sprint process for their organizations, products, challenges, etc. to know how it helps them. For a few, it didn’t go well because of the improper implementation, and then stopped there. And there were many who got success with it. Some of them made it a part of their organization, a few decided to build their business on it. So, it seems that it has started trending within organizations, teams in some part of the world.

But, Design Sprint is still unheard in most parts of the world. My experience says, when people hear about it, they find it interesting. They ask questions like is it about designing a website or mobile app, is it a part of agile, etc. They try to understand why, how, and what of it. And they end up with questions like, what’s the outcome of investing the time of 4–7 key people for the entire week? What is the ROI of Design Sprints? It’s an obvious and important question.

Let me explain the ROI of Design Sprints. For that, let’s start with diving into the traditional processes.

Traditional processes

Before starting, let me break a myth first. People think that Design Sprints can be used for products only. No, that’s not true. Design Sprint is versatile and can be used to solve any critical challenge.

But, to make it easy, we will take a simple example of building a digital product.

John Doe, most of us know him, right? He’s got a great product idea. And he decides to build a digital product (mobile apps) to bring that idea to life. Now, let’s see how his traditional process to build a digital product looks like.

John will do some market research, competitors analysis, user research, etc.

Based on that, he will create a list of features for the initial launch. Generally, we call it an MVP.

Then? He will either hire a development team or build his own team to start building the MVP.

After the development of 4–6 months (depends on the scale of features or modules), he gets his MVP done.

And, he will launch it.

Then, he will wait until he gets real users’ feedback on the MVP; so that he can improve the product and launch a better version of it. Generally, collecting the feedback takes 1–2 months.

This is a kind of general process with no IFs and BUTs. But, the fact is, anything can happen while you’re building an MVP. There can be unlimited discussions and meetings in messy ways, changes in the features decided initially for the MVP, etc. Sometimes, such unstructured and messy things make teams lose motivation and direction, and much more. So all of these may increase the MVP launch time by 1–2 months.

After getting feedback on the MVP, the same traditional process continuous (generally) for all the following versions of the product.

Now, you can think of the amount of time, money, and efforts John Doe will spend on the MVP and all the following launches.

Think of the money

Let’s say, John Doe hires a development team from an agency to build his digital product. This team will spend 4 months to build and launch it. Then they will wait for approx 2 months to get feedback from real users.

After getting feedback on the MVP, John decides to make changes to existing features and introduces new features to give users an “Aha” feeling. Again, the development team will start building the product, they will take approx 2 months to develop and launch this time. John will again wait for 1 month to get the real feedback so that he can improve the product.

This way, the traditional process continuous and John keeps spending money on product development.

Wait, we just forgot the cost of maintenance, infrastructure, marketing, etc. Right?

If John would have built his own development team, he would need to pay salaries to the product manager, designers, developers, system engineer, tester, business analyst, marketer, etc.

Think of the time

Now, you already know what does a traditional process look like when you build and launch a product; you should have got an idea about how much time it can take to build a product that users can use and get the most out of it.

If you sum up everything in John’s example, he will invest approx 10–12 months of time to build and launch a product that can get some value to John and app’s users.

Where is John wasting the time, money, efforts in his product?

Well, I would say, John is wasting time, money, and efforts at almost every stage of the traditional process in various cases. Let’s see how.

First, generally, product development teams have different stack holders. And, they rarely meet for the common goal or objective. If they meet, they get trapped in endless and messy discussions.

Second, when they are trapped into discussions, they start getting changes, back and forth starts happening in design and development, and many more things can happen. Most important, teams start getting the frustration, they lose enthusiasm and focus during this process.

Third, sometimes they start getting negative feedback from the early adopters. These can be major feedback and change the product’s direction.

So, you can see that there is a lot to lose for John with the traditional process.

Also, let’s think of the worst situation. John was having a very limited budget. And now, he has wasted all that budget. As a result, either he has to shut down the product or he has to look for the investor.

Quantifying the loss

Let’s say, John hires a team of 5 members to build the product. So it is a team of total 6 members (including him). Consider that the product would last for two or three iterations and take 12 months of development time.

John would waste 12 months of the time of 6 people, i.e. 72 months.

If John would pay $2,500 for each member, he would waste $150,000. Plus, all the infrastructure, maintenance, support, digital marketing, etc. expenses.

And, all the efforts of 6 people for 12 months.

ROI of Design Sprints

John would have saved him all the wasted time, money, and efforts; he wouldn’t have lost enthusiasm, focus, direction, motivation had he opted for making Design Sprints a part of his process.

How?

The Design Sprint brings team members together to think and work on a specific goal (a north star) that they think is important.
You eliminate most of the unnecessary verbal discussions and efforts of strategy, thinking, designing, building, etc. between build and launch stages. Discussions happen in form of content, not audio. So no messy and unstructured discussions within teams.
It is a time-boxed. It is a 4-day or 5-day process. So you get (kind of) immediate results (at the end of the week).
Tangible actions and outcome which helps the entire team to stay focused on the goal.
It enables you to test the potential of your idea without doing a single line of code. You build a high-fidelity prototype and test it with your target users.
It gets you insights (feedback from user testers) on your ideas or solutions. That helps you to decide if an iteration is required to the idea or not before starting the development. This means you’re lowering the risks. You get the risk-free stage to pivot your ideas.
You start investing your time, money, efforts to build and launch the product with confidence.
Impress your key stack-holders, investors, target users.
Maximize your ROI. If we look at the traditional process, it starts with some ideas, you build and launch it to get feedback so that you can build more ideas to make it better. You just saw that it takes months of time, money, efforts of the entire team. With the Design Sprint, you’re saving all of that.

In our example, John would have achieved more with $150,000 and 12 months of time had he opted for the Design Sprint.

The example that we took was for a digital product, but you can connect it with any of your big challenge related to the digital or non-digital product, process, service, experience, etc. Here’s an example of how to use Design Sprints for your organizational processes. You can find more case studies at Sprint Stories.

Conclusion

I don’t say that Design Sprint is a solution to everything. But it is 1000 times better than the traditional silos that organizations and people have built.

You should run Design Sprints when

You have a big project or a big challenge to solve and you’re just starting out with it
It’s going to take a lot of time and money
You don’t have sufficient time to test something big
When you get into deadlocks
Restart when you get a major failure at something
There is low motivation
When an organizational structure becomes a hurdle

Happy Sprintin’

Got any questions? Reach to me over Instagram.

Liked it? Give a few claps to this article. Maybe 50 claps! 👏👏👏👏👏 x 10.

And, if you loved it, share it on your social profiles. Hehe! 🤓

👉 Get the Design Sprint Quick Start Guide for FREE to start running Sprints on own.

👉 Get our Design Sprint Master Slide Deck to run and facilitate Sprints like a PRO at $30 off.

Thank you!