Turning Challenges into Opportunities with Design Sprints

This was originally published on the Tendril blog.

Tell me if this sounds familiar:

A new idea for a product starts making the rounds on your team. The idea sounds smart. You have alignment from stakeholders. The team is excited to work on it. The best and brightest are put to work for days, weeks, months designing and building this new idea. You can’t wait for the world to start using it. Launch day comes and goes. You celebrate all the hard work and late nights that went into getting to market so quickly.

Then something doesn’t happen…the numbers don’t show up; adoption isn’t growing, you’re not hitting your targets and people aren’t using the features you’ve invested months developing. The product must be a flop; logically, you start phasing out support. You may even discontinue the product and move your best and brightest onto the next and newest. Silicon Valley has been telling us to fail fast for what seems like ages now, but did we? And what did we learn?

The problem

Countless organizations jump directly from project kickoff to a fully fleshed out design of a new solution without researching user needs or validating ideas. But when you don’t know what your users truly need to do, you end up building for everything they might ever do. Or worse, everything they might never do. The result is often an over-architected solution that took months and even years to develop, only for it to never really take off. Quantitative data is compiled and analyzed, but we’re still left scratching our heads asking ourselves “where did we go wrong?” Without proper user research, you can’t really understand why your product failed, only that it has.

Let’s think about this another way using a well-known analogy. Imagine that you need a new car, what would you do first? Well, you’d probably figure out what you needed it for. Do you have a long commute? A family of four it needs to seat comfortably? Pets? Gear for sports and recreation? Once you’ve figured that piece out, you’d ask yourself what’s important to you: reliability, reputability, flashiness, new or used? From there you’d likely start to research your options online. You’d talk to friends and family about their experiences with their cars. You’d ultimately find an option that meets your criteria but also fits your budget. You would test drive it. On the contrary, you would never walk onto a lot and drop even $10k on a car you’ve never seen or done any research on and hope that it just works out. So why drop hundreds of thousands of dollars on a product when there’s little understanding of its viability?

Design thinking fills fundamental gaps that many organizations have: it helps teams better define the problem they are solving for, sheds light on what their audience truly needs and relies on user-centered design practices to make sure the right solution is created. Design thinking offers tremendous value by de-risking products and empowering teams to make a go or no go decision based on empirical insights — so why aren’t we all using it? Many of us are pushed to deliver faster, meet increasingly shorter deadlines and get to market quickly for fear of being left behind — all the while short on resources and budget. And even though the long-term benefits of design thinking are indisputable, the upfront time and commitment needed for research, testing and iteration can seem daunting for those of us feeling pressured to deliver.

The Solution

Tendril embraces experimentation at all levels of the organization, so to ensure we’re doing our due diligence for users while working quickly, we’ve started using Design Sprints — a process that is meant to capture all of the wonderful benefits of design thinking in just one week.

Developed by a few folks over at Google Ventures, a Design Sprint is a five-day exercise that helps companies solve big challenges in a small amount of time. Their findings and step-by-step instruction for running a Design Sprint can be found in their book, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.

Photo credit: http://www.gv.com/sprint/

With Design Sprints, we’ve been able to identify things like what product features are must have versus nice to have and how to mobilize our teams around the right initiatives. And don’t let the term ‘Design Sprint’ fool you — this method can be used to solve just about any business challenge. And, bonus, you don’t need to be a designer to participate.

At Tendril, we often hear about how our utility partners want to find new ways to engage and delight their customers, but keeping up with customer expectations is often a challenge. For utilities looking to quickly prototype and test new engagement strategies, Design Sprints can help answer a lot of important questions without being delayed by regulatory, time or budgetary constraints.

How it Works

Your Team

To run a sprint, you’ll need a small (no more than seven people), cross-functional team. There are a couple of defined roles you’ll assign, such as the Decider — any time a decision needs to be made, they make the final call — and the Facilitator — they keep the team focused on the process. You’re encouraged to include experts from varying facets of your company: marketing, customer service, finance, tech, creative, etc.

One of the best people you can and should include is the person most likely to pushback against your project. Sprint refers to this person as the Troublemaker. Including them will make it easier to get their buy-in and may even give you valuable, contrarian insights to the problem that the rest of your team wouldn’t have come up with.

Your Schedule

The sprint is scheduled across five days, concentrating on a new initiative each day.

Monday: Goal Setting

You’ll start by setting your short and long term goals, identifying a specific target to focus on and turning potential risks into questions. For example, “Customers may not understand how to use our new mobile app,” becomes “How do we make sure customers understand how to use our app?”

You’ll also conduct expert interviews that can vary from internal stakeholders to partners, customers and other third party players.

Tuesday: Research and Sketch

You’ll spend the second day looking into how other companies are successfully solving for your challenge. This could include companies both within and outside of your industry. For instance, if your utility is looking to help customers better understand their bills, you might look into how other usage-based services present billing data, such as mobile and internet companies.

Next, your team will sketch out ideas to solve to your problem. Using a multi-step approach, you’ll look at all of the notes taken during your expert interviews and inspiration research, jot down initial ideas and perform a few iterations of sketching. You’ll end up with fairly concrete ideas to vote on the next day.

Wednesday: Vote & Storyboard

The team votes on which sketch or sketches to move forward with and storyboards them into a solution. Storyboarding helps find points of contention and questions that need answering as you head into prototyping.

Thursday: Prototype

Since you have one day to do this, the goal is to make the prototype is realistic as possible without spending too much time developing it. The authors of Sprint refer to this as “Goldilocks Quality.” For instance, let’s say your solution is a better way to show customers their energy usage within your customer portal. Instead of trying to get something coded and operational within a day, you can simulate the experience using slides. And don’t be fooled into thinking this is a designer task, every member of your cross-functional team will play an important role in prototyping.

Friday: User Testing

You’ll use a small sample size to test your solution with real customers. Consistent with Nielsen and Landauer’s testing methodology the Sprint authors recommend testing with five users to find the major flaws and strengths of the solution.

Keep in mind that your job this week is to be wrong. It’s not a good feeling, but it’s something you need to become accustomed to. The first thing you build is going to be somewhat wrong, and the user feedback you receive Friday will give you the direction you need to keep moving with minimal investment. You’ll walk away with invaluable insights, immediate next steps and action items for your team.

Lessons Learned

Every sprint we’ve done so far at Tendril has been a flawed success. Sometimes our ideas are proven to work, while others fall flat. Either way, we gain insights and learnings that would otherwise take us weeks or even months to uncover. We recently ran a Design Sprint to improve our Engagement Portal. In this particular sprint, we had three big feature ideas. After our one week Design Sprint we discovered that two out of three ideas completely bombed. And that’s great for us because it’s two fewer features to build only to never be used.

Since we’ve started running Design Sprints, we’ve noticed something else change in our organization. There’s a greater sense of team camaraderie. Having gone through a rigorous design thinking process, Sprint teams are more confident in their solution and are proud of the outcome. There’s greater alignment since they have all met with stakeholders and experts, been instrumental in making strategic decisions and have heard from the users themselves. It’s a less quantifiable outcome, but no less meaningful for an organization.

Conclusion

Because you have the focus time and the right people in the room, Design Sprints condense what could take weeks of many meetings with many of the same stakeholders into five days.

A Design Sprint takes every potential weakness of traditional product discovery — not asking the right people, having the wrong requirements, going off on tangents, overthinking a solution — and turns them into strengths. The structure ensures experts are consulted, the problem is well defined and there is no time for tangents or over-analysis. So the next time you’re faced with a new challenge, take five days and run a Design Sprint, you’ll be amazed by what it could save you.