Day 5: Reviewing with stakeholders

You’ve been sprinting for almost a week and you’re probably exhausted but there’s one day left. This is the day when you’ll share your prototypes and diagrams with other people. You’ll start to receive feedback, which will help you decide whether to pursue the idea, abandon it, or move forward after making changes.

So, I said that this was the review “day” but most likely it will turn into several days. There are usually a lot of stakeholders involved in complex systems. Unless you get really lucky and everyone’s schedules align, it’s unlikely that you’ll be able to complete all of the user and stakeholder reviews in one day. However, aim to complete the majority within one week. Otherwise, it gets easier for the review to be pushed to the side because of other commitments (or fires), and the momentum will be lost.

Purpose of the reviews

Your goal with these reviews is to test your assumptions qualitatively.

You’ve made a lot of assumptions in the past week. You’re assuming that,

Users feel that they have the problem you identified and agree that it’s the most important problem to solve
Users will think that this product/service/solution solves that problem
Business stakeholders will be able and willing to support the change
Technical partners will be able and willing to support the change
The solution is in alignment with high-level business and technical strategic goals and initiatives
Your draft roadmap and product or business model phasing are desirable and feasible for users and stakeholders

As you gather feedback, pay special attention to (a) anything that could dramatically hinder success or (b) information that this is a valuable investment to continue forward with. Ideally, you landed on what customers want and your business and technical teams will be able to support it. If not, it’s much easier to pivot now when you’ve only invested a week than to continue further in the wrong direction.

Outline of the day

Unlike previous days, I won’t recommend a specific agenda for this day. While the sequence and timing of events were important during the previous days to keep the momentum going, for the review days it’s more valuable to be flexible. Hold the reviews at times when your stakeholders are available and in a mood to focus and provide feedback.

If you need to stretch these meetings out over a few days or up to a week that’s ok, but try to schedule at least one for the day after the prototype is completed. Each meeting may require between 30 minutes and two hours to get through the material, gather comments, and ask follow up questions.

User reviews

Looking back at your conversation on day one of the sprint, your users are the people who will end up using your solution, who are usually outside of the organization but may be internal employees. The best users for testing are people who either are in your target market or who work closely with them. For example, a professional who represents a large group of your target users could also give you valuable insights into their lives and needs.

Your organization may have rules or standards about how much information can be shared with external parties, how they are contacted, who can communicate with them and how. It’s a good idea to investigate your organization’s policies before conducting user reviews to avoid any issues down the line.

How you structure your reviews may change slightly depending on how detailed your prototype is and what types of assumptions you want to test. If you’re working with a brand new user base or problem, you might want higher-level feedback and more of a discussion about their lives, workflows, and pain points. If you have already validated the user need then your review may be more focused on optimizing the details of the solution. If you’re working in a for-profit then you might also want to test if they would be willing to purchase the solution.

Here are some examples of activities you could do during your review to test assumptions:

Interview users about their daily life, workflow, and pain points (ex. how business owners normally find and interact with customers)
Demo the prototype to gather their feedback on the flow, functions, and design
Ask them to complete a task using the prototype and observe the steps they go through and their reactions
Survey them on their interest in the product (ex. ask for newsletter sign-ups or pre-orders)

Stakeholder reviews

This includes everyone who won’t be end users of the product but have a stake in the outcome or development of the project, such as business stakeholders, technical teams, and executives.

For stakeholder reviews, you’ll want to share the end experience but also some of your analysis and reasoning that led to those choices. Review your stakeholder analysis chart as you prepare review sessions, to ensure that they focus on the information that your stakeholders care about the most.

Business stakeholder reviews

Your business stakeholders may be managers in charge of a process or they could be frontline employees. They are your business partners in charge of helping you execute the entire end-to-end new experience. They might be in charge of training and procedure changes, but will probably also be experts in the existing processes and systems.

They were most likely involved in the earlier days of the sprint so this is the opportunity to check back in to confirm that the final prototype accurately represents the business needs, terms, and processes. This meeting is also an opportunity to share new ideas about what the experience could be with or without business process changes. Sometimes new possibilities don’t resonate as strongly until you’re looking at a prototype of the new experience.

Technical partner reviews

These are the people in charge of implementing technologies, platforms, or sites that support the business activities. The system maps that you created on the first two days will help to identify the technical groups that need to be involved in the review.

The purpose of this review (or set of reviews) is to test your technical assumptions. While creating your design and roadmap, you estimated what would be feasible to implement in the short term given your current knowledge about assets, processes, timelines, skill, funding, and priorities. Make sure you spend some time validating those assumptions before locking in your current designs.

When meeting with technical teams share high-level information about the problems you’re trying to solve, along with the to-be experience, and alignment with strategic goals. This will give you common ground and understanding of what you’re trying to build, why, and the relative priority before diving into the “how.”

Another goal is to align understanding of the high-level architecture and the draft roadmap. If this is your first meeting with the partner then this step will be especially helpful because their side is probably a black box to you. Discuss the interface, what this system could look like, and any known roadmaps and initiatives. Depending on your organization, actually implementing the change could take weeks or years to get priorities aligned but in one week you’ll have information about what could be, how it could be divided, and what will need to be in place to execute the change.

If you’ve worked with that team before then you can probably jump straight into the details, otherwise, you might need to plan an initial meet-and-greet with program executives that covers a high-level view of your objectives. Then you can plan follow-up meetings with system architects or other subject matter experts who can answer your more specific questions.

Executive reviews

There is most likely someone playing the role of executive sponsor for your project. You may even find yourself with multiple sponsors. They most likely didn’t have time to attend your design sprint but are accountable for outcomes and can influence priorities and funding decisions.

Your goal with this review is to verify that the direction you’re going in aligns with their strategic goals and vision. Another benefit of this meeting is that you’ll learn about new initiatives (or changing initiatives) that the executive may know about that you are unaware of. It’s also an opportunity to share what you’re trying to accomplish so the executive has more information to support your work.

Schedule this meeting in person if possible so you can see their reaction and adjust your presentation if necessary. They will probably have a random 30-minute time slot available so you’ll need to be flexible and get straight to the point. Keep the presentation short and high level, highlighting the problems you’re solving, the to-be experience for customers, and the draft roadmap. Executives will be especially interested in next steps, timelines, and what you’d need from them to execute the changes. This is also a good time to share known risks and mitigation plans so you can brainstorm strategies long before money is invested or the risk materializes and the dynamic becomes more tense.

Retrospective

Regardless of how many reviews you can fit into the final day, plan on holding a retrospective with the team. You’ll review the stakeholder feedback later, but this retrospective will be focused on the Enterprise Design Sprint process that you followed. Try this simple exercise with the group to draw out what has worked well during the week and what you need to adjust in the next sprint.

Write down as many notes as you need in each category:

Keep doing
Start doing
Stop doing

Keep a running list and revisit it after each sprint. Pick a few items in the “start doing” and/or “stop doing” sections to focus on for the following sprint. At the next retrospective cross off items or move them between categories if necessary. Seeing incremental improvement can help motivate your team and keep them excited about the process.

Next steps

You’ve learned about why Enterprise Design Sprints are useful, how to pick a great topic, and what to expect during the first five days, from kick-off through reviewing with stakeholders. We’re not done, however. The next post in the series will be about what to do after the sprint is over.

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.