At the NY Product Conference last fall, Daniel Burka from Google Ventures (GV) gave a talk about design sprints (made popular by the book Sprint, written by his GV colleagues). During the Q&A, someone asked, “How often should we run design sprints?”
His response: “Probably about once per quarter.”
Yikes. In our business, we need to run them much more frequently. In fact, we need design sprints to be the foundation of our entire design process.
Related: Go inside design at GV
As a long-time follower of the GV Design blog and a vocal advocate of rapid prototyping for the past 10 years, I was delighted when Sprint was published. It felt like prototyping had finally become mainstream.
The foundational concepts outlined in the book are all techniques I strongly believe in:
- Use strategy to ensure focus on the right problems
(“Start At The End”) - Use prototyping as the key ingredient to learning quickly and efficiently (“Prototype Mindset”)
- Test hypotheses with a small number of real users in realistic situations to gain outsized learning (“Small Data”)
The concepts are well-articulated and packaged together in a way that makes the process easy to understand. This “turnkey” nature of Sprint is what makes it so compelling. But, as anyone who has participated in a sprint as described in the book knows, they are intense.
This should be no surprise—there’s even a full chapter in the book dedicated to this warning (“Time and Space”). For my design team, the philosophies and principles from the book were spot on, but the execution didn’t fit our model. We needed to create a sustainable design sprint system that would work for our business.
At Fahrenheit 212, my team and I work with clients to define new products, services, and experiences that will drive their future growth. We need a process that allows us to make quick yet strategic progress as we test and learn our way from early stage concepts to initial product launches. So, we set out over the past year to take the best philosophies and principles from Sprint and apply them to our business.
While we have adapted Sprint to work for our client service business, we think many of these principles also apply to those working in their own corporations. Here are 4 key adaptations that you can consider to guide your own design sprint system.
Adaptation 1: Run 10-day versus 5-day sprints—to ensure sustainability
We do this for 3 reasons:
- You can run sprints consistently and keep your teams energized for the long term
- If you intertwine commercial and financial analysis into your sprints as we do, you have the space to determine how various product experiences and features might affect the business model and operations of the business if the product were to succeed at scale
- You have the time to bring along a broader stakeholder community outside of the immediate project team as you move through your design process
The structure of our sprints is consistent with the book, but the additional time provides more opportunities for collaboration, resulting in helpful “inside-out” feedback from stakeholders and subject matters experts. It also leads to greater alignment throughout the organization to support the effort.
“Focus on consistency to help everyone get into a repeatable rhythm.”
Adaptation 2: Execute the same cadence, but different activities—to create muscle memory
We currently run 3 different variations of sprints that align to different points in our design process: value proposition sprints, concept design sprints, and product design sprints.
Each variation includes a heavy amount of commercial analysis and financial modeling weaved throughout. While our goals, learning objectives, and prototyping techniques vary depending on the type of sprint we’re in, we’ve standardized the structure and cadence.
Focus on consistency. Ensure all sprints are the same duration, follow the same activity patterns, and are hosted in the same location (for us, it’s our offices), and are hypothesis-driven to deliver maximum learning. This helps everyone get into a repeatable rhythm, despite working towards a wide variety of project goals depending on where you are in the design process.
Adaptation 3: Establish clear roles and responsibilities—to prevent work about work
“The Decider” is a key role described in Sprint. We’ve taken this a step further by clearly articulating in writing who is ultimately responsible for all key aspects of the sprint—product decisions, design decisions, commercial analysis, and overall project management. We’ve found this is critical to being able to move quickly and with confidence.
“To deliver maximum learning, make your design sprints hypothesis-driven.”
It sounds really simple, but the act of writing it down and communicating it to the team significantly reduces each team member’s cognitive load, freeing up headspace for everyone to remain focused on their primary responsibilities. We use the “RASCI” framework, others use “DRI.” Creating clarity is really all that matters.
Related: Design sprint communication
Adaptation 4: Use consistent tools—to create leverage
We assemble bespoke teams for each project, which means the same people don’t always work together. This is often helpful to bring fresh perspectives to problem solving, but it can also present some challenges with teams needing to quickly learn each other’s working styles.
To help minimize any unnecessary churn, encourage consistent use of preferred technology tools and supplies to drive your sprints. While we have a degree of flexibility in empowering each project team to select the right tools to meet their needs, standardizing where possible helps newly formed teams quickly assimilate and focus on the task at hand.
Lessons learned
As with anything, practice makes perfect. We have many lessons that have shaped our current approach that may be helpful to others working in corporate settings or solving for a diverse set of users. Here are a few:
Set expectations about prototype fidelity
The main work product within each sprint is the prototype. The primary purpose of the prototype is as the stimulus to test hypotheses with users, derive insights, and ultimately make decisions about where to go next.
“Clearly articulate in writing who is responsible for all key aspects of the sprint.”
However, in many cases the prototype also serves as a critical stakeholder communication tool to indicate progress and where the team is heading. This can create a delicate tension because the level of polish needed for each of these needs is often quite different.
Set expectations early with stakeholders and educate them about the level of fidelity that will be produced in each prototype. This is essential to keeping the project on track and keeping stakeholders happy.
Find a way to capture non-verbal feedback
Every sprint culminates in testing with real potential users. Running these tests in person is ideal, but it isn’t always possible. In many cases, the target users are not average consumers that can be easily recruited from Craigslist and are often in other geographic locations (a few of our recent test subjects have included mental health physicians, small business bankers, and altruistic organ donors).
When testing in person isn’t practical, insist on video conferencing paired with screen sharing. While it isn’t as powerful as being in the same room, it still allows the ability pick up on the more subtle cues and body language that users offer. This additional context—above and beyond their verbal feedback and the actions they take within the prototype—leads to a much deeper understanding of their experience.
Get ahead of any constraints
Depending on your industry or type of product you’re designing, there may be constraints that need to be considered as you plan your prototype and user testing. For example, including visual design and branding in your prototype is often helpful to create a realistic experience (“the facade”), but may make corporate marketing teams uneasy.
Also, when working in regulated environments such as financial services, insurance, or healthcare, it’s important to understand any regulatory and compliance constraints that may exist to before planning your prototype and testing scenario.
Addressing these types of issues up front and aligning with the right stakeholders on what is and isn’t acceptable helps make every sprint go much smoother.
Structuring the product design process around our adaptation of Sprint has been a huge improvement for us. We’ve been able to maximize our focus on doing and minimize time spent talking about what we should do next.
The bottom line: the design sprint approach outlined in Sprint may not be exactly right for every business. But with a few modifications, you can make it your own.
More posts about design sprints
Carson has 15+ years of experience leading multidisciplinary technology teams focused on product strategy, product design, prototyping, and software development. He is passionate about the craft of digital product development, and has been a long time champion of rapid prototyping as a means to dramatically reduce risk and increase the odds of product success. As Head of Digital and Associate Partner at innovation strategy and design firm Fahrenheit 212, Carson is responsible for leading all digital product design and development initiatives from early-stage strategy to full implementation.
