Converting Design Sprints to a Corporate Setting
The Google Ventures Design Sprint format was created for startups. What’s the difference when we do it within a large company?
I was recently honored to be invited on a panel led by John Zeratsky, co-creator of the Google Ventures Design Sprints and Sprint book. Because the Sprint format was created for startups, John led a clever conversation focused specifically on what it means to produce and lead Sprints inside a larger organization.
It was a topic that made my mind swirl long after the event was over. Having led dozens of Sprints in both contexts, I had never explicitly thought about the contrasting differences before. But the truth is that we’ve come to approach corporate Sprints completely differently than startup Sprints.
Inspired by that discussion, here are some of the main ways where we modify Design Sprints for a corporate audience:
1. What are the biggest difference between Startup and Corporate Sprints?
Startup Sprints are about saving time, Corporate Sprints are about creating opportunity while mitigating risk.
One of the most beautiful things about the Design Sprint is that it’s architected to save the design team’s time with preparation, overbuilding, debating, going down the wrong road, and more.
In a corporate context, we need to separate the notion of time saving into two categories: saving time at the individual team level, and saving time at the corporate strategic level. The first refers to what the people doing the sprint are doing from hour to hour, day to day, and week to week. The second refers to the strategic choices and commitments made by the business.
In a startup, these are essentially the same thing: there’s only one or two big things going on at a time, so every day the team/org takes before rolling out a new launch is directly burning money out of their investment funds.
In a larger business, the design team usually has a month or two more to invest in order to make sure the larger business is truly making the right decision.
Practically, this means a few things for the Corporate Sprint:
A: Plan for a lot more iterations.
The Design Sprint as written ends after the first cycle of testing. We’ve found it usually takes about 3–4 cycles to hit a confident right answer. So when planning out the schedule, don’t end after the first testing round: make sure you have at least 2 more iteration and testing rounds in the books.
Of course, these don’t have to go immediately on the same week / workshop. However, it’s essential to realize that the milestones for your design progress are your iterations.
As a result, plan out testing & iteration cycles accordingly in advance: It’s possible to get them on a daily cadence if moving very quickly, but every few days is fine as well. 1–2 weeks is the slowest cadence possible to keep up momentum.
B: Spend more time exploring truly unique ideas.
Since a larger organization is far more capable of backing up a unique and amazing product or service, cast a wider net with your initial ideas, and go further afield.
Here are some specific process changes I use for this:
- During the Lightning Pitches round (which is also similar to the Stanford d School’s “analogous solutions” tool), go a little broader. Find some things that are wonderful in adjacent spaces without the pressure to immediately connect it to the design at hand. Then, let yourself explore and discover potential inspirations: “What is magical? How do they do it? What might we borrow?”
- Do 2 rounds of ideation. We still have people write ideas separately and share them, but after they are shared we go a second round to enable people to be inspired by what they just heard.
- Test a wider range of ideas. Instead of testing 1 option by default, test at least 2–3, ideally even more.
- In fact, I strongly recommend starting out by testing the ideas that you’re likely to learn the most from, not necessarily the ones you think are most likely to succeed. Pick a smattering of very diverse options that cover a wider field, so that you can converge in a later iteration.
- Ideate from data. Our most exciting ideation round is actually at the top of the second iteration. That’s the moment that we know a bunch of juicy information about the user from the first batch of tests, and can really start focusing ideas around where we know the opportunities lie.
2. If I want to do a Corporate Sprint, what should I do differently to prepare?
A: Plan to get more done in less time.
The truth is that in my career, I have only met 2 corporate teams that could take a full 5 days off to do a Sprint. And one of them already had a workflow that involved 5-day design sessions every month or two.
Instead, we’ve found that 3 days is a lot more doable, because people still have half their week.
In order to squeeze everything into a shorter amount of time, we compress the initial ideation, mapping, and deciding substantially. Because there will be more iterations in the future, it’s less essential to get it perfect the first time.
Additionally, in earlier cycles we test users on Sketches (paper designs) rather than digital mockups so that we can make more changes faster.
Based on the needs and capabilities of your group, you may choose to compress time differently. When making your own plan, the most important thing to keep in mind is to not give up any user testing. It’s the most cumbersome part, but also the most critical.
B: Understand your deliverables
By default, a Sprint generates a prototype and a list of insights. There’s also a list of questions and additional ideas. In some organizations this will be enough, but not all.
In a startup, the people who do a Sprint to come up with the solution are typically the same people who are responsible to execute, launch, and sometimes even maintain the solution. Therefore, as long as those people understand what happened in the Sprint and where to go, it’s fine. Fitting those insights into the subsequent workflow also typically feels like a natural process.
In a corporation this is often not the case— every organization has a uniquely different relationship between the people designing a product/service/feature, and the people who will be implementing it. Communication and documentation processes are also a lot more important.
Therefore, it’s essential to be explicit about the deliverables.
Before your Sprint, make sure it’s clear who needs to understand what happened afterwards, and what format they need that information. Ideally, create a quick “prototype” mockup of an example report that everyone can agree on.
Make sure also all parties understand that one round of Sprinting will not get you the entire validated, risk-mitigated new opportunity. Instead, you will have a prototype, a set of insights that drive how the team will think about the solution, and plenty of next steps for additional iterations and development on the design.
C: Consider bringing in a feasibility expert.
Often, the team doing the design do not have the complete picture of what is actually possible to implement. Although it’s better to cast a wider net with ideas tried to get a sense of of what is most important to users, you also need to stay grounded in what the company can pull off.
If there are questions with respect to subjects like engineering, compliance, or production efficiency, book some time with an expert in the middle of the Sprint during the idea selection process. Don’t let them shoot down options just because they’re different (you still want the data from testing the impossible), but often they can identify cases where something similar might be 10x more doable.
3. What about doing Design Sprints for internal clients / users or partners?
This was probably my favorite question that came up in the panel, and I could talk about it for half an hour.
Doing a Sprint for internal clients can feel dauntingly different, but it’s actually for the most part easier as long as you keep a number of things in mind:
A: Add a “User Wrangler” role.
The easiest thing about internal clients is that they’re a captive audience who, unlike consumers, are fully incentivized for you to succeed!
The hardest thing is that this connection comes with a lot more relationship management. Take the best diplomat on your team and give them the job of communicating with users, setting their expectations, and handling their relationship with the Sprint.
It’s essential that they understand that what’s being shown them is in the early exploratory idea stage and not a real proposal for what they will be working with.
Additionally, explain that it’s all right for them to experience a fundamental mismatch with it. Or even just a sense of mediocre indifference! It’s very difficult to say, “meh” to your colleagues, so make sure they are comfortable being unimpressed with the design.
Most importantly, make them feel valued for their insight, and like they are truly having a meaningful impact on the outcome. Social capital is built not only by doing things for others, but also by having them do things for you that are enjoyable and important.
B: Leverage their time by creating more prototypes & variations
Quite often your internal clients will be very busy and their time with you will be more limited than if you were working with consumers. Sometimes, you may even have to break up testing day to work on their schedule. (Looking at you, Healthcare.)
To get the most out of limited user test time, bring more variations of the design. That way, if something isn’t working for them, you can immediately change it out for the next hypothesis, and the next. Even if something is working for them, you can tease out a high density of information about how and why by immediately contrasting it to a very different option.
Important, this means not only bringing several different designs, but also bringing a range of variations of different parts of the same design.
In other words, leverage the additional time your team has available to anticipate the most likely dozen prototype changes, and prep those in advance. Do this by using Sketches rather than digital mockups, options loaded onto more devices, or a setup that lets you push out prebuilt updates in less than a minute.
C: Bring more stakeholders into the room at the same time
This is one of my favorite maneuvers that can only be pulled off by testing on Sketches rather than digital mockups:
If you are working on an internal solution that touches several different types of people with complex interdependencies, you can do a Lightning Iteration test on all of them at once:
Build the solution for each party assuming everything else is working, and have different team members show it to each. Then quickly, during the test itself, find out what changes would be needed to make it functional for each person. Immediately propagate those changes to the designs of all the other parties, and get their respective reactions. Continue iterating back and forth together until you land on the solution that actually works for everyone at the same time. (This usually takes about 4–8 changes.) If you get stuck, just ask the group how they would each want it handled.
It helps to have snacks in the room so they can wait in 5 min breaks as you rapidly update the designs.
4. Other Miscellaneous Q&A Topics
Q: How do I protect our brand while we’re trying out something early?
If this really matters, go offsite and use a fake brand. For example, say, “Pretend you see this product from a fitness company called Fakename, which is similar to Competitor A and Competitor B”.
Q: How do I get buy-in from reluctant adopters?
There is no magic bullet for this, alas. The closest I’ve found is to get them exposed to genuine reactions from users. Often, incumbents are caught up in the same way of thinking about the challenge and lose track of the actual impact: rebuild that connection. If possible, bring in a live user that they can watch experience the current version. If not, record video of users authentically sharing their experiences.
Q: You keep talking about testing with Sketches, how does that work? Doesn’t the Sprint book recommend against this?
Check out the example video here. We’ve found that questions about features and broad approach test fantastically with Sketches as long as you put extra effort into immersing the user and listening to the nuance in their response. Additionally, our own experience has been that the specific issue mentioned in Sprint about users focusing on fussy UX feedback in low-fidelity designs is less culturally pervasive outside of Silicon Valley.
— —
