GitPrime elevates engineering leadership with objective data. In this interview series, engineering leaders talk about building healthy and high-performing teams.

 

One of the problems with traditional product development and testing is the pure investment in time. It can take weeks, months, and sometimes even years to get an idea to a place where it’s ready for meaningful user feedback.

But Douglas Ferguson, President at Voltage Control, helps companies get from idea to solution in only five days. By facilitating one-week hyper-focused Design Sprints, Ferguson helps both new and established companies unleash new ideas and test them quickly — essentially compressing the time and debate it otherwise takes to answer critical business questions.

Ferguson has been an entrepreneur and human-centered technologist for more than 20 years. In addition to helming Voltage Control, he’s also a partner at Capital Factory, a mentor at Techstars, a founding venture partner at NextGen Angels, an advisor at Kinn Home, Bold Metrics, and Abilitie, and a member of the board at Fusebox Festival and Health Code.

He points to Jake Knapp at Google as the inventor of the Design Sprint (Knapp authored the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days). Knapp’s framework for an inclusive design process is quite flexible and adaptable. In Ferguson’s time facilitating Design Sprints and custom innovation workshops with Voltage Control, he’s refined this five-day model in a way that helps teams build and buy into solutions together.

"There’s no reason a company can’t start getting deeply curious about the problem space, making a prototype, and testing it."

“I'm a big fan of this notion of a seventy-percent solution today, versus a hundred-percent solution tomorrow,” Ferguson says. “In this complex adaptive world that we find ourselves in, we have need for emergent solutions.”

Oftentimes, it’s late-stage companies seeking to try out Design Sprints. But Ferguson tells early-stage organizations that the same ideas are applicable to them, perhaps with a looser level of structure, because the teams are still so small and often so tight-knit.

“There’s no reason a company can’t start getting deeply curious about the problem space, making a prototype, and testing it,” he says. “Creating a high-fidelity prototype that demonstrates what you do, and then talking to people about it to understand how they receive it and how they hold it and how it makes them feel, can inform your solution more profoundly than anything.”

In this interview, Ferguson breaks down the essentials of implementing a Design Sprint for the purpose of getting a product ready for launch or improvement: what happens on each day of a five-day sprint, who needs to be on the team, and what success means in the context of this framework.

 

The day-by-day for bootstrapping a Design Sprint

Ferguson finds that a one-week, five-day structure works well for designing an intensive sprint. We’re used to working in weeks, so it’s generally simpler to conceptualize a five-day immersion into a Design Sprint.

DAY 0: PLANNING AND KICK-OFF

Naturally, the groundwork for the five-day sprint begins ahead of time. Teams need to organize logistics: a workspace, needed supplies, a chance to clear calendars. Sprint members also benefit from the chance to get their heads prepared for the work to come.

“We typically recommend having a kick-off so we can set expectations,” Ferguson explains. “Encourage people to read some articles and get themselves oriented, so that when they walk in the door they're bringing the right perspective and you can get to work right away. We’re going to be heads-down in this thing, so we want to make sure that we’re set up for success.”

DAY 1: UNPACKING THE PROBLEM SPACE

The first day of the sprint—let’s call it Monday—is all about delving into the problem at hand. “On Day One we’re getting in alignment,” Ferguson says. “We’ll do some mapping exercises. We're going to interview some people who have some perspective that we really should hear, users or experts about the problem space. And we use all that information to draw some sort of map.”

The map can take on pretty much any form, but typically, he explains, it is some form of user-journey map that is targeted at the specific subsets of the problem space that the team wants to address, without worrying about every step along the way.

By the end of Day One, the team is then able to focus on what they are going to spend their time on for the rest of the week.

“There might be lots of moving parts to this problem space, but we narrow our energy down to one critical little thing that we want to focus on,” Ferguson says. “That's what we really zero in on Day One.”

DAY 2: DIVERGING FOR INDIVIDUAL SKETCHING

Tuesday and Wednesday are designed to generate as many ideas as possible, and then to whittle them down to the one or few ideas that will go into the design prototype. These days allow people to diverge and work on individual explorations, and then converge as a group on solutions and decisions.

Tuesday is largely about the diverging half of the equation, where everyone individually sketches, after a bit of group collaboration. “We'll do some work together where we share analogous inspirations and things that we see out in the wild that we think might inspire us, whether it be competitors or something completely different or adjacent,” Ferguson explains.

“And then the rest of the day is spent on sketching activities that are all done individually. Everyone can think through their ideas, formulate them, and get them down in a way that the others can really grok what they're trying to share or what their vision is.”

DAY 3: CONVERGING ON A DIRECTION

Then on Wednesday, the team converges for integrated decision-making. Essentially, the sprint team members each share their sketches, and together, the team decides on the winning sketch(es) and then begin to fill in any missing gaps—like, as Ferguson says, adding meat to the skeleton bones of the sketch.

This two-day diverging/converging process tends to yield more accurate and beneficial results than either individual brainstorming or group collaboration alone.

DAY 4: THE ONE-DAY PROTOTYPE

On Thursday, the team builds a prototype.

“We make it as believable and as high-fidelity as possible using whatever tools we can,” Ferguson says. “We want to move really quickly and not get mired in any kind of functional or feasibility issues. We just get to simulate it as cheaply as possible.”

DAY 5: TESTING THE PROTOTYPE WITH USERS

Then on the final day, the team tests that prototype with five users. Five is no accidental or arbitrary number—five users, Ferguson has found, are enough to reveal any big patterns.

“Say you have a hundred people at a party and, as they're starting to leave, five people trip over the stairs,” he explains. “You don't have to run the entire party over these broken stairs to prove that there's some problem you need to look into.”

One of his keys to user testing is to look for trends. If one of the five users mentions something that no one else does, a team might decide to look into it more deeply if they have reason to believe it might be generalizable. But if all five users relate an experience consistently, then there’s something worth exploring there.

“After a Design Sprint, we’ll often coach teams on shepherding their product through to the following stages,” Ferguson says. “We'll often recommend that they make tweaks to their prototype and test it again. So at the end of the day, you end up talking to more than five people, but you do it in these five-person cycles until you have high confidence.”

 

The full cast of characters for a Design Sprint

Planning who to include in the Design Sprint happens in the Day Zero stage. “When we plan, we need to think about who needs to be in the room,” Ferguson says. “That should be informed by requisite diversity. We should ask ourselves, ‘Who do we need to include to make sure we're thinking about everything, and all of our assumptions get exposed?’”

"We should ask ourselves, 'who do we need to include to make sure we're thinking about everything, and all of our assumptions get exposed?'"

The cast of characters attending a Design Sprint will obviously vary depending on what’s being designed, yet Ferguson offers some foundational guidelines for who to include.

• Someone who understand the logistics. “If it’s a software company, you’re probably talking about an engineer, or maybe someone in Operations,” Ferguson says. “If you’re a consumer package goods company, it could be someone in Manufacturing. You want the voice of logic and the constraints of physics.”
• A designer. “Often, we’ll have multiple, depending on their skill sets and their perspectives,” he says. “You might have someone who's more of a researcher to do the interviews on Friday, or more of a visual designer to do the prototype on Thursday, or someone who’s a creative blend of those. Ultimately, you want some person or group of people coming from the perspective of design and creativity.”
• A customer representative (the voice of the customer). “You want someone who understands what they’re going through. This might be support, or sales.”
• Someone who understands the messaging. “Typically, this is someone from marketing or communications,” he says.
• The voice of the business. “Especially if you’re going to be pricing this thing, someone needs to understand the business dynamics and the business model pieces,” he says. “You're not going to reach a long-lasting or durable decision unless you've included all the variables. Someone from the Finance group can make sure that you're putting together good pricing models, or someone from the Bus Dev group can make sure that the business context supports what you're building.”

Continuing along those lines, Ferguson advises that a Design Sprint planner will want to go through the various constituents in the organization and determine whether all the helpful stakeholders are represented. “You can't have inclusive decisions unless people are in the room,” he says.

 

Measuring a Design Sprint’s success

Considering the costs of having this group of individuals in a room for five full days, measuring the ROI of a Design Sprint is useful in communicating the results with executives — and when pitching the idea to run another Design Sprint in the future. Capture qualitative feedback on the fifth day of the Design Sprint, and then track business opportunities and financial gains if the project is a success.

Beyond the tangible outputs of a Design Sprint, the process of running the sprint can be a primary reason why organizations facilitate them in the first place. Cultural improvements, a sense of momentum and alignment, and a new backlog of innovative ideas are just a few outcomes of running a successful Design Sprint.

“You get insights into your organization’s alignment from the team itself, and those things tend to permeate the company after the Design Sprint,” he points out. “The alignment creates advocates, so people understand why decisions were made and what trade-offs were considered. The sprint team members go back into the wider organization with a stronger sense of the company’s direction and how their ideas and actions can shape that.”

"The sprint team members go back into the wider organization with a stronger sense of the company’s direction and how their ideas and actions can shape that."

Furthermore, the Design Sprint also leads to powerful user insights. Even if the project winds up with no legs, the sprint likely unearthed other actionable realizations that will allow an organization to pivot in new directions.

Even in the worst-case scenario—the Design Sprint turns into a complete disaster, producing nothing of any worth—the deliverable is that your team reached that conclusion in a single week, rather than several months of more traditional development. That’s a significant savings of time and other resources.

Ultimately, beyond designing a single prototype, the Design Sprint helps an organization understand the desirability or legitimacy of a product in the market. “And I think there are better approaches to reaching that understanding than A/B testing your way to product-market fit,” Ferguson says.

 

Conclusion and further reading

Ferguson’s structure for a five-day Design Sprint is this:

• Before beginning: Prepare and plan for the sprint, including ensuring the requisite organizational diversity on the team.
• Day 1: Get everyone familiar within the problem space, and determine which aspects of the problem will be tackled that week.
• Day 2: Diverge to allow individuals to sketch out approaches to the problem.
• Day 3: Converge as a team, decide on a sketch, and start filling out that solution.
• Day 4: Build a prototype.
• Day 5: Test the prototype with five users, looking for trends across all subjects.

He also recommends as further reading for anyone interested in implementing a Design Sprint Jake Knapp’s Sprint, GV’s Design Sprint resources, and the plethora of content available on his company’s website, voltagecontrol.co.

Whatever resources an organization uses in implementing Design Sprints, Ferguson’s approach ensures a broad range of deliverables, from a completed prototype to perhaps even more valuable results—the user insights gained through the process, a strengthened organizational advocacy for your work, and lessons learned in one week rather than months of design work.