Alignment workshops

As part of our work as an R&D Studio we often work with clients with ambitious ideas with a lot of uncertainty. With these kinds of projects, we always need to identify something small and practical to start with - something that will be super-useful at answering an unknown or testing a hypothesis.

My favourite method for getting from a big idea to something small and practical is what I call an alignment workshop - that is, we are going to get alignment on what’s important and what we will do first.

I’ve come up with a consistent structure that works well - it’s reliable enough that I can dive in with a new client without much preparation and flexible enough that I can adapt it on the fly as needed.

This post outlines the overall approach and has enough detail for you to give it a go next time you want to align on a set of next steps for your product.

Step 1 - Introductions

Naturally, the first step in a workshop is introductions and setting expectations.

I deliberately keep this section very simple and very short. No warmups or games - we’re going to get to know each other and build trust during the actual workshop activities, and everyone wants to get started with the workshop content.

For introductions of people, I have everyone fill out a sticky note in the online whiteboard tool we’re using (most of our workshops are online). This does one obvious thing, which is to get a list of names and roles of everyone attending. And it does one critical not-obvious thing, which is to get everyone active and contributing straight away. It also lets me know if an online whiteboard tool is new to anyone, and to help them understand that there is nothing more difficult than writing on digital sticky notes today.

For introductions of the product idea, I have someone talk through it at a super high level, and only for a minute or two. We’re going to spend a few hours talking about the idea, so it’s not necessary to go into detail at the start. I explain why we keep it brief because when people have an idea to share, they want to explain it, and I don’t want them to feel like we’re limiting their ability to do that.

I also introduce the workshop structure, so everyone knows what’s going to happen over the next few hours and how they will be contributing. This is important because people wonder (and worry) about how they are going to make sure their ideas are included and what chances they will have to contribute. Explaining this up front lets them know that they will be able to contribute and gets them ready to actively contribute.

Step 2 - Context map

My favourite first activity in this workshop structure is called a context map, where we collectively discuss the current context. The intent of this activity is to start more broadly than the detailed product idea itself,  to get a shared understanding of the context that the product will exist in, and particularly to understand what triggered the client to want to do this now.

The activity uses a canvas with 7 sections (described below) that help people think about their product in relation to a range of different topics. The idea is that the group creates sticky notes that describe what’s happening at the moment, and places them in the canvas sections.

I ask people to particularly focus on recent changes, including why no-one has done this thing before and what has changed to make now the right time to do it.

I don’t make them do the sections one by one - I find that is too linear and constraining (and takes too long). It’s better to allow them to fill it in free-form - that’s how our brains do brainstorming best.

The sections:

• Political: What is the current political environment? Are there recent changes to rules and regulations?
• Economic: What’s happening in the economy, and what economic trends are relevant?
• Demographic: What  are the demographics of your customers (or your business) and are there changes driving the idea?
• Environment: What is happening in the environment - this could be environment as in climate; or environment as in the work environment?
• Technology: What is changing in technology?
• Customers: What do you know about customer needs, changes in needs or changes in customer types?
• Uncertainties: What uncertainties do you know about?

I’ve run this activity a lot, and it’s always different, so there is really no right or wrong way to do it or expected outcome. It primarily serves as a useful structure to start discussing the key issues around the core idea. We refer back to it in later discussions.

Step 3 - Journey map

The next activity is to create a very broad user journey map. This takes a core user task (or more than one, but not all possible tasks) and steps through it end to end, focusing on the sub-tasks and the touchpoints.

These are always going to be broad, as we may not yet know exactly how a user will step through a task in detail. But they help with:

• Understanding the basic user tasks
• Checking if client does know the main user tasks (it is not uncommon for someone to have a good technical idea, but not know what people would do with it)
• Learning whether the client has drawn the user tasks from interaction with actual users, or if they are making it up

It also focuses the following activities on what people need to achieve, rather than the technical elements of the idea.

Step 4 - Features

This is a quick one (well, we try to keep it quick) where we brainstorm the key features that are needed to achieve the user stories. It primarily helps us to think about the scope and size of what might need to be done.

A ‘feature’ is anything that either the user or technology will need to do to achieve the user story. Basics include signup/login, invite a user, set up a profile, add key information, edit key information, connect to external data and much more.

Step 5 - Assumptions and unknowns

Next we start talking about knowns (assumptions) and unknowns. We do them at the same time as, whenever I have attempted to talk about them separately, we end up talking about them at the same time. 

The intent here is to create a list of unknowns that we can use for hypotheses and experiments; and a list of the things that the client knows for sure, so we can confirm that they are actually true. 

I’m always very cheeky in this activity and tell the client that we are going to write down all the things they know for sure, and still call them ‘assumptions’. I make it light-hearted so they don’t feel like we doubt them, but reinforce that it is very common to be absolutely positively 100% sure about things that we later find out to be untrue.

Step 6 - Hypotheses

By now, we’ve had a lot of good discussions. And really, the point of all of this is not to create the outputs from these activities but to have a discussion. The activities just give us focus. And honestly, by the time we get to this point, we’ve usually also discussed a whole lot of other stuff that doesn’t fit into the activity categories (my whiteboards are always full of sticky notes outside the borders of the activities).

We can now write a set of hypotheses - statements that are written as if they are true, that we can use as a focus for work activities that test if they are true. 

From a hypothesis statement we can discuss what kinds of activities we can do to determine the truth of the hypothesis. This might be a small technical spike or proof of concept, some user research, a conceptual prototype to test with. It will rarely be a MVP, and never a full product, even when that’s exactly what a client might have come to us to create.

Step 7 - Next steps

The last step is to make an agreement about what the next steps are. These usually flow pretty clearly from the hypotheses. Sometimes they are for the client to go away and research further and sometimes for us to cost out a small piece of work. We don’t jump straight into costing out a project if it is not the right time for it though.