Why you should try an Enterprise Design Sprint

Does any of this sound like you?

You’re a changemaker working on a complex problem either as an entrepreneur or intrapreneur. You have some resources for making change but will need to work with partners, policymakers, or others to scale your impact.
You’re a product manager, business analyst, designer, architect, or systems engineer in a large organization.
You’re working on a difficult problem which will need to be solved in phases over months or years.
You’re managing a portfolio of work that spans multiple time phases or teams.

Are you running into any of these problems?

The product design cycle is taking too long.
You’re delivering value but not getting the response from customers and stakeholders that you were hoping for.
You have presentations, white papers, or sketches about what could be done. Some of it may even be validated with customers. But you don’t have a plan for implementing the concepts. Or you run into issues when trying to implement them.
You’re working on problems involving multiple stakeholders, business lines, and solution partners that aren’t on the same page.
You don’t have one single, completely informed decision maker who can make the final call.
You’re having difficulties reconciling modern experiences with legacy systems and business processes.
You have “wicked problems” to tackle but your organization is ignoring them in favor of low-hanging fruit. And you’re starting to run out of low-hanging fruit.
You’re having difficulty helping other people focus on anything beyond the latest fire.

If any of that resonated with you, I have good news for you. An Enterprise Design Sprint might be exactly what you’re looking for. But first, let’s talk about what Design Sprints are (in case you haven’t heard of them yet).

What’s a Design Sprint?

People have been running forms of design sprints for years, but two books were recently released that provide guidance for design sprint facilitators. “Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days” by Google Ventures and “Design Sprint: A Practical Guidebook for Building Great Digital Products” by Richard Banfield, C. Todd Lombardo, and Trace Wax.

Both books use slightly different terminology but the general process is similar. The process takes a small team of designers and problem solvers through defining a problem to solve, design activities, the creation of a prototype, and testing the concepts with users. All in one week.

The schedule:

Monday: Unpack/Understand
Tuesday: Sketch/Diverge
Wednesday: Decide/Converge
Thursday: Prototype
Friday: Test

The advantage of this structure is that you can rapidly explore a potential solution space and validate your ideas before spending too much time and money on implementing something that customers don’t want.

What’s different about an Enterprise Design Sprint?

Design Sprint frameworks are great and might be all you need for your situation. We found that they needed to be tweaked to help us achieve better outcomes in a complex enterprise setting.

We were managing a portfolio for a handful of our own development teams. To enact change at an enterprise scale we needed to integrate with hundreds of other teams. We needed something that would both help our developers move forward and inspire other teams across the enterprise.

The process needed to be accessible to career designers and people with zero design experience alike. It needed to work within an environment like a government agency without being constrained by it. It needed to balance modern user experiences with the reality of existing legacy systems, policies, and processes.

The final solution, Enterprise Design Sprints, borrows from user-centered design, systems engineering, agile, and enterprise architecture.

Why call it an Enterprise Design Sprint? Besides working well in an enterprise, the process also fits with a different definition of the word “enterprise”:

“Full Definition of Enterprise: a project or undertaking that is especially difficult, complicated, or risky”

– Merriam-Webster Dictionary

To help with especially difficult or complicated projects, the overall structure is similar to a standard Design Sprint with some different activities and outputs. The biggest changes were adding success criteria, value frameworks, business model playbooks, roadmaps, and systems engineering techniques.

Why do those matter? Individual feedback from real people is important. However, in complex organizations, you also need methods to sort through multiple views of the problem and solution space to figure out what to do next. The structure of an Enterprise Design Sprint combines qualitative and quantitative techniques to help you determine what to build, for whom, and why.

The outcomes of the sprint are also different. The objective is still the same, to gather user feedback, but the outcomes are focused on three main artifacts: A prototype of the minimum viable product (MVP), a prototype of the vision, and a draft roadmap. This set allows us to leave the sprint with something that could happen in the short term (assuming users like it), and a broader vision to test. The draft roadmap shows a potential path to that vision. That plan can be the inspiration for future design sprints.

The modules are customizable but here’s the typical way to split the modules across one week:

Day 1: As-Is

Sprint goals
User needs
Business needs
Success criteria
As-is customer journey
As-is system

Day 2: High-Level To-Be

To-be ideas
Idea organization
Idea rating
To-be customer journey
To-be system

Day 3: Detailed To-Be

Storyboards
Process models
System diagrams

Day 4: Prototyping

Prototyping
Roadmapping

Day 5: Reviews

User feedback
Stakeholder feedback
Retrospective

An Enterprise Design Sprint is also different from a typical design sprint because it defers the detailed design phase by one day. This is done to provide a two-step to-be design experience. The first day is to think about what could happen at the system level or customer experience perspective. The second day is for detailed storyboarding to inform the prototype.

So why should you try an Enterprise Design Sprint?

Benefits of an Enterprise Design Sprint

1. It will help you guide a team through complex problems

Something about complex problems paralyzes people. Often the most important problems to solve are high value and high effort, but it can be easy to stay focused on only the low-hanging fruit. Which is a fine place to be but eventually you start moving into low-value, low-cost territory. The Enterprise Design Sprint structure provides a systematic way for breaking down and working through complex problems using time-boxed sessions.

2. It will help you create a shared vision

Working on a complex problem is like sitting in a boat with hundreds of people paddling in different directions. The problem is not that there are no resources. It’s that people are doing the best that they can, given the direction they’re trying to go in. It’s just not the same direction.

Creating a shared vision is the easiest way to see dramatic improvements. Enterprise Design Sprints help by giving a shared view of the customer, the stakeholders, the problem, the solution space, the vision, and the path to that vision. Now you have everyone aiming in the same direction.

3. It will help you determine a potential minimum viable solution

We’re not just here to find the answers to problems. We’re here to make an impact quickly. While you probably won’t solve everything in a week, the sprint is designed to help you end the week with an idea of what the minimum viable product or minimum viable experiment could be. That’s the smallest thing you could build that would provide value to stakeholders, or at least, help you learn more about which direction to go in.

4. It will help you ensure that your MVP and the roadmap to the vision are actually implemented

Implementation doesn’t occur during the week but the outputs are digital artifacts that you can share with other teams. That is critical for a few reasons:

They can see what you are trying to accomplish. Remember back to the boat metaphor. If they don’t know where you’re trying to go, they can’t help you.
They understand why you are trying to accomplish it (ex. enterprise goals, customer quotes or stories). That background can help if they are given competing priorities.
They can see your draft roadmap and comment on their ability to support it. The artifacts provide a great starting place to have design and planning conversations, rather than looking at a backlog of items. You could also incorporate your partners into a sprint and co-create with them.

5. It will uncover more opportunities

Following this structure will help you balance user-centered design, business re-engineering, and systems engineering. Sometimes you can’t build a new site, business or product from scratch. And the techniques for re-engineering a system are different from the techniques for creating a new one. Enterprise Design Sprints have enterprise analysis built in. Customer journeys meet business processes and technical architecture to give a broader picture of what is and what could be. Because sometimes there are opportunities that individual users or stakeholders don’t realize could be possible. Sometimes there are existing opportunities available in enterprises that just need to be uncovered and unlocked.

6. It will save time

Between context switching and meetings that keep getting pushed out because someone couldn’t attend, even a relatively small decision could take weeks to work through. The design sprint structure will ultimately save you time because:

It gets everyone in the room together (physically or virtually) with minimal distractions.
It’s a very structured meeting with artifacts created at each step in real time. No need for someone to spend a lot of time creating and sending out meeting minutes after the fact.
Since work expands to fill the time available, you’ll probably find that you’ll be able to create the same amount of value in one week that would normally take you longer.
The time spent in the sprint will save you time later when you’re deciding what to build next. You’ll already have your notes and roadmap available, it’s just a matter of updating them and running another design sprint if necessary.

7. It will save money

Besides saving time, which saves you money, Enterprise Design Sprints save money in these cases:

When money is redundantly spent because each individual team determined their own backlog and roadmap. Hold a joint sprint instead.
Teams may even go as far as to implement something that needs to be refactored. Or almost implement something before realizing that the other teams can’t support it. Use the outputs of the Enterprise Design Sprints to help align your roadmaps ahead of time.
If you’ve ever spent money on a long user research and design project only to find out that the results weren’t feasible to implement, then give Enterprise Design Sprints a shot. The systems component can help you identify any gotchas or alternative paths early on.

[clickToTweet tweet=”‘Move beyond the low-hanging fruit with #EnterpriseDesignSprints'” quote=”‘Move beyond the low-hanging fruit with #EnterpriseDesignSprints'”]

Update: This blog series about Enterprise Design Sprints has been expanded into a guide for facilitators with all of the content, plus 50+ worksheets and some other surprises. Check it out in the store.