How to pick a great Enterprise Design Sprint topic

You read last week’s post about why you should try an Enterprise Design Sprint, and you’re ready to get started. First things first: picking the topic. No pressure, but you’ll want to pick a good one. A successful and engaging sprint can jump-start an initiative, re-energize teams, and set the tone of a project.

We’ll cover four steps:

Step 1) Generating ideas
Finding sources of inspiration for an Enterprise Design Sprint topic.

Step 2) Selecting ideas
Deciding which topic to start with.

Step 3) Testing ideas
Quickly running the topic through the design sprint outline. We want to envision how the sprint could play out to identify any issues ahead of time.

Step 4) Validating ideas
Getting feedback on the topic and buy-in from sprint supporters and participants.

As the facilitator, you can do the first three steps by yourself or try to pull a small team together to run through these steps.

Step 1) Generating ideas

The first step is to generate ideas for sprint topics. Aim for problem or opportunity areas that are important and complex. You could use the Enterprise Design Sprint structure to explore relatively straightforward changes as well, but it’s designed for tackling problems that are otherwise being ignored or pushed aside because of their complexity.

If anyone’s ever said “that’s too complex” or “that’s too much work” in reference to the topic, then you’re probably on the right track.

Some sources of inspiration could be:

A problem you identified
Check out 79 ways to find problems to solve for methods to try.
A recent client request
This could be a formally written or verbal request. You may see them expressed as a solution or a problem. Try to talk to the requestor and draw out the core problem or reasoning behind the request before the sprint. You might learn that the problem they’re trying to solve is in a different part of the process than the solution they proposed.
Issues at the intersection of multiple teams or programs
Unless you’re working on a problem by yourself then you’ll need to work with other teams to deliver epic value. Enterprise Design Sprints are a good tool for those cases because you can explore the landscape quickly in order to identify opportunities, system interfaces, and dependencies.
Issues at the intersection of multiple business offerings and customer segments
Think about the products and services your organization provides and how it provides them. Are there multiple business lines that serve the same customer? Does one customer interact with multiple business lines? Here’s an example. Say that information about family relationships (such as the spouse and children) is needed for different types of customers to access products or services. Looking at the needs and systems behind managing family relationship data could be a good sprint topic.
An area with a lot of investment but low traction
If the team has been working for months but you haven’t seen the needle move on key metrics, an Enterprise Design Sprint could help. After going through the sprint exercise the team may realize that they should shift gears, that there’s some remaining low-hanging fruit to implement, or that there is a major dependency on another team before further progress can be made.
The design or re-design of an interaction
Pick a point in the process where people are interacting with your business or system and look at how to improve that interaction or design a new one from scratch. Some examples could be a phone call, in-person visit, or website interaction. You may also hear those interactions referred to as touchpoints.
The integration of a new revenue or value stream
Maybe the existing business model is shifting or you’re thinking about adding a new product or service. An Enterprise Design Sprint can help you explore options before committing further resources.
A new customer segment or stakeholder
A sprint would also be a good option if your system was originally designed for a particular set of people and now you want to serve a new stakeholder type.
A goal, mission or vision
You could use a design sprint as a way to break down a large business goal, mission, or vision into something tangible that could be implemented in phases. For example, you could use a sprint to address the goal of reducing the unemployment rates of a specific group of people.
A market trend
Maybe you notice something happening in the marketplace and want some time to explore what that could mean for your organization. Ex. applications of crowdsourcing.
A technology opportunity
You could try an Enterprise Design Sprint if there’s a new technology available and you want to work through how it could be applied to your system.
An item on a roadmap
There could be a general capability on your roadmap that needs to be re-visited, validated, refined, and broken down.
An existing project proposal or proof of concept
Sometimes you’ll inherit a topic that others have already done work on but haven’t completed. Kicking off with an Enterprise Design Sprint is a good way to review what’s already been researched and proposed, what has changed, and where there are remaining gaps.

Step 2) Selecting ideas

At this point, you have a couple of ideas and need to pick the topic to focus on next. Here are some methods you can use to decide:

Go for the highest value
Look at the relative value of addressing each topic, using a value framework. Maybe one topic will impact a larger number of people than another, or perhaps it addresses the needs of a vulnerable population. The complexity is less important because the sprint will help you break down the problem regardless of where you start.
Pick a topic that will help unblock progress
The intense focus and structure of the sprint may give you the leverage you need to work through the block or decide to abandon that course of action and reallocate energy.
Consider time criticality
If you need to move quickly on something and get a plan or solution out the door fast, then an Enterprise Design Sprint is a good option. You can knock out the topic with the earlier deadline before moving onto the next.

Step 3) Testing the topic

After you narrowed down what you’d like to cover, it’s good to do a quick test. Run through the Enterprise Design Sprint stages and see if you can come up with content to fill in each section of the sprint. This step is helpful because if you can’t figure out a logical way to step through the sprint, then the other participants will also struggle.

The actual progression of the sprint will shift as new information is revealed over the week, but it’s helpful to have an idea of what you think you might find when you go off into the unknown. You want to be open to new ideas but having a potential outline can help you guide the group if they seem stuck or confused.

Customer needs
Who could the main customer segments be? What kinds of problems do they have?
Stakeholder needs
Who could the main stakeholders be? What kinds of problems do they have?
As-is
What do we already know about the processes, problems, and systems?
Is there a lot of existing knowledge or should there be extra time spent on the as-is phase? (Ex. if there are no as-is processes documented then you might need to spend time beforehand learning more about the existing landscape).
List the name of know processes or customer journeys to explore.
Success criteria
What measurable outcome could you try to achieve?
To-be
What kinds of concepts might emerge?
Prototyping
What kinds of prototypes might emerge?
What might the roadmap include?
Reviews
What kinds of customers might we need?
What kinds of stakeholders might we need?

Refinement tips

If you went through that exercise and you’re not happy with the progress the team will make, try one of these two techniques:

Expand the topic to include a broader theme, process, or more customer segments. Consider zooming out from the initial request to cover a larger process or a broader set of customer segments.
Refine the topic to include a sub-section of the problem. Consider breaking down the topic into steps, value streams, or customer segments to dive deeper into a particular area of the solution.

Note: A mistake that many teams make in complex systems is diving into the details too soon. That can lead to local optimization without recognizing opportunities in the larger system. In general, the more you know about an existing system, including technology, people, and process, the more successful you will be with a very targeted design sprint topic.

The less well known the system, the broader your sprint topic should be, and you might need to be prepared to run through a few iterations to break down each level. Think of the first level as surveying the landscape from an airplane or mountain top before venturing out to do further investigation on foot.

Step 4) Validating your topic

Now that you have the topic and a rough idea of how it will play out, it’s time to publicize it and get other people on board so you can start scheduling the sprint.

The types of perspectives you’ll want to involve in the sprint:

Business: Ex. Business owners, business architects, business analysts, business subject matter experts. You want people who can speak to the current business processes, rules, and mission.
Design: Ex. UX researcher, UX designers. You want people who can speak to the user needs, user experience, and design perspective.
Technology: Ex. Architects, developers, engineers, system owners. You want people who can speak to existing systems, capabilities, technology and feasibility.
Internal stakeholders: Employees and decision makers, impacted by the current or future system. There could be some overlap between this group and the groups above.
External stakeholders: Customers, users, and third parties impacted by the current or future system.
Management: Helpful to have later on when discussing funding, timelines, and phasing. If you don’t have them involved in the sprint you definitely need their support early on to be able to keep your team focused during the sprint week.

Now it’s time to recruit participants and drum up excitement and support. It helps to prepare a tailored case for the different types of participants. If you’ve completed your stakeholder analysis chart then refer back to it for information about your stakeholder’s needs, otherwise here are some common angles that are effective:

For managers: How the sprint will save time or money, reduce risk and problems down the line. Who at minimum needs to be there and what is required of them.
For business stakeholders: How the sprint will help them achieve their business objectives. When their participation is required vs. optional.
For analysts, designers, and architects: How the sprint will help them complete their job activities.
For subject-matter experts and end users: How participating in the sprint will benefit them or their organization. Ex. to share information and feedback to create a better product.
For everyone: How the sprint will contribute to a larger purpose such as serving others, solving an important problem, etc. Taking a break from regular job activities and playing with sticky notes can be fun, but connecting it to a broader “why” will help energize people.

While going through this step, you’ll probably get positive feedback and volunteers to help you prepare for the sprint. However, you may learn about other time pressures and priorities that could impact your choice or how you frame the benefits of the sprint. Resolving those issues and adjusting your topic or timing up front could help ensure that the results of the sprint are given sufficient attention.

Next steps

Now you have your topic and probably also a list of future Enterprise Design Sprint topics to check out. Next week we’ll talk about the first day or phase of the sprint, “As-Is.”

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.