Journey map operations: what it is & how to get started [plus webinar]

Overview

• What is journey map operations?
• What are roles and responsibilities?
• What is a journey map council?
• What are journey map operations tools?
• How to get started with journey map operations?
• How much time does it take?

Watch the deep-dive webinar

This article has been derived from our "Ask Marc" series that we initiated together with our co-founder Marc Stickdorn and is supposed to be a place for people to learn more about service design and journey mapping software. The sessions usually kick off with a short introduction to the focus topic to bring everybody to the same page, followed by your questions and deep discussions of best practice examples.

On this page you find the recording as well as the transcript. Additionally, the session is available on Spotify, iTunes and Google Podcasts.

• [03:00] Workshop maps, project maps and management maps
• [07:00] How to get started with journey map operations
• [08:10] What’s the operations part about?
• [12:17] How to structure journey maps from macro to micro levels in Smaply?
• [14:30] Can you connect all the different journeys?
• [15:00 and 17:40] Is there an example for maps in a map?
• [15:40] How much time does it take to set up an initial journey map?
• [19:30] Who should update journey maps and how frequently?
• [23:05] Should everyone contribute or is it better to limit it to a few people?
• [24:00] How would you support teams as an external?
• [27:30] In your own journey map ops, what details are you focusing on?
• [31:00] Who is usually in charge of the management of the journey maps?

‍

What is journey map operations?

Journey map operations is a customer-centric management tool for agile organizations. It provides a framework to manage multiple agile projects or even an agile organization, understand overlaps and contradictions and optimize according to newly discovered CX insights.

Journey map operations implies:

• Coming up with a shared language
• Creating a hub of customer journeys
• Embedding a customer-centricity mindset in an organization
• Agreeing on responsibilities and roles – a journey map council
• Using one central tool to manage customer-centric projects

Thus, journey map operations is a whole governing system for an organization around customer experience.

What are the roles and responsibilities in journey map operations?

When you start with journey map operations, you need a specific role in the organization: the journey map coordinator.

They are responsible for different parts of the journey. If we think of the highest-level journey, the person responsible for that should also be the person in the organization who’s in charge of customer experience.

When you zoom in, you probably have different teams responsible for different parts, or even different departments responsible for different parts of the journey. For the more detailed journeys, also assigned journey map coordinators so there’s one coordinator responsible for one journey. You can go down to very specific details of your experience, and have a specific team responsible for that.

‍

These coordinators get in touch with the different departments to find out what kind of projects are going on and where those impact customer experience at a particular part of the journey.

Journey map coordinators get in touch with other departments, start building relationships across the silos of your organization and collect information.

Who should update journey maps? Should everyone contribute, or is it better to limit it to a few people? How frequently should you update them?

This depends on what type of map – workshop maps, project maps, management maps:

• ‍‍Workshop maps you typically do not update. You create them to collect information, probably in a co-creative setting where you invite your customers and learn from them. You might digitize them, it might be a starting point for a project map but you typically don’t update workshop maps.
• Project maps you update throughout a project. That depends on the kind of projects you have. What is the velocity of your project? If you have a fast-paced project where you have regular changes, where you do research, there you might add research data every day to the map. Where you do prototyping, you might add prototypes to it. Or your hypothesis and the results of that. You could also upload reports or videos of the prototypes to it. In a project it really depends on the velocity of it: the faster the project goes, the more you update it. I have been in projects that went on for years and every few weeks people were working on it. Of course you don’t update it on a daily basis, but ongoing. Like every few weeks.
• Management maps rather depend on the speed of your organization.

It’s more like, they add a user pain point, they discovered from the support work. There might be another team pain point they discovered by talking to their colleagues. It might be a new project they add to it. There are only tiny changes every week.

But the advantage is that they meet each week, they take a look at the map. If there are any changes that somebody put up there, they will highlight them. Immediately you see all the changes in the map. What was added to it? That also helps to speed up meetings. The most horrible meetings are those where everyone talks about exactly the same thing every week.

"Most of our clients do it on a monthly basis.
There are few companies – rather in the production and the manufacturing area – where they have lots of products. They were much smaller, much slower going. They produce cars for example, or b2b manufacturer. They do it on a quarterly basis.
And we work with startups who try to be as much on the pulse of customers as possible. They update their management maps on a weekly basis. They do it by having a dedicated team for that, so they have set up small journey map ops team. It’s a handful of people who constantly update, although there might not be major changes every week."
Marc Stickdorn, co-founder and CEO of Smaply

I don’t think it makes sense if everyone contributes to it, because that will be a mess. That’s why having a governing structure where you have a clear responsibility is so important. Who is in charge for which part of the experience? And that means if there’s a person in charge, they get all the information from their own circle. Whoever they build into this circle. Then others can tell them “Hey we have a change here”, “Hey that’s a new paint point” and “Hey there’s a project”. Still, not everyone needs to be in the system to update the journey map themselves.

Many contributors, limited owners.

This then helps to free them, up to have more time to actually focus on customer experience.

It’s important to have both perspectives – customer and employee or team pain points. We then try to connect all the projects with pain points and all the pain points with projects. Sometimes you identify that there are pain points but there’s no project tackling it. And obviously that is stuff that goes into our backlog. This is what we need to fix in the future.

In the more detailed maps we also have a lane that is underlined with research data. That can come from support, from usability testing, from research we run do, workshops we run and so on. And then we actually meet once per month and and go through that.

Who is in charge of the management of the journey maps?

This is difficult to answer in general. That topic is based on the different departments in different organizations. So it can be part of design, it can be part of innovation, in some organizations it’s even part of the C-level where you have a CXO. I would look out for the person in the organization who’s the highest in the hierarchy and actually focusing on customer experience. That might be in innovation, might be in design, but that might also be in marketing. It might also be in any other department, when you look in a role, I think everyone can learn it.

There is not only one single person responsible for them, that is really important. That’s why we like to call it the council. Because it should always be a group of people taking a look at that, a group of people taking decisions. There should be someone high ranking in the organization, because they have an impact. You can also influence other departments. But then you should build accounts that consist of different people with different roles. And that might be UX lead, that might be a PO, there might even be a project manager. This obviously depends on the project manager’s rights. I would not limit it, I would not exclude anyone by definition.

It’s the same as when you’re struggling to build service design capabilities in an organization. You need to look for the people with the interest and the heart and the  desire to really grab onto the work. I think that’s a good way to figure out where you’re starting. Who can own?

‍

What is a journey map council?

A journey map council is here for journey map coordinators to regularly meet, bring all the CX-relevant information together check how the organization is performing, how the various KPIs are developing.

Depending on the organization, they might hold it every week, every month, every quarter. Depending on how quick you move within your organization.

What are tools for journey map operations?

We really want to put the customer at the center, and management tools should help us with that.

On your journey maps, as an additional lane type you add Projects. There you write down all the projects that are currently going on, or that are planned. Because you feed up the information from the very detailed journey, to the mid-level, to the highest level – on the highest level you aggregate loads and loads of projects. As soon as you aggregate these projects, you’ll find overlaps or contradictions between the projects from different departments.

It works brilliantly if you add other lane types as well, like user pain points, team pain points, KPIs. Suddenly a journey map becomes a dashboard of your organization, focusing on the customer experience. You see all the projects, all the KPIs, all the pain points from your team and your users, organized by the experience.

If you move further down into details, you don't only see quantitative, but also qualitative data. You’re going to see projects and you check for contradictions and overlaps. You decide which projects should move on or who should you bring in touch with each other. You also realize that there are pain points where there are currently no projects active focusing to solve them. You can agree on starting research projects for that or, if you already identified the pain points backed up with research, you can set up prototyping projects and in the end also development projects, implementation projects.

Using a journey map as a visual management tool only works if you use a digital solution for journey mapping – by the way, that’s how our customers use Smaply as a governing system.

How to get started with journey map operations?

You might start with a high level map – the highest level you can have, kind of a customer lifecycle. Then you can zoom into any step, create a dedicated journey map there with a different time frame – it might be just a few hours. Then you can zoom into details again and do micro journeys or further level it down into more detail. The difference here is always the time frame. The more you zoom in, the more details you see, but the less time you actually cover in it.

It’s the same as with maps in geography: when you zoom in you see more details but you see less of the scope.

If you map out all the customer experience and organizations offers, you will end up with loads and loads of different maps. I don’t recommend to start with that – rather start with a few dedicated ones. Map out the highest level and then at least one level below. Start with, for example where you have pain points or where you currently focus different projects on.

‍

How much time does it take to set up an initial structure?

That depends on the quality. You get what you pay for. So, depends of course on how much data you already have. If you have all the data, then it’s fairly straightforward. Just put your data into a map, cluster your data. The most time consuming is actually the data collection because a journey map is just as good as the data is.

There are two different kinds of journey maps. There are research-based journey maps and there are assumption-based journey maps. Assumption-based journey map means you just – maybe alone or in a small team – put up a journey map and say: “We think, this is what the customer experience is”. They look great and they might be a useful start, but they are only a start. Because then you need to challenge your own assumptions. They are biased by your own personality, by your behavior, by the knowledge you have. You need to challenge that and back it up with research, so over time you move from assumption-based maps into research-based maps.

If you create a research based map, use various methods of qualitative research: use interviews observations, maybe auto-ethnography – just become a customer yourself, maybe use mobile ethnography… That is probably what takes most time. But most time it can be anything from a few hours to a few days.

Actually creating the map itself is not the big deal, once you have the data. It can take anything from like five minutes to a few hours.

Summary

Journey map operations is a useful approach to take journey mapping from a one-shot tool to a long-term management tool. It implies a few decisions about customer journey priorities and roles, as well as agreeing on check-ins and data to look at. Overall, journey map operations can help to keep the overview on CX-related projects and guide then through the different innovation phases.

And now, what's next?

Go ahead and set up your own journey map operations with Smaply – it's free, forever.