Seven People. Five Days. One Idea. Go!
One of the most challenging things I believe we all face in our day to day professional lives is finding the time to do ‘meaningful’ work. It’s all too easy to spend an entire day answering emails and jumping from one urgent task to the next, only to look back at the end of the day and wonder what it is that you actually accomplished. We’ve all been there.
It’s for this reason that the concept of true, uninterrupted work seemed so appealing to my team at work — the idea of spending time focused on a single (and meaningful) task. The idea itself isn’t a new one of course. You’ve probably seen it laid out in some form or fashion in any productivity book or blog you’ve ever read. But the concept has recently gained some added traction in the product management world, thanks to a book called Sprint, written by Jake Knapp and a few other guys from Google Ventures. The concept is simple enough — dedicate five consecutive days to digging into a single problem. The problem itself could be anything… from evaluating a potential new product within an existing business, to validating the idea for an entirely new business altogether. But no matter what the problem is, the goal remains the same: dedicating the time to really and truly exploring it.
The book is a great read, and I highly recommend it for anyone interested in learning more about Design Sprints, but at a high-level, the process goes something like this…
- Day 1: Map out the specifics of your problem. What’s your long term goal? What are the questions you need to answer in order to be able to get there? Who are the experts that hold knowledge likely to be of value to you?
- Day 2: Sketch out some rough ideas based on the information you’ve gathered during day one
- Day 3: Decide on a particularly promising idea (or two) that you want to build out and explore further
- Day 4: Build a prototype of the idea(s)
- Day 5: Test the prototype(s) with real users, and synthesize the insights you gain into some actionable next steps
Of course, that’s just a quick outline — there’s a whole book’s worth of detail around each of those steps! — but it gives you an idea of what’s involved.
Having recently read the book ourselves, our team decided to test the Sprint concept against a problem of our own — building a live chat experience on our company website. Live chat was something we had discussed in the past, but we’d never been able to find the time to take it beyond the conceptual stage. That said, we had reason to believe that live chat would add some real value to the user experience on our site, so there was a definite upside to figuring it out. It was for these reasons we thought it would be a great fit. So we decided on who the right team for the Sprint would be, pulling in a mix of subject matter specialists, and with that, we were off…
Well, almost. As you can imagine, finding five consecutive days for an entire team to block out their calendars and commit to nothing else but this singular project was tough. We had to look a few weeks out, and even then some of us still needed to move things around. But, we were dedicated and eventually found the time to make it work.
With that figured out, we turned our attention to the other challenge we knew we were going to be dealing with: the fact that everyone would be remote. Most of the time, these Sprints are done in person, with everyone sitting together in a room somewhere, making particularly heavy use of a whiteboard and Post-it notes. In our particular situation however, that wasn’t going to be feasible, so we had to figure out how to make the process work in a fully-remote and therefore, fully-digital, setting. It took a little ingenuity, a fair amount of work up front, and the use of our favorite digital collaboration tool, MURAL, but we figured out a framework and process that minimized the pitfalls of being remote, while also optimizing the benefits of digital technology, enabling us to do things that wouldn’t have been possible in a physical environment.
So off we set. And five days later, we were done!
“Hold on just a minute!”, I hear you saying. “You skipped over the Sprint itself! What gives?!”
Well, the fact of the matter is that a Design Sprint is really something you need to experience for yourself in order to truly appreciate its power. No blog post would ever do justice to all the ground you cover in the course of those five days — the ‘ah-ha’ moments you invariably have, the disagreement and discussion amongst the team, the feeling of hitting the wall, the feeling of then breaking through said wall, the excitement of watching your prototype — something you built with your own hands! — being put in front of a user and seeing them respond to it. It’s pretty amazing! But with that said, I’ll do my best to capture the highlights…
- Practice makes perfect: The Sprint went remarkably well. That’s not to say that things went perfectly of course. There was bound to be some issues that cropped up as a result of it being our first time through the process as well as due to the remote/digital nature of it. But as we debriefed after a long couple of days, we were amazed at how much we had accomplished, and frankly, at how much fun we had during the process — it’s pretty exhilarating being able to step back at the end of your week and know that you accomplished something truly meaningful.
- Remote work works: Conducting the Sprint remotely actually wasn’t that bad. You do lose a little in the way of the energy and focus that comes with having everyone in the same room, but with the right mix of technology, you can more than make up for that. We used Google Hangouts, Google Slides, MURAL and Spotify (gotta have our jams!) throughout the week, and also spent plenty of time jotting down ideas on good old fashioned pen and paper. As long as the team can dedicate themselves to the Sprint, meaning closing email, turning off notifications, silencing their phone, etc, it can be done!
- “The best requirements we’ve ever gotten”: ← That was an actual quote from the developer we had invited to join our Sprint team. At the conclusion of our week, we had validated some of our ideas around what would work well with a live chat experience, had invalidated others, and had stumbled across new ones that we never would have considered otherwise. We had built a fully functional live chat prototype, and, using the information we had compiled along the way, had basically developed a business case and in-depth requirements document, not to mention gaining buy-in from the various stakeholders, designers and developers that had been a part of the process. We’d also tested the prototype with some real users and so knew what changes should be made as we moved forward with building out a real, functional product. Not bad for a few days worth of work!
- Time well spent: The value of dedicated, focused work cannot be understated — in fact I’ve found myself incorporating some elements of the Sprint methodology into my day to day process, just to ensure I don’t fall back into the same bad habits of filling my time with unfocused ‘busy work’. It may seem like a big ask carving out five days to focus on one thing, but it’s amazing what you can accomplish when you give yourself the space to really think. Of course, it’s not possible to carve out that much time for each and every thing you have on your plate, nor should it be necessary — a Sprint is best reserved for those big, important ideas that have a lot of upside if you get them right (and a lot of downside if you don’t).
The book is an excellent place to start if you’re interested in learning more, but you really should think about doing one for yourself.
