Piloting and Scaling Journey Map Operations at Atlassian

Maren Hotvedt at UXDX Community: Testing and Scaling the User Journey. Video: https://youtu.be/lhNwlgdtgzI

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and context at Atlassian

[00:00:00] Maren: Hi Rory, and thank you for that introduction. I'm excited to talk about this. I have slightly changed the title to "Getting started with journey map operations", which I think is a more honest reflection of where we're at with this practice than "scaling". But there's still, I think, a lot to learn.

[00:00:22] To quickly introduce myself: I currently live in Boise, Idaho, which, if you aren't familiar with US geography, is a place best known for growing a lot of potatoes. But I've had the chance to live and work in many locations, including Seattle, San Francisco, Sydney and Austin, before settling here. I have been in design for nine years. I've worked as a UX designer and content designer, and more recently have really shifted into service design, focusing on strategic end-to-end customer journeys. Before that I worked in consulting, sales and marketing, which has been really helpful as a service designer in understanding how different parts of the business work and deliver experiences to customers.

[00:01:08] On the side, I'm also a debater on Atlassian's award-winning Work Check podcast, which is a very fun show that debates modern workplace practices, like whether it's okay to wear pajamas to a Zoom meeting. I am wearing slippers right now; you can't see them. And last but not least, outside of work I also love the outdoors and spending time with my dog and partner. Besides potatoes, Boise is also an amazing mountain town, with a lot of rivers, skiing and hiking outside my front door.

[00:01:39] A little bit about Atlassian as well, because I think this is really helpful context to understand the environment that I'm operating in. Our mission is to unleash the potential of every team. We build best-in-class software tools like Jira, Confluence and Trello, and also share practices to improve team connection and performance. We are helping shape the future of teamwork and collaboration for over 250,000 global customers and millions of users, and we're a distributed-first company with over 10,000 global employees.

[00:02:13] But don't worry, that's all I'm going to say about Atlassian. I'm not here to talk about our products or product design. I want to talk about service design, and specifically how to make journey maps effective tools for transforming customer experience, through something known as journey map operations, which is particularly helpful in environments like ours, where you have distributed teams and a lot of organizational complexity to deal with.

What journey map operations are and levels of zoom

[00:02:40] First off, what is journey map operations, or journey map ops? Simply put, this is a way to use journey maps as visual, customer-centric management tools to connect organizational silos, align priorities, and see how every project impacts the customer experience as well as your business metrics.

[00:03:01] One of the key concepts behind journey map ops is understanding and communicating journeys at different levels of zoom, within the context of a journey framework. Before I dive into our approach to implementing journey map ops, I want to spend a little bit of time talking about levels of zoom.

[00:03:20] Journey map ops starts with understanding the big-picture view: seeing the forest and not the trees. Every business, no matter what industry you're in, has some high-level customer lifecycle that all work ladders up to. This same lifecycle concept also applies to other groups, such as employees or partners, so where it says customer lifecycle you can swap that out. But essentially there is the canonical big-picture journey. Within the end-to-end customer lifecycle you also have sub-journeys. Some of these are still very broad and may represent months or even years of your customers' experience, which is why we call them macro journeys. And within macro journeys you have even smaller journeys that represent short interactions with your business.

[00:04:07] With journey map ops, over time what you're doing is building up this view of your customer lifecycle at different levels of zoom, and you're able to zoom in to focus on specific micro journeys, or zoom out to look at the bigger picture. When you zoom into the lower levels, it becomes easier for teams to see clear connections between their work. This could reveal overlapping work, often in areas where multiple teams work on the same part of the customer lifecycle. For example, you might have team one, team two and team three all working on onboarding, but for different products and approaching it in different ways.

[00:04:49] With journey map ops you can keep a hierarchy of up-to-date maps. You can build bridges between silos; those silos could be teams, or disciplines like engineering, PM and design. You can visualize ownership to drive clarity. You can show the why behind key metrics, explaining why metrics are moving one way or the other when you pair them with a view of the customer experience. And you can easily access past research and projects, see what you have available, and not reinvent the wheel.

Why Atlassian invested in a pilot

[00:05:25] Even though there are a lot of benefits, implementing and running journey map ops is also very resource intensive, so I want to shed light on why we at Atlassian are investing in piloting this approach. Before we started piloting this practice, we knew that some of our key customer journeys had a lot of room for optimization, but there were some organizational challenges preventing us from making big improvements. These could look like teams duplicating work, lack of clarity on who owned what, and no visibility of other parts of the journey. A team might be working, as an example, on onboarding, but not know what was coming before onboarding, in awareness or discovery, and not know what was happening afterwards in terms of the product experience.

[00:06:17] We had regular rituals to review key metrics, but we didn't have the same for key journeys, and all of that was really resulting in a fragmented customer experience. After, we now have teams that are much more aware of one another's roadmaps and can coordinate projects effectively. Journeys have assigned owners. There's a shared understanding of the journey, and not just the piece that each team works on. Journeys and metrics are reviewed together, and we're creating a more consistent customer experience.

[00:06:53] Let's assume that I've got you hooked: you're super excited, you think this is cool, you want to try it. As I've mentioned, implementing journey map ops, even on a limited scale, requires a lot of coordination and buy-in from different teams. Finding the right area to pilot this in, the right leaders to support it, and the right partners to help champion and accelerate the work is critical.

[00:07:15] To give some context, we started this work in earnest back in December, so roughly five months before I'm speaking today, piloting in one area, and we are just now rolling it out to a second area. I'm going to talk through how we approached our pilot of journey map ops in one area and what you can learn from our experience. All of the work I'm going to talk through was led by a team of two: myself and another lead designer, working in tandem as partners.

Creating the journey framework

[00:07:43] Simplifying things down, we approached this in four steps. The first thing we did was create our journey framework. Next, we prioritized the most important journeys. Then we mapped them in a consistent tool and template. And finally, we put in place the rituals we needed to regularly review them with key stakeholders, and make sure they weren't just sitting there, never looked at again after we did the mapping.

[00:08:14] I'll dive into detail about step one, creating our journey framework. The end state we were looking for was something like this, where we had defined levels of zoom and defined lifecycle stages. We started by looking at the lifecycle stages. The first thing we did was an internal audit of different end-to-end journey work from across the business. We looked at the stages that were being used, looking for common patterns; for example, again, onboarding was a phase that almost every end-to-end journey shared. We then synthesized these into a recommended set of lifecycle stages.

[00:08:51] Next, we explored ways to define our levels of zoom, and for this we had to look outside of Atlassian, at examples from folks like Nielsen Norman Group, Chris Risdon, Marc Stickdorn and others who are leading voices on this topic. One thing I've observed is this is really greenfield; there's very little standard way of thinking about levels of zoom for different journey artifacts.

[00:09:18] But we came up with a model that we think works for us. We landed on a synthesized version of the customer lifecycle stages and documented them, along with definitions for levels of zoom, to help guide our teams. When we tested these with internal users, we found that the more zoom levels and lifecycle stages there were, the more ambiguity we introduced. So we started with a simple framework, and in retrospect, for the lifecycle stages, I would simplify it even further.

Prioritizing journeys and choosing a tool

[00:09:48] At that point we had our outline in place, and it was time to start filling it in with journey maps. But obviously we're not going to map every journey. That's not feasible, and it's definitely not necessary. We needed to hone in on which parts of the customer lifecycle merited mapping and reviewing, and why.

[00:10:07] To do this, we worked with leaders in our org or department to prioritize two things. First, we worked with them to prioritize an area of the customer lifecycle to focus on. For us this meant looking at the global business priorities and the department priorities, and then tying that to the relevant customer lifecycle stage. Next, we needed to prioritize the actual journeys to look at, and get more specific about the particular scenarios we were interested in and why. This helped us not boil the ocean, but was also really important in identifying who to work with on the next step, which is mapping the journeys. I also want to call out that this is just an example visual to illustrate the concept, not the actual representation of what we were focused on. I don't want to get in trouble; this is just an example.

[00:11:00] Once we had agreement on where to focus, it was time to actually map the journeys. A key consideration here is what tool to use. It's one thing to map a single journey, which I think is most often what people are doing, or maybe a set of related journeys. But when you're trying to map a system of interconnected journeys that you need many teams to contribute to, and you want to scale over time, getting the tool and templates right is really important.

[00:11:31] Some of the factors you need to consider include licensing: what is in your existing toolkit? Maybe you already have Mural and Figma, for example. Budget: do you have budget for a new tool, is it possible to get budget? You need to think about complexity and scalability: how complex will your framework be? Are you talking about five journeys that you need to map and review regularly, or 500? That's a very different scenario. And then savviness: how tech savvy are your contributors? Figma, for example, can have quite a high learning curve sometimes, versus something like Miro or Mural, which are more whiteboard tools. Thinking about the tool is definitely a step you want to do early and think critically about.

The journey template and contributors

[00:12:25] Alongside the tool, we also thought about our journey template. We worked with our stakeholders to identify what information they needed to see at a minimum. There were some things we looked at for consistency: for example, how do we have consistent titles so that everything is easy to find? Same with metadata; the reason for that is to make things searchable and easy to find. And then we had the actual information: what swim lanes did we need to include and why? How did we write the scenarios, how did we define the scenarios? And also, what research did we consult to create this journey map, and what types of research do we have available? Looking at quantitative, qualitative and competitive also helps us see where we have research gaps for a particular journey.

[00:13:17] For each journey we appointed a coordinator, who's responsible for gathering information from all of the contributors to fill it out. This can get pretty complicated, especially if you're looking at an end-to-end journey that comprises the work of many teams. Each part of our template has clear R&R, with different roles responsible for different parts of the journey map. For example, the journey coordinator is responsible for the end to end, and they would work with the designers from different teams to fill in the storyboard, analytics and PM to fill in metrics, research, PMs and design to fill in insights, et cetera.

[00:13:59] If your journey has a very large scope, identifying and coordinating these contributors can be, like I said, really complex. Just to give an example, last week we started mapping a set of four journeys, and so far we have 40 contributors and counting. So it's a lot of work for that journey coordinator, but in the end we will have a consolidated view of the end-to-end journey that was not available before.

Running journey reviews

[00:14:24] At this point you have your maps filled in, and now it's time to start your journey review sessions. This is really, I think, where this practice diverges from my experience in the past, which has been: you create a journey map, it gets reviewed maybe once or twice, and then it gets put in a drawer and never looked at again. This is a regular review and refresh of each prioritized journey, and, like I said, this is really what makes journey map operations different from simply journey mapping.

[00:14:57] At a high level, the review process we planned for was: schedule a review meeting; map the journey to be reviewed, or, if this was a second, third or fourth review, refresh the journey; pre-record a walkthrough of the journey; fill out a basic template that has things like the link to the journey, the link to the walkthrough, and some questions we need people to reflect on; and then run the review and capture any feedback to action. Then we would rinse and repeat, on a cycle defined by the journey. For example, a journey that was really high priority and moving fast you might review weekly, whereas a macro journey that doesn't need to be reviewed as often would have a quarterly refresh.

[00:15:47] Like I said, the first thing we did was schedule a review meeting with leaders from across the teams that worked on that particular journey. As I mentioned up front, we're a distributed company, with people working across global time zones, which means everything we do often needs to be optimized for asynchronous collaboration. So rather than do a walkthrough live, we opted to record a walkthrough of the end-to-end journey map and have people reflect in their own time.

[00:16:16] As the leadership team watched the walkthrough, we had them reflect on a set of questions about the journey. These covered topics like how effective it was at helping users achieve their goals, how consistent the UX was, whether we had the right teams and projects in place to improve it, whether we had the right KPIs for the journey, et cetera. The review went well and we got good feedback, but afterward we were still struggling with "so what?" What do we do with this feedback? How do we action it across all of these different teams? There wasn't a clear path to closing the loop on the feedback.

The off-site, early results and what's next

[00:16:51] And then we got lucky. Only a few weeks later we were able to take advantage of the opportunity to review the journey in person at an off-site. With everyone together in one room, we could identify the accountable owners for each part of the journey and set up a working model to ensure that they could collaborate more closely.

[00:17:12] In the end our process wasn't quite what we had imagined, but we were able to feed the information from the off-site back into the source-of-truth journey map, and now, going forward, we can use journey reviews to show the impact each of these teams is having on the end-to-end journey. To keep the end-to-end journey map up to date, we have a lead designer dedicating a few days each month to gathering information from the contributors, updating the map and running a journey review. I think the key thing to emphasize here is that the journey review is part of a larger program of work dedicated to improving this end-to-end journey. Simply having the journey review was not enough; it's tied to this programmatic element that's outside of design.

[00:17:58] Early feedback we've gotten on this work has been really positive, and one of my favorite pieces is just the simplicity of what we've done. It sounds very simple, but it really is a difference from what we had before. Before, we didn't have the clear picture of the end-to-end view; all we had were slices, and we didn't know how they fit together. This same leader is really excited about this practice at Atlassian, because for him it's helping him identify where to deploy his people and teams, as well as where to pull back. He can use journey maps and journey reviews as a strategic tool to deliver better outcomes for the business and our customers.

[00:18:41] What's next? Our goal is definitely to scale this practice across more areas of the customer lifecycle, but we are taking an incremental approach to get there. The first thing we want to do is take what we've learned and try replicating it in another space: pick another pilot area, and then a third pilot area. By testing it in more areas, we're also getting to train more people on the practice and learning new tricks along the way, so we're taking a train-the-trainer approach. Once we have high confidence that things are working well across multiple areas, our plan is to work with DesignOps on a standard playbook, not just for journey map ops but for how to run a journey-centric program.

Resources

[00:19:26] In 20 minutes I can only scratch the surface on this topic, so I also want to leave you with a few of the people and resources I have leaned on as we've explored journey map ops. The first is an article from Nielsen Norman, on the practice of customer journey management. It's very short; go read it after the talk. This is the article that really started sparking my thinking about the idea that you should manage customer journeys like products. A really good article that stands the test of time.

[00:20:00] The next is one particular episode, a very specific recommendation, from the Service Design Show. This episode with Florian Walmart [?] is focused on similar work that he is leading to manage a complex database of connected customer journeys. He's farther along than we are; he has 100-plus journeys that he's managing. Listening to this helped me project into the future at what our journey map ops and journey management practice could look like over time.

[00:20:33] And last but not least, Marc Stickdorn, I believe, is the inventor of the term journey map ops. That might be wrong; don't quote me. But he has a ton of free resources available on this topic, as well as paid training and coaching to help you implement journey map ops. I actually learned about this at one of his training courses, so I can highly recommend them. But he also, like I said, has free videos and articles, lots of stuff to lean on to learn about journey map ops. And with that, thank you. I think we have a couple of minutes for questions, but I'll let Rory confirm.

Q&A

[00:21:12] Rory: Yep, we do indeed. First of all, thank you very much for sharing. I haven't actually heard of journey map ops, so it's new to me. Just a reminder to everybody out there: please feel free to write in your questions on whichever platform you're watching this on, and we'll share those with Maren. The first question I have, because I wasn't 100% sure: are you creating a master map and everybody is contributing to it, or is everybody developing their own separate maps for what they need?

[00:21:59] Maren: There are two. The database is thing one. Within the database, which is organized around the customer lifecycle, I would say we have multiple master maps. We have end-to-end journeys that ladder up to this customer lifecycle, where multiple teams, like 10 teams, are contributing to that end-to-end journey, and they're each plugging their work into that master map, which is part of this larger database of maps.

[00:22:34] Rory: It's a system of maps. Is the separation different products, or could there be two master maps for the same product?

[00:22:47] Maren: There could be. For example, let me try to think of something. Let's say we have a totally different user experience in Asia than we do in Europe. You might have two separate maps to depict that experience, but for the same phase of the customer lifecycle. Or it could be by product. Onboarding is just the easiest example, because I think everyone groks it. We have Jira, Trello and Confluence; they all have different onboarding experiences and different customer bases, and so that journey is going to look different. But at the same time we want to be able to click in and say: onboarding is a common phase for customers, what are the experiences we offer today, and how consistent are they across multiple products? I don't know if that fully answers your question, but it is very much something we're still grappling with, I would say.

[00:23:49] Rory: I remember a talk from Verizon where they have what they call a mega map: the entire company has a single map that they're trying to maintain. And I think your approach is probably, from my perspective, a bit more scalable.

[00:24:03] Maren: Yeah, it's much more of a database that's structured around a customer lifecycle, is how I would describe ours.

[00:24:14] Rory: And just on that point: customer or user, do you distinguish?

[00:24:22] Maren: Yes, I can give you our technical take. We consider customers the business entity. UXDX is a customer; Rory is a user. I would never refer to UXDX as the user. So when we say we have millions of users, those are all part of customers.

[00:24:46] Rory: Sorry, just where I'm coming from would be: let's say within a large company you might have the IT department pay the bills, and they're the ones who decide, let's bring Jira in, or let's bring something in. And then you have Rory, who's sitting here working on a project, and I'm the one using it. Do you have a distinction on that sales versus usability side of things?

[00:25:16] Maren: We certainly have archetypes and stuff like that. I would say those are both user types within a customer.

[00:25:27] Rory: There'll be different sections of the flow. So early on it's more the person who's buying, and then later on it's the user.

[00:25:36] Maren: Yeah, and oftentimes the maps we are creating are not limited to a single user. There are always multiple users involved, whether it's somebody requesting access to something and then that request goes to an admin, for example, or, like you said, one group is responsible for the purchase but the people using the product are a different group. We have to show all of that in what we're mapping, but we certainly think of them as different groups.

[00:26:15] Rory: Just a slightly different take, because one of the examples you gave was that when the stakeholders look at it they say, "Oh wow, I need more data on that," or it opens up insights. How do you share that? I think it ties in with the next talk. User journey maps are often perceived as qualitative. I saw the lines for the emotional journey as you're going through, and that's a very qualitative thing. So how do you actually tie in the quantitative data, that we've done the research, this is actually a problem here, or here's the data?

[00:27:01] Maren: Yes, with our actual system. We have this idea of funnels and funnel metrics: how does that tie to the customer journey, and can we actually pull that data in? In the short term, we are working with our partners in analytics to actually map that data as insights. For example, the customer reaches this screen or this step, and we know there's a 50% drop-off; we're putting that in as an insight. That's, again, the short term. Ideally we'd actually have it integrated with our analytics tools, to be able to show here's how this customer journey is performing right now. That's the dream.

[00:27:42] Rory: I think if you turn that into a product, it'll be quite successful as well.

[00:27:48] Maren: Yeah, we would use that.

[00:27:52] Rory: Excellent. I think that's all we have time for. Thank you very much for sharing, and I hope everybody out there enjoyed it as much as I did.

[00:27:58] Maren: Yeah, thanks everyone.