One Man’s Quest to Run a Design Sprint
If you work in the design or innovation space, you’ve probably heard of Google Venture’s Design Sprint process or amazingly awesome book, Sprint! I got a copy back in the spring of 2016 and it opened my eyes to possibilities of work life, team structure and problem solving.
Admittedly, I am a slow reader — yet was able to burn through this book in 24 hours. I then reread it a week later as my designer heart filled with ideas and hope about the future.
What if this is how we worked all the time? What if this was how we tackled projects or opportunities? no more waterfall, no more planning 18 months ahead of time to put a “strategic vision” in play… No more! Now we’d have immediate testing of assumptions and ideas with real customer feedback — the world would change for the better!!
Alas, the rational part of my brain began to poke holes in this fantasy. I work at a large personal insurance firm where change is … hard. Getting people to break out of their silos and work cross functionally without ego and entitlement is tough — we’re structured and incentivized to act in this way. The Sprint process is the antithesis of this. So how might we change this?
I thought, “I must talk to our leadership about this.” Then I said — well that’s how I’ve always approached things in the past and maybe that doesn’t work as well. So, I bought each VP a copy of the book, delivered it to them and said, “Please, you must read this. It’s important to the way we work and approach problem solving. I bought it for you to read, you don’t owe me, just please read it.” and then walked our of their office.
This was pretty brash but I had to do something emotionally charged to these hyper analytical leaders. When they receive emails or comments in passing, their more likely to just shrug it off or forget about. I thought if I led them to the water, they might just drink it. To my astonishment, they read the book.
Although they read the book and seemed to even agree with its framework, things didn’t change as fast as I would have liked. Honestly at that time, I was not in a position to be able to drop things and run a test sprint (I was Product Owning/UXing 2 enterprise applications). But we kept pushing this idea at staff meetings to the point where my VP would answer for me in some cases:
Group question: “How should we be thinking about our research and buy-in strategies for this set of journeys next year?”
VP: “Drew — we know, Sprint is the way to do it.” (Me smiling)
I noticed too that there was a gap in our team’s understanding of design thinking. We all knew what it meant but very few of us had practiced it. Having practiced the methodology often before, I volunteered to run a 90-minute design thinking boot camp for our department to get people involved in the process and relate this back to the Sprint methodology.
This worked wonderfully. People were highly engaged in doing the “wallet project” from the Stanford dSchool and many exclaimed “I never knew that design thinking was actually like this!” — #hooked!
To reinforce the new skill set these new design thinkers were building up, I designed a prototype bot (Miles, the design thinking robot) that would lead users through the design process. It’s still in beta but if you want to check it out, please do on Invision’s prototype platform.
This was working — people were talking about design thinking. They did an exercise, they were finding ways to fit into their work life — awesome! right? Well, I still wanted to run a design sprint.
Several months later, I had transitioned off of my Product Owner/UX role and into a more UX research/designer role focusing on service delivery opportunities. This was an amazing change up and it opened a new door for potentially using the design sprint process. My new manager had witnessed my several attempts to build up a familiarity and comfort with design thinking and design sprints and so he offered to let me run with one for a big opportunity that we haven’t been able to solve yet — premium increase communications. #awesome
With the bureaucracy out of the way, I was able to form a cross functional team made up of folks from our Product, Marketing, Front Line and Customer Advocacy teams. As a team, we were able to focus solely on our opportunity for 7 weeks and came up with some revolutionary ideas to transform how we talk to customers about their premium and any changes that occur to their policy costs. I will have another post later about our design sprint process — we deviated a little bit from the book. The book doesn’t talk a lot about the amount of initial prep and customer discovery that needs to take place before you get started, FYI.
The lessons I learned were that in order to make big change happen, I needed to think through who my change agents were and how to best approach them. For me it was not just the VPs (although their buy-in was key), it was the communication and on boarding with my teammates that helped. I noticed that the people coming up to me excited about this stuff and one’s trying to use the methods in their own work, were my real agents of change.
They helped me overcome the status quo and created a unified message of problem solving to our leadership and decision makers. This is key! Much like how the sprint process is a team effort, achieving change and buy-in is a team effort.
Notice who is responding to your message and how they respond. Get them onboard and help take some of the pushing off your shoulders and work together to make things happen.
Did you introduce design sprints at your company? How did it go? I’d love to hear from you!