Why I Believe in Design Sprints

During a recent call with the team, our founder Robin Dhanwani opened up about how he was inspired to experiment with the Sprint methodology and adopt it at Parallel.

After reading Jake Knapp's book Sprint, Robin built on the Design Sprint methodology to help government organisations and young startups alike innovate faster with less risk.

Sharing his personal observations on design engagements before the Sprint approach, Robin also highlights how running sprints helped him address several bottlenecks.

‍

Transcript

⏱️ Before Design Sprints: wasted effort and long delays

What was happening is — whenever we get into a design engagement with our client, they would most likely, 80-90% of the time, come to us and say, "My product sucks. I want to redesign it completely".

We'd end up working with them. [We'd] plan a project for six weeks, eight weeks, and it will end up taking three months, four months. After we are finished with everything, they'll go to the developers and say, "We want to build this".

The moment they start building it, they'll realise, "Oh, this will take us a year to build". It's not realistic. So they will strip off half the stuff, they'll build something, and they'll remove something.

Six months down the line, they'll build something, and it'll be nowhere close to what we had designed. By that time, one year has gone from the time we started the engagement — the market has moved on, the competitors have built other stuff which is way better, and half theproducts don't launch.

💰 The real problem with the traditional design process: no real value

So what was actually irritating me is that we were not able to add real value to clients, in terms of actually getting business benefit out of what we are doing.

It was just taking too long to finish work, because the minute we do some stuff, they say, "No, no, this is not nice, let's try more, let's try more, let's try more options, let's try more options, let's try more options". It'll take too long for us to get done with design, and then way way longer for them to do development.

There was no real value getting added.

🔔 Trend alert: design moves in-house

At the same time, design around that time was going in-house.

Good product companies were building in-house teams for the same reason — where they realised that design is not something that you do once and forget about it. It's something that you can do as a visioning exercise, and plan your vision, and test it.

But then, when you're doing design at a tactical build level (what is going out in the next two weeks, three weeks), it needs to be very closely aligned with what the tech team is able to build. You can't spend so much time on just trying to make something perfect.

😍 My first Design Sprint

When I ran a Design Sprint with some clients the first or second time, we realised the kind of ideas that we could come up with were not incremental — they were exponentially better. And [we realised] how we could actually engage the team and get really cool ideas, rather than very tactical, incremental stuff, and in a short amount of time.

In a week, you could just make a leap which would have taken months otherwise, and still not got it.

😬 Two other issues that Design Sprints solve

There are many other issues that would happen working with clients.

The back-and-forth feedback would take months. You send something, they come back, and then not all stakeholders are aligned. Somebody else will say, "I like it, but my boss doesn't like it", and then you have different calls.

There was a lot of busy time without any productive output happening, because the people who have a big stake and say in the product decisions and the designs were not part of the design process. They don't understand how we came up with a particular design or solution. They didn't have any background story. They would just look at the final output and react to it. The final solutions were always disconnected with, what problem did we try to solve and how did we come to that point?

When I ran a sprint, I saw [how] I can have these very high-level stakeholders in the room, and work with them, get them to be a part of solutions. There was complete alignment. They were bought in. And in one week, we were able to make rapid progress.

Also, we were able to disconnect the solution layer and the presentation layer of our work. What I mean by solution layer is, just solving problems and coming up with ideas or solutions which will actually solve problems and give business impact; versus just trying to make it pretty and visually nicer.

We were able to separate both because of the way we were approaching it. [This] had huge gains because, a lot of times, we were just getting biased with how things look visually and just spending forever making them perfect without solving the problem and getting distracted. But, in this approach, we were able to solve problems, test whether they're working or not, and once we were confident, that's when we were moving on to saying, "Okay, now this is done, this needs to be built, so let's take parts of that and make them visually better (where they're ready to go to production)".

💛 for Design Sprints

So I was very sold the moment I did this [Design Sprints] the first time itself. Actually, I was sold the moment I read the book itself [Sprint by Jake Knapp], that we could use something like this to really accelerate the pace at which things are done.

Being a self-taught designer and being very connected with the design ecosystem, I could see the pain — that what we are doing will not actually add value to companies in the earlier format.

Loved this video? Subscribe to our Youtube channel to get all the latest videos.