Product

Design Sprints: How to Get Buy In from Your Team

October 26, 2016

Design sprints have been consuming conversations over the past year, amongst all sorts of makers  – from authors testing out new book concepts to software teams working on the next VR breakthroughs. I mean, who wouldn’t love a prescriptive framework that enables you to validate your biggest ideas in 5 days?

But design sprints are new and disruptive to traditional approaches. That probably means that if you’re the one minting design sprints inside your company, you’re probably also struggling to get others to play ball.

Non-believers

Personally, when I first read about design sprints, I was excited and suspicious. I was brainwashed at Accenture to believe project plans always required months of requirements gathering and spec writing before a single discussion could take place about product design. How on Earth, then, could anything practical be accomplished in five days?!

But then something happened — I sat in on our first sprint we ran with a New Haircut client. Sure, it was sloppy compared to how we run sprints today, but even in that beautiful disaster there was an obvious lift in thinking, collaboration, energy and speed. We (and our clients) were instantly hooked.

Over the past year we’ve run dozens of sprints against our own ideas, as well as for the companies that hire us to design and build their digital products. But now, more and more, we’re talking with people on teams inside companies that have attempted to bring design sprints into their culture and hitting stiff arm after stiff arm…from navigating changing processes, to getting business leadership to agree, to the bevy of other one-line excuses.

Let’s break down these 3 types of pushback and arm you with some specific tips to help you bring design sprints into your organization, successfully.

New is Scary

For many, the idea of changing anything stirs up angst. When we kick off with large organizations to train their product teams on design thinking we hear all sorts of grunts and groans. For example, Project Managers want to know how a sprint will impact budgets and timelines. The truth is, by spending these 5 well-orchestrated days upfront, we’ve seen product development budgets and timelines shrink by up to 75%. That’s PM gold right there!

Tip: Share these two case studies to turn your PMs into your biggest advocates. 

Likewise, Creative Directors squirm that their design processes are already lean, agile or both. But I bet they’d love a way to efficiently capture stakeholder and customer insights upfront so their design teams have better direction with the solutions they’re building.

Tip: Ask them to define how the current design process works. After they’re done rambling for 20 minutes spend 5 walking them through Duco — an app we designed to introduce design sprints to anyone, at any level, in any function.

“5 Days in a Row Will Never Happen”

Everyone is busy. That’s why one of the biggest gripes we hear from people, especially those operating in corporate environments where you have meetings to plan for meetings, is that the idea of spending 5 days on a single topic seems impossible. However, the issue is that they’ve never had a real process (brainstorming is not a process) to raise an important challenge and identify a solution that didn’t involve weeks of emails, stakeholder interviews, meetings and more meetings. Design sprints provide that exact framework.

When these same people complete their first design sprint with us, not a single individual leaves the sprint week without acknowledging how much time they could have saved over their career had they adopted the process sooner.

Tip: Try to convince the team to spend time getting through Day One of the sprint. This should provide enough insight into how powerful the sprint can be, to get them to agree to finish the remaining 4 days.

Tip: A sprint team is ideally 4–7 people. If some refuse to spend all 5 days try to get them commit to Monday, 1/2 of Tuesday and 1/2 of Wednesday. The rest of the days can be managed by a core team of 2–4 people, and even (worst case) summarized for the larger team on Friday or one day the following week.

When All Else Fails, Pick an Excuse

  • “We’ve tried brainstorming meetings.”
  • “Our customers don’t know what they want.”
  • “We already did our research.”
  • “We are the customer.”
  • “We know what we have to build.”

Most of us are creatures of habit and comfort. We trust what we already know. So when it comes to deciding upon how to solve a really important problem, most want to jump right to the solution. We convince ourselves and others around us that we already know everything we need to know and can just get started. Unfortunately, it’s typically not until weeks or months later that the hard questions appear and you need to start from the beginning, all over again.

Instead, design sprints provide you with the tools and techniques to enable a team of individuals to arrive at the right solution, together, in five days.

Tip: When you hear the excuses come rolling in, ask out loud , “If this idea is so important, doesn’t it make sense to spend one week making sure we’re taking the best approach to solving it?”
Can your company afford for the answer to ever be “No” here?

Still Stuck?

No matter what you try and how persuasive you may be, for some companies, design sprints will always been considered DOA. Maybe the challenge wasn’t that important after all. Or maybe you haven’t worked hard enough to gain buy in from the team. Regardless of the obstacle, the above tips can help you win over your team so you can all move forward together.

Partner

Jay Melone is a Partner at <a href="http://www.newhaircut.com/">New Haircut</a>, a product strategy and training group based in NJ. They help product teams fall in love with the digital solutions they make, and how they make them. They offer <a href="https://www.newhaircut.com/design-sprint/">design sprints</a>, problem framing, and outcome-based roadmaps as part of their 4-week <a href="https://www.newhaircut.com/product-transformation/">Product Transformation Program</a>.