Design Sprints

Episode #6 of the course Product management toolkit by Rich Headley

 

Welcome to lesson six. You’ve been using a combination of tried-and-true tools to get this far. You now know which problem you want to solve through a look at the Value Proposition Canvas. You have a Value Hypothesis for how you can solve it. Thinking about the Kano Model, you’ve come up with a basket of features that you think will have a good mix between meeting basic expectations, adding value beyond that, and even delighting the customer in some ways. You’ve also figured out how to prioritize all of your ideas using the RICE method.

Now, in many cases, you’re ready to start designing, building, and testing your ideas. But if the problem is big enough, you may want to challenge your ideas a bit more by bringing other team members to the table (and the whiteboard) with a Google Design Sprint. The point of a design sprint is to short-circuit the typical path of having an idea, building, launching it, and learning from it. What if you could go straight from idea to learning, without having to build or launch the product?

Depending on how much time you have, you could do this short loop in one to three days, but the most proper and effective timeline is five days. But hey, that’s much better than spending weeks or months building something only to find out you did it wrong.

The people you’ll want to invite to your design sprint could include people from the C suite, sales, marketing, engineering, design, product, and your user base. You want a well-rounded group of people solving problems with you. They don’t need any design experience, but what helps is if they are knowledgeable about the space you’re trying to solve problems in.

You’ll need a Facilitator—someone who’s comfortable cracking the whip and keeping everyone on schedule and in alignment with the process. You’ll also want a Decider, which is often you as the PM but can also be your boss or someone else who’s in the best position to make tough decisions when there isn’t a clear consensus in the room.

Here’s how the design sprint breaks down:

Day 1 is collaborative, and it’s purely about understanding the user personas. Who are they? What are their needs? What are the situations they’re in that cause those needs or make the needs more painful? Who are the competitors in the space, or what other analogous products could serve as some good inspiration? Which of these needs and personas do you want to focus on and what strategy do you want to take? You should do some expert interviews at this stage—key people who understand the users and customers—or you can even interview the users and customers themselves. These people don’t need to be present for the whole design sprint, so you can do several interviews on day one and get a lot of good information.

Day 2 is about diverging, where each individual envisions their solutions. It often starts with crazy 8s. No, not the card game you played as a kid—it’s where you fold a sheet of paper into eight squares and spend no more than a minute rapidly iterating on the same idea in different ways. This is called divergent thinking, and it’s meant to get you to think beyond what first comes to mind. You can do this process a couple of times for different areas of the problem space you need to solve. By the end of the day, no matter which independent thinking exercises you decide to have the group do, every individual should have their full drawing (or series of drawings) that represents the solution they have in mind. The important point here is that any text in the drawings should represent text as it would actually be on the page, not some explanation text trying to help someone understand the idea. The idea should stand on its own, without needing any explanation text. Everyone gives their sketch a title but doesn’t put their name on it. We want to be anonymous at this point.

Day 3 is where you decide on the best options as a team. Before the session, the facilitator hangs everyone’s ideas on the wall, kind of like an art gallery. It’s fun to have some music playing, and some cheese and wine out during this process. The point here is for everyone to individually vote on the anonymous drawings. You can use colored dot stickers or markers for voting, and everyone should get a certain number of votes that will allow them to support the best parts of each drawing, or the whole drawing by putting a vote at the very top. The decider gets extra votes here. After voting, the facilitator guides a discussion about the areas that got the most votes, where the people who voted explain what they liked about it. After voters provide their explanation, the anonymous artist reveals themself and provides further explanation of their ideas. This is also a chance for the artist to point out anything else that they thought was important, even if it didn’t get a lot of votes. At the end of the day, the group—and, if necessary, the decider—chooses the best ideas to proceed with.

Day 4 is purely about prototyping. You don’t necessarily need the whole group here. The decider and facilitator can work with a designer to build something quick and dirty to show the users. Hopefully, this designer has been in the whole design sprint and has all the context, which will result in a better prototype. The key here is to focus on usability, not making it beautiful.

Day 5 is where you validate your ideas with real users outside the company. You have to get unbiased, raw feedback from people with the actual pains and needs that your ideas are intended to solve. It’s best if you schedule these user testing appointments before your design sprint even starts. But what if we don’t finish on time, you might ask? That’s the point! You need to set a hard stop deadline for yourself to have a prototype by the end of day four. If you don’t, you’ll run the risk of losing your design sprint participants or suffering from analysis paralysis. So during this testing, you’ll hear some validation of your ideas, and also constructive feedback that will allow you to learn where you might have missed the mark.

In summary, this was a 5-day process that will make you much more confident that you’re building the right thing, and building it right. You can do a design sprint in multiple points of the design process: at the beginning of a project, when you’re at an impasse or have hit roadblocks, or when development has been slowly lumbering along and you need to more quickly arrive at a minimum viable product you can release.

In the next lesson, we’ll talk more about prototyping, and also about user testing.

 

Recommended reading

The Design Sprint by Jake Knapp

 

Share with friends