On product teams nowadays, it seems like everything is about speed. If your product isn't not the first to market or the first with a new feature, you might as well not bother.
But we all know that building winning products is about more than speed.
Napster pioneered digital music sharing in 1999, and Pandora's user base was 13 times bigger than Spotify's in 2012, but we all have that green Spotify app on our computers today.
The Rocket ebook and several other e-readers came to market in 1998, followed by the Sony Librie in 2004 and Sony Reader in 2006. Kindles weren't released until 2007, but now they're synonymous with digital books.
Google beat Yahoo, Gmail trounced Hotmail, Myspace fell to Facebook... the list goes on and on.
The products that win are the ones that solve the right problems, in the right way, with the right user experience.
So how can you tell if your product is on the right track? How can you know if your product is what users actually want?
As you probably guessed from the title, Design Sprints are a solution.
No matter what stage your product is at, Design Sprints are a great way for product managers to become more design-driven. They help teams reliably build products that nail both problem and product experience — without wasting time and money.
A Design Sprint is a five-day process where a diverse team works together to understand, prototype, and test their solution for a big business problem. If the solution is a winner, it goes straight into full-blown product development.
The Design Sprint framework was initially incubated at Google Ventures by Jake Knapp, who launched Gmail and Google Hangouts. Modeled after IDEO's design-thinking framework, Design Sprints have been used by companies like Uber, Slack, Blue Bottle Coffee, and Coca-Cola.
In 2016, Jake and a few GV design partners published Sprint, the famed blue book that blew up within the design and innovation community. (It even became a New York Times and Wall Street Journal bestseller too.)
Since the book's release, product teams worldwide have consumed, tested, and adopted the framework. Without a doubt, Design Sprints have changed the way organisations of all shapes and sizes now approach new product and service development.
The Design Sprint framework helps teams quickly identify the right problems to solve and test their solution through rapid prototyping and user feedback. Within a week, teams can move from an abstract idea to a high-fidelity prototype tested with real users — efficient, quick, and easy on the budget.
Many product teams believe that they already know what their customers want.
"Most of our ideas are wrongheaded. In fact, 60–90% of ideas do not improve the metric they were intended to improve. You can invest in convincing people why your idea is the best, or you can invest that time in testing it to find out."
– Barry O'Reilly
Here is where Design Sprints can be most effective for product teams. They help answer questions like...
By answering these questions, product managers can create backlogs based on validated user needs that solve business problems, rather than based on feature requests or gut feeling.
This sense of purpose is quickly validated with insights from real customers:
"They also offer an important insight that’s nearly impossible to get with large-scale quantitative data: why things work or don’t work.”
– Sprint, Knapp, Zeratsky, and Kowitz
Design Sprints are a validation machine that tells teams if they are on the right track, and if an idea is worth their time and effort. More importantly, they help teams plan and prioritise feature releases, based on actual user feedback rather than hypotheses.
Design Sprints are an efficient tool to bring everyone on the same page—from understanding the problem at hand, figuring a solution, and estimating the efforts required.
A sprint that we ran with NITI Aayog is a good example.
The team didn't have a product. Instead, they had a vision document of what the product needs to be in three to five years.
We had to figure out what was the right starting point. What does the product need to be in the first six months? We spoke to key stakeholders and decision-makers, many of whom had different ideas. So our challenge was to come together and set one milestone for the product.
Just two weeks after running a sprint, the NITI Aayog team began its product development. The outcome of the sprint was so clear and specific that they were able to revise and recreate their RFP without any ambiguity.
Design Sprints are an opportunity for everyone to contribute to the product's success for two main reasons.
First, decision-making is democratic and much faster than several rounds of meetings that not everyone may be on board with.
No one has a passive role at the sprint. Everyone is encouraged to share and speak their mind. There is no such thing as bad ideas. In that room, on that call, everyone is a designer, and they are in charge and responsible for a product's success.
"Design sprint exercises allow participants to peel back the complexities with discrete thought experiments. This gives stakeholders more visibility into the nuances of the problem and the workings of the potential solution. The more visibility, the more likely a proposed solution will get support from all involved."
– Richard Banfield
Second, a Design Sprint relies on a diverse group of people drawing, sketching, and voting on ideas and solutions together. It brings different teams and and domain experts together. For many of these people, if not most, it's the first time they meet and collaborate.
"Simply getting people talking, disconnected by an organisation's complex structure, is an undervalued part of the Design Sprint process."
– Douglas Ferguson
John Zeratsky, one of the authors of Sprint, and Jake Knapp recently explained why they built a framework that bounces between individual and group tasks.
"Individuals are great at coming up with ideas. Groups are great at making decisions. The cliche is the wisdom of the crowd; like all cliches, it's a cliche for a reason because there is truth."
– John Zeratsky and Jake Knapp
The Design Sprint framework is designed to empower individuals and support teamwork. By working together, alone, teams can harness the energy of the crowd for effective decision-making.
Running Design Sprints allows product managers to adopt a prototyping mindset. This helps them justify if a product will get traction before they write a line of code or get emotionally invested in their ideas.
Jake Knapp expands on this idea in the Sprint book:
"The longer you spend working on something, whether it’s a prototype or a real product— the more attached you’ll become, and the less likely you’ll be to take negative test results to heart. After one day, you’re receptive to feedback. After three months, you’re committed."
– Sprint, Knapp, Zeratsky, and Kowitz
Design Sprints are about moving from wanting perfect to just enough, from long-term quality to a temporary solution. Instead of spending months on design and code, getting all the details right, and waiting for quantitative data post-release, it's best to build a facade to get quick, honest feedback from users.
Not only are quick-and-dirty prototypes cheaper, but it's also easier for teams to objectively assess a quick prototype, rather than beautifully designed screens or working code that they've spent months on.
Here's an example from Sprint. While working on their product, the team at Slack wondered what the best way to explain Slack to non-tech customers was.
They had two ideas:
Five days and one Design Sprint later, Slack had a clear answer on which was the best solution for their product — with no emotional or code commitment.
Because Design Sprints produce something tangible so quickly, teams' roadmaps instantly become pragmatic. With fewer unknowns, from estimating and ideating to prototyping and validating, there are fewer delays and projects move faster.
After a Design Sprint, a product team can create or alter their roadmap, change priorities on their product backlog, and go straight into development. Or they can also choose to focus on the prototype further, and flesh out the remaining features, user flows, and screens.
Business goals and design processes tend to be disconnected. A Design Sprint can bring them together, since its three outcomes appeal to both teams' needs:
Building a prototype to quickly test its potential can help product managers effectively raise funds and unlock budgets for ideas that might have otherwise ended up on a back-burner.
A single successful Design Sprint may not cover every decision required for a product or feature release. However, it will provide evidence that teams can use to gather approval from key decision-makers and other stakeholders.
This show-and-tell approach has changed how startups, government organisations, and enterprises think about design. As design teams show how their work will affect the bottom line, they get a seat at the table and more influence over how products are built.
A Design Sprint that doesn't end with a validated prototype is not necessarily a failure.
If a team doesn't find a working solution, they can re-look at the original problem and how they understood it. Was it meaningful? Was it worth solving for the customers?
If there are more questions than answers, it only means that the team has a lot more to consider before building their product or service. Richard Banfield sees this as a positive:
"If none of the solutions you build and test work, you've discovered what won't be a good solution. This is a good thing. You just saved time and money."
– Richard Banfield
In addition, insights, observations, and recommendations from users who tested the prototype can help a team move quickly to their next idea or reconsider their priorities on the product backlog.
Here's why we believe Design Sprints are a useful instrument that product managers can use to become more design-driven and customer-centric.
Check out these related blogs: