Design Sprints: A Leaner Approach to Lean Startup
This blog was written by Andrea Hill via Waffle’s brand new Just The Toppings program. Interested in contributing? Email us at megan@waffle.io
When Eric Ries penned “The Lean Startup” in 2011, he had no way of knowing to what extent this scientific approach to product development would be embraced by companies of all sizes around the globe.
Based on rapid build-measure-learn cycles to ensure customers are engaged throughout the design process, the lean startup approach quickly became adopted by product management teams of all sizes, even those who were well past the riskiest stages of launching a startup.
My own lean startup experience was in 2015, when I ran ReadyTalk’s first internal startup, UbiMeet. ReadyTalk is a web conferencing provider and we launched a meeting productivity app to handle what happened before and after your web conference. We followed lean startup principles; focusing on continuous experimentation to drive our product roadmap, positioning and pricing. It was a blast and I felt more ownership over that product than anything I’ve worked on before or since. But while we created and set experiments to learn about how people set agendas and followed up after meetings, there was a lingering doubt in the back of my mind: were we solving the most important problem for our target users?
Were we experimenting to de-risk the overall concept, or to optimize how to design or develop a given feature?
In the case of UbiMeet, we started out with a product concept in mind, and then experimented about the edges of the solution. We’d get good feedback around features as we implemented them, but the overall product didn’t get the traction we’d have expected. People claimed they had this problem, but they weren’t using our product to solve it. In our aim for rapid validation, we’d jumped ahead to optimizing a solution, rather than validating a problem.
How did THAT happen??
Fast forward a year, and we shut UbiMeet down. We had invested a fair amount of time and resources, but our build-measure-learn cycles just felt like we were spinning our wheels and getting nowhere.
We still wanted to add another product to our portfolio, however, and I implored our stakeholders to take a step back. Rather than jumping to solving to a problem we assumed our target customers had, I wanted to talk with customers first, and ‘see what problems/concepts bubbled up’.
With the pain of 11 months wasted on a project we shut down still weighing heavy on my stakeholders’ minds, you may think they’d be resistant to my requesting what seemed like an even longer path to product.
Fortunately for us, the GV Design Sprint process was there to guide us through customer discovery, design, prototyping and testing — within a single week!
What I love about the Google Ventures Design Sprint process, as introduced by Jake Knapp, John Zeratsky and Braden Kowitz in their 2016 book Sprint! (How to Solve Big Problems and Test New Ideas in Just Five Days), is that before you ever start to design, you listen to your customer. The design sprint brings participants through inspiration and divergent thinking before narrowing in on something to test, and then actually getting customer reactions — all within a five day period.
This limited scope makes for a much easier investment for a company to make. And by starting with gathering customer insights, you can be sure your time is spent on a problem your customer really wants to be solved.
Business stakeholders talk about revenue-generation and cost-reduction, and the design sprint can help with both. You can rapidly come up with great new products, or as in the case of one of our sprints, you can get the signal NOT to develop something.
One of our key stakeholders was sure that if we just added one (admittedly big) feature, our product would be a huge success. We ran a design sprint and were shocked at how strongly our target audience objected to the concept. They saw it not as helping them do their jobs, but replacing what they most enjoyed about their jobs. Without those interviews, we may still be talking about that feature (or worse, building it!). Instead, we refocused on only solving things that needed solving. :-)
“Within a week’s time, Andrea guided the team through a design sprint that helped us identify a new role for our teams to target and what was important to them, and perhaps most importantly, provided prototypes of how the key customer wanted to visualize the data.
Our product and engineering teams pulled this specific concept into our newly launched platform, and truly delivered value to our customers.”
- Beth Toeniskoetter, Business Line Manager at ReadyTalk
Thinking of Running Your Own Design Sprint? Five Steps to Success:
- Pick a Critical Problem to Attack. Don’t waste your team’s time on small problems. You’re taking a week to dig into the problem, make it a good one.
- Involve Your Stakeholders. Design sprints aren’t just for designers or PMs to go off and work; bring your stakeholder (‘the decision-maker’) into the week as much as possible. The bigger the problem you pick, the more he’ll care about the outcome.
- Be Willing to Do Something With Your Findings. Don’t run a design sprint just to say you’re “doing innovation”. If your team uncovers something surprising, be prepared to follow that path further. It could lead to something great!
- Respect the Process. The design sprint process is tried and tested; follow the guidelines so you’re focusing on finding the best solution to your challenge rather than coming up with processes.
- Recruit Early! Getting the right people to talk to on Friday is the key to ending your week on a positive note. Spend the time to identify and recruit people who can give you feedback on your hard work.
The design sprint process elicits rapid, customer-driven learnings just like those that made lean startup so compelling, but it shortens the time and increases the depth of the learnings. Nervous about getting into a never-ending cycle of optimizing the wrong thing? Try this out for a week. What do you have to lose?
