A design sprint -or a mini-design challenge- is one way to simulate strategy development using basic principles of design thinking. Design sprints can be used to help organizations bridge silos, think differently about teaming and re-examine a challenge that keeps rearing its head. A design sprint happens in a condensed period of time (anywhere from 90 minutes to 2 days); has a framing question (e.g., "How might we redesign meetings?"); and requires teams to work with constraints to develop quick and dirty prototypes (everything from a doodle poster to a wireframe mockup) that can be validated with some basic feedback. Here are six takeaways about strategy that design sprints reveal.
1. Expand Your Definition of "data". In a design sprint you often have to collect data in the form of conversations to gather anecdotal evidence. Remember that stories are data too. Quantitative data shows us patterns. It can be enriched by qualitative data, which tells us why certain behaviors are happening. An integration of the two methods is ideal.
2. You Are Not Your Customer! This may seem obvious, but many companies fail because they build services or products loaded with assumptions because they've been having too many internal conversations. Get out of the building, and onto the street. If we do not shorten the feedback loop from concept to finished product or service with real people, we lose valuable time to get insights. So talk to your customers and learn from them.
3. Show Us, Don't Just Tell Us. Visualization gurus like Dan Roam, Sunni Brown and Information is Beautiful prove that communicating complex ideas is best done through simple visualizations. After you've nailed the basic concepts consider converting your solutions into fancier infographics, for even greater resonance with the marketplace. Have you noticed the newest Amazon ads featuring whiteboard marker sketches?
4. Failure is Feedback. I love this phrase because of the positive interpretation of something we all cringe at: making mistakes. If you begin to practice regular reflection and ask what can be learned at every revision and breakdown, then all of a sudden a ton of opportunities appear. Which leads me to the next point:
5. It's all about "The Build". Building on ideas can only happen when we expose our ideas to colleagues beyond our team of 1, 2 or 3 people, go into other areas of the company or market for feedback and assess the next iteration. It also creates buy-in which is helpful when we are ready to shift from prototype to product launch.
6. Reframing is Strategy. I define strategy as the art of reframing the problem. The best way to do this? Ask better, new and different questions. How do you ask new questions? See point number one!