Hi there, Product People! Carlos here with Product Management essentials and insights. If you work as a Product Manager, chances are you've heard of the Design Sprint. And if you haven't, well, now’s a better time than any to learn! They’re intense and challenging, but are also fun and quickly generate valuable product ideas!
What is a Design Sprint?
There are two elements that form the foundation of a design sprint: time-constraint, and speed.
Jake Knapp developed design sprints at Google Ventures (GV) in 2010. It "uses design thinking to reduce the risk when bringing a new product, service, or feature to the market." Since then, it has become a powerful movement that helps Product Teams at Google, developers, and companies in the industry solve design problems quickly. But it's grown beyond just design, and can help Product Teams tackle tough problems, find quick solutions, and intentionally make an environment open to creativity and new ideas.
Though the original design sprint was 5 days, best practice is now 4 days. Depending on the problem and the team it can range from 2-5. Every organization has their own version, fit for their product, sector and staff. However, the key principle behind a Sprint is to save steps in product development and release. A short-time constraint is necessary and it highlights the “survivalist” nature of the Sprint: only what is useful will be kept in the end.
A design sprint helps you put the product in front of your users as quickly as possible. As the founder of Linkedin, Reid Hoffman, once said: “If you are not embarrassed about the first version of your product you show to your users, then it means you launched too late.” Design sprints also allow you to iterate and test ideas quickly, reducing time and resources invested in bad ideas.
In the past, the Product Development process was:
build -> launch -> measure -> iterate
The issue is that building often takes too long, there’s no going back if you get new info, and the results are inconclusive. A design sprint solves this by forcing a fast ideation/prototype/test cycle.
Hosting your next Design Sprint: Step-by-Step
Make sure to follow these steps to ace your next team's design sprint! This is based on Jake Knapp's Design Sprint 2.0, a 4-day version of his original 5-day sprint. (Because yes, Jake Knapp ran a design sprint on his design sprint model to iterate and make it even better.)
Day 0 - Prepare
Before your design sprint, you must identify the objective by choosing a "big" problem your company needs to solve. Define the main problem your product needs to solve and why it matters in the broader context of your company and the market. Then, you need to go get the right people together to start the process.
The Team
You'll need a designer, a decision-maker (the person who has the final say in the Sprint decisions), an engineer, a user expert, and yourself (the Product Manager). Ideally, you should also include other interested parties like marketers or key stakeholders.
Pick a facilitator to manage the sprint/keeps things moving. This person should be confident leading a meeting, including synthesizing discussions and nicely telling people to be quiet and be okay speaking less. Sprints can be led by anyone, but Product Managers are particularly well-suited for the task: they work at the intersection of many vital functions (design, development, user research, marketing, etc.) and thus they are perfect for “translating” doubts and achievements across teams.
The Tools
If you're running this experiment in person, get tools like sticky notes, whiteboards, dot stickers, paper, timers, snacks, and tape. If you're doing it remotely, all you'll need is to make a copy of this design sprint template and set up a video conference on your platform of choice.
Day 1 - Define the challenge. Product solutions.
Define the sprint challenge with the team.
Define the long-term goal of the product or feature.
Set design sprint questions.
Create a user touchpoint map.
Run a lightning demo to come up with solutions.
Run a sketch session to narrow down and visualize solutions.
Day 2 - Vote on solutions. Storyboard.
Highlight and discuss interesting solution ideas.
Vote on solutions.
Create a user test flow.
Draw a storyboard.
Day 3 - Prototype
Not all team members have to be in the room on Day 3, just the ones responsible for building out the prototype. Keep it simple! Only building pieces of the product or feature you want to test with users.
Day 4 - User testing
Conduct user tests and document their reactions, comments, and behavior. Analyze feedback and note down key takeaways. You’re done, and hopefully with a strong MVP in hand!
Check out some of the previous issues:
Building a Product Mindset for Yourself and Your Organization