As our product team, consisting of software engineers, UX designer, and PM, stepped inside the war room to start our first Sprint day, I can see that some of us were nervous at the challenge at hand. We have a tight timeline to deliver a product that solves an important problem for our business. Not only is there more technical and design complexity than originally expected, but more importantly, we are not sure how our users will react to the new experience. Ambiguous, high stakes, and not enough time. It was a great opportunity to run a Sprint.
Many of us may be familiar with sprints in an agile and scrum context, but the technique that I am referring to is Google Venture’s (GV) Sprint. In GV’s own words, “The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed at GV, it’s a “greatest hits’’ of business strategy, innovation, behavior science, design thinking, and more — packaged into a battle-tested process that any team can use.” In my mind, this translates to an ideation and validation technique that is done at lightning speed, which reminds me of past hackathon days. I love the spirit behind moving fast while being creative to solve tough problems.
After running this recent Sprint, I thought it would be helpful to share my experience and learnings to convince you of the usefulness of this technique so that you may add this to your product toolbelt and solve one of your big problems.
Before running the sprint, it is important to plan out who you want to recruit to the team, when you are running the sprint, and where it will take place. Now, I have a tendency to overplan to avoid unwanted surprises. But when approaching sprints, I would advise against spending too much time planning because over preparation can have diminishing returns especially since the nature of problem solving is fluid and unexpected turns can happen.
Here are the logistics that you need to plan out in order to run a successful sprint:
- The Team — These are the people that you want to be in the room with to solve the challenge. The team that will be working closely for the next 5 days coming up with creative solutions and thinking through trade-offs. As a PM, it is obvious that you want to include engineers and designers, but after my latest Sprint, I would also recommend bringing in other cross-functional experts (Operations, Account Management, Support, etc.) for their unique perspectives of how your ideas will affect users or impact existing business processes.
- The Time — Find 5 days on the calendar where everybody can attend the sprint and make it their primary focus. There will always be other meetings to attend or work to do, but it is important to align as a group that the Sprint is the most important work that week. Meaningful work requires uninterrupted blocks of time without context switching, so I started our Sprint days at 930AM with 2 hour blocks spread throughout the day to give the team time to break or check on other work.
- The Place — This is where your team will huddle up for the sprint. Find a decent size area where everybody can sit comfortably and have the privacy to brainstorm out loud without interruption. I had help finding a conference room that gave us the space to brainstorm effectively and this location played a meaningful part in making the sprint successful.
Once you have figured out these 3 pieces, you have a solid foundation to run an effective Sprint.
As mentioned earlier, the Sprint is a 5 day process and the GV design team who founded the technique provided a high-level structure for what to do each day.
GV team’s Sprint Framework
They have also mentioned that this structure is flexible and I found success tailoring the 5 days to fit my challenge’s unique situation and my work style. There are a few differences between GV’s proposed Sprint structure and mine.
- First, instead of doing the user testing and validation on Friday, I preferred gathering user feedback daily in order to validate assumptions and to pivot in design approach more quickly. I had the help of great cross-functional partners to schedule user interviews at the end of each day and this allowed our Sprint team to validate assumptions and test ideas in even shorter cycles, allowing us to save precious time by not over investing in suboptimal ideas.
- Second, I was able to break up the challenge into smaller pieces. So, instead of doing a 5 day sprint to solve the core challenge, I essentially ran mini-Sprints each day and used part of Friday to do a review of the end-to-end core challenge. There were definitely instances when solutioning for one part of the challenge requires thinking through the other parts, but piecemealing allowed us to build momentum toward coming up with solutions even if it means occasional revisits afterwards.
- Lastly, due to the amount of time our team had, we did not build an interactive prototype, but we did have high fidelity mockups that allowed us to do user testing and gather feedback. You can use your judgment here for how high of a fidelity your prototype needs to be.
Taking these differences, this is what my Sprint looked like compared to GV’s.
Modified Sprint Framework
The point here is that the structure of your Sprint is less important than how you execute. At its core, the Sprint is a compacted solution discovery technique, so you can take your own experiences and tailor the Sprint based on your team dynamics and the challenge.
Now, the book did a great job laying out a high-level framework for how to run a Sprint, but I also took away learnings as a PM that may help you make your Sprint more successful.
Stay Grounded in the Why
- As PMs, we own the problem and the solution. So, it is important that as your team is navigating through the Sprint that you serve as an anchor to the core problem. When you notice discussions are heading toward tangents, help your team structure the discussion by reminding everybody the why or reframing the problem statement in different ways (try eigenquestions). Doing this skillfully can spark new ideas, maintain the scope of your product, and avoid building vanity features that do not drive the desired business outcome.
- Taking this one step further, share the short and long term goals of this product with your team. Elaborating on the short term success metrics that you are trying to drive while painting the longer term vision can ground your team in the tactical needs and higher-level product strategy.
Work Backwards from the User
- We started the Sprint by developing a mental model of our users. Our UX designer had a great idea of starting us off with an overview of the user journey and pain points uncovered from previous research. Doing this exercise allowed us to have similar starting points in terms of how we understand the psychology of our users and this is critical for brainstorming ideas later on.
- As the PM, it is also important to build a safe space for your team members and encourage everybody to share their ideas. Sharing ideas in a group setting may not be comfortable for everybody, so open up opportunities for everybody to pitch in. The end product and your users will benefit greatly by doing so.
There is also advice in approaching product design tradeoffs that I wanted to share, but that content is worth another post in itself.
At the end of the 5 day Sprint, our team came up with the final design for the new user experience as well as the technical implementation plan. Of course, we still had details to iron out and plenty of development, testing , and go to market work, but we came out with a solid game plan with far less ambiguity.
Fellow PMs who have led Sprints, feel free to comment and share your experiences. If you are interested in trying a Sprint and learning more, check out the GV team’s Sprint book here. See you next time and go build something that matters!
P.S. If you have not yet tried DALL-E, do not miss out. The digital images created by this tech is mindblowing. You can find some of DALL-E’s images here in this post.