What We Learned Running Our Own Google Ventures Sprint

I work as an engineer with Lucidpress. The Lucidpress team, as part of the larger Lucid Software family, is known internally as a startup within a startup, and all the ideas, excitement and passion you'd expect from a startup are found here in abundance. Related: How to lock in your team's productivity There are so many ideas, in fact, that it's often difficult to pick which ones to build next. And as is the case with decisions in any startup, one wrong step can have big long-term consequences. This past week, we came to one of these crossroads. Just to give some background, Lucidpress is an easy-to-use layout & design tool that allows users to create marketing content such as magazines, brochures, flyers and social graphics that can be printed or shared digitally. A few members of the Lucidpress team, including Andy Hurd (left) and Vicky Thomas (middle) who participated in the sprint. We love Thayne McCombs (right) as well. But over the past couple of months, Lucidpress has gained traction in what for us was an unexpected field: brand management. Large companies wanted to a way to ensure that their content stayed on-brand. This could mean lots of things, but we didn't have the time or resources to explore every option. That's when we came across the Google Ventures Design Sprint. The Google Ventures Design Sprint is a battle-tested method to define a problem, compare and contrast competing ideas, prototype one of them, and get customer feedback—all in one week. It's an intensive process, but it has the potential for big rewards. We've been inspired by this method after reading the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days authored by Jake Knapp, John Zeratsky and Braden Kowitz from Google Ventures. Our bible during the sprint. We decided to give it a try. At the conclusion, we asked our team to give their thoughts and feedback on the experience. In this post, we'll share what we learned. Day 1: Unpack & define the problem Day 1 was all about defining the problem. We knew generally that we wanted to solve problems for our users around brand management, but we needed to get more specific. We started with a list of questions—hundreds of them. From the questions, we were able to map out how customers with a brand management problem might move through the product. With a clear map, we were able to see several areas that needed to be improved upon and some things that needed to be created from scratch in order for users to find success. Our team, minus our fearless Decider Dave, who was off making other important decisions. To make sure we were aiming for the right target, we brought in four people who were close to the problem but unable to participate in the sprint (a salesperson for Lucidpress, the CTO of Lucid Software, and customers) then gave them an opportunity to critique our map and ask questions. By the end of the day, we were ready to narrow the focus of the sprint. We all picked what we thought were the most important questions and determined what our focus would be based on those results. Questions from Day 1 So everyone is here for our first Google Ventures Design Sprint. How do we get started? "As with all group workshops, it is key to have a facilitator chosen. This person doesn't need to be a professional facilitator; the Google Ventures Design Sprint has enough structure and wise ideas that most anyone can pick up what is needed and move the group along. But it is critical that a facilitator has read the book and can begin each day by laying out a clear agenda for what the group will focus on. High energy helps, too." —Luke Langford, the Facilitator How do we keep a narrow focus? "Sprints are designed to answer hard, traditionally high-cost questions in a very low-cost way. Sprint suggests listing out your hardest, highest-risk questions about your proposed project on Monday morning. This was super helpful, because when it came time to pick the focus for our sprint's experiment, we were able to draw from the top-priority questions on that list which we had agreed on as a group." —Vicky Thomas, the Planner Day 2: Sketching & idea exploration Day 2 was a day of inspiration. In the morning, we started off with lightning demos. Lightning demos are simply 2-minute demos of products that people love. These could be apps, arm chairs or even video games. We explored a few of our team's favorite products and looked to "remix and improve" on the ideas of others. In the afternoon, everyone got out their pens and took 90 minutes to sketch out their ideas. By the end of the day, we had eight possible solutions hanging on the wall. Questions from Day 2 A major part of Day 2 is lightning demos. How were you inspired by what you found? "The GV 1-week sprint increased our team's traditional cadence of software production—building our team's confidence in low-investment R&D and allowing a quick, pragmatic, reflective process to drive innovative possibilities." —Matt Snyder, Design Expert I'm not a designer. Do I really have to sketch? "I'm an engineer and have absolutely terrible handwriting. I couldn't draw a straight line if I tried. Sketching was really scary for me at first, sitting there staring at a blank sheet of paper. But it turned out that I found it much easier to express by drawing rather than trying to explain what was in my head." —Jared Yarn, Tech Expert Day 3: Decision For us, Day 3 was far and away the hardest day of the sprint. In the morning, we started with an art gallery of all of our sketches from the day before. Everyone was given small dot stickers to mark the ideas they liked and thought should be included in our final prototype. Everyone loves Vicky, as you can see from the two stickers she was awarded. Dave, our Decider, received several large dot stickers to vote with. After an hour of examining and explaining each of the sketches, all of them had at least some votes, and we had to figure out how to narrow it down to one prototype. We eliminated any that the Decider hadn't selected but were still left with five sketches, all good ideas. Over the course of the afternoon, we debated and eventually narrowed it down to one sketch. With that, we began storyboarding the way a user would interact with our idea. By the end of the day, we had a storyboard of 18 scenes we wanted to prototype and walk users through. Questions from Day 3 How did you guide the discussion so that you arrived at a decision? "With so many ideas and sketches, it would have been extremely time-consuming to talk through the merits of each in great detail. To narrow the options, I primarily relied on my gut to determine which ideas were most important or would resonate with our users. Fortunately, that 'gut' has become relatively well-informed over time through literally thousands of customer interactions, including still reading every support ticket today! "Once we narrowed it to two key sketches, a much fuller discussion emerged. What was interesting to watch was how the specific design or implementation details transformed quite a bit over the next couple hours, though we held to the design principles which I had decided on previously." —Dave Grow, the Decider Day 4: Prototyping On Day 4, the rubber hit the road. It was time for us to build a prototype of everything we had discussed and decided on in the first three days. We started the day off by reviewing the storyboard we created the day before to make sure everyone was on the same page about what we wanted to prototype for each scene. Once we were aligned, we got to work. Initially, we considered building a simple prototype in Keynote or PowerPoint. But luckily prototypes are already a core part of our workflow at Lucid Software, so we already had a nice library of components and tools, like Codepen.io, as well as several internal prototyping experts. The majority of the day was spent building the individual components of the prototype and stitching them together. Meanwhile, our interviewer was busy preparing for Friday's customer test by writing an interview script and reminding customers. We ended the day by doing a trial run of the prototype to make sure everything was in order. Overall, the prototyping took longer than expected, but we were able to end the day pleased (and impressed) with what we had built in only a few hours. Questions from Day 4 Our team doesn't have any prototyping experts. How can we build a prototype in one day? "The UX team created a prototype of Lucidpress for testing with our users. It was built using our own prototyping component library and Codepen. This allowed us to quickly build an interactive experience with the new features we wanted to test. "We used a mixture of images and live components, only coding what was necessary to make our prototype feel real for our user tests. For example, we made a clickable right panel to show different states, but we filled those states with static images. This level of realism allowed our users to treat the prototype like it was the real product. They clicked around and explored the interface through scenario-based suggestions instead of task-based actions. This type of prototyping increases the quality of feedback we receive. This is critical for uncovering problems in our thinking and assumptions we made earlier in the week." —Cory McArthur, Design/Prototyping Expert Luke, our Facilitator, leading a discussion. Day 5: User testing Day 5 was the day we were all waiting for. Finally, we were able to sit down and test everything we had planned and built over the week. Earlier in the week, our Facilitator and our Planner put together a list of customers we could talk to and set up interviews with them. Our Planner was the contact and interviewer. She introduced them to the prototype and guided them through the experience. In the other room, the remaining seven of us listened in, taking notes and watching closely. At the end of the day, it was clear that some of our ideas really worked and users loved them. Other ideas were not important to users, and some ideas were just straight-up confusing or useless. Without spending any time on development, we were able to get amazing feedback on the feature we planned to build. Just before wrapping up the day, we recapped and made assignments to apply the lessons we learned and get the feature built. Questions from Day 5 Do you really need everyone listening in on the interviews? It seems like just a couple listeners would be plenty. "I found it was really important to have everyone participate. It was helpful to see how each team member interpreted some of the different responses. There were some learnings that we only understood because one person was there to point it out. For the most part, everyone left on the same page, knowing exactly what we should do next. There was little disagreement because we had all learned together." —Andy Hurd, Tech Expert With only five users, how could you be confident in the findings? Is five people significant? "Our team did a great job recruiting the right users for the test who accurately represented the target customer we decided to focus on at the beginning of the week. Testing with the right users helped us to be confident in our findings and trust the feedback we received. "We actually ended up being able to talk to only four customers, but we still saw patterns emerge because we had found the right people." —Garrett Jestice, Marketing Expert Final thoughts & questions Was the sprint a success? "It was absolutely a success. In the span of just five days, we took a number of rough product ideas we'd had and worked them into prototypes that our customers validated. Some ideas got great reception, and we'll start developing them immediately. Others—including one idea that we probably would have started to develop—received only lukewarm reception and so will be put into our backlog to be refined further. The whole point of the sprint is to learn. And we learned. A lot." —Luke Langford, the Facilitator What would you do differently next time? "The biggest thing I would do differently is alter the sketch day. I wish we would have been able to share our sketches with each other instead of individually sketching for 90 minutes. It would've been nice to break that time up into a few shorter sketching blocks where we could share our ideas and then riff off each other's sketches. As ideas helped inspire others, this could have resulted in a more efficient Wednesday as we merged ideas and filled in gaps." —Rob Witt, Design Expert Other tips from the team "You need at least three whiteboards. We used four for most of the week, and it still felt cramped!" "If the Decider has a clear product vision on Wednesday, he should be more active in pushing consolidation of ideas. If there are gaps, then the Facilitator should work to help the Decider gather info from the team to help move ahead efficiently." For those of you looking to run your own sprint, we highly recommend the book that inspired our process. Included with Sprint is a shopping list of items that you'll need for the perfect sprint. We used this list to prepare, so we thought we'd pass it on to you. Check out the list here.