Automated transcript
Introduction
---
In this event of the Swiss Service Design Network we speak with Marc Stickdorn about the origins and future of journey management. Marc is the co-creator of the Service Design tool Smaply. And the co author of a series of books about Service Design.
During this conversation, we explore topics like:
What are the different periods that led to journey management?
Dangers to be aware of when starting in journey management.
How to work with KPIs and metrics in journey management.
What software tools you can use to get started.
The future of journey management and Service Design.
Why governance makes or breaks journey management.
We also rant about the terms, Service Design touchpoints, and you guess it. Journey management.
A big, thank you to Marc for this lovely conversation and for sharing all of his knowledge with the community.
Daniele: Welcome, everyone. Without further ado, I'd love to introduce Marc to the stage. Hello, Marc.
Marc: Hello. Good to be here. Thanks for having me. Yeah.
Daniele: Thanks so much for accepting the invitation.
Meet Marc
---
Daniele: I'd love to start very quickly. If there is one person that doesn't know you yet what's your one minute Who's Marc explanation where you can name drop everything you do just so that people have a few references that they can then go in Google and say, Oh, That's the book. Oh, that's the company.
Oh, that's this
Marc: blog. I Try it. Hi, I'm Marc, a German living in Innsbruck in Austria. So in the middle of the Alps, similar like your environment, I'm in, in the field of service design for a while. I publish books like this is service design thinking in 2000. 10 together with Jacob. Then 2018, this is Service Design Doing with Jacob and Adam and Marcus, and this is Service Design Methods.
And I, gosh, worked in service design, did projects, realized a common issue and started the first journey mapping software that was more than 10 years ago. And obviously there's been some developments in it over the last 10 years. I guess that's what we're going to talk about. Besides that, I teach at different universities and I help organizations all over the world to embed and scale service design and journey management.
Although I don't like this term, but I think we're going to talk about this later.
Daniele: Absolutely. I see you are. This modern service design humanists. I know that there is a word in service design humanists that you don't love either, which is very good because we're going to have a few rants in here, but I'm going to keep them for a little bit later.
The origin story of Smaply
---
Daniele: May I ask, so you started this company which is, which was one of the first really companies doing this journey management thing. And why the fuck did you want to do that? Because that sounded like a lot of work to create a company doing that and doing the software, especially 10 years ago.
So why did you jump on this adventure? So
Marc: 10 years ago was not about journey management, at that time it was about journey visualizations. And if I think back probably like 13 years ago, I was working with with companies and saw a certain pattern when we looked at how they're using journey maps.
At that time, I saw some companies using design tools of that time. At that time, it was like things like InDesign and so on, where people created beautiful journey maps. And although I'm not a fan of beautiful journey maps, I'm rather a fan of useful journey maps. But they had beautiful maps. And the problem I saw with that was that they became static.
No one changed them or there was only one designer who was able to do changes in that. So they were not dynamic. They were not using really as a living boundary object, but they were static. And the other side I saw were companies using at that time tools like. Excel to do journey maps and even though the journey maps were ugly, they were accessible for the organization.
And that's why they worked much better. They were not useful for really communication, but for working, they were good because of accessibility. And I thought like at that time we actually need to. Put both sides together. It needs to be easy, needs to be accessible. We need to be able to democratize how people do journey mapping while at the same time, we need to make sure that we keep a minimum of of visualization in it people can actually use it.
And that was a starting point for Smaply at that time, where we said we do a software that. basically fit in the middle and focus on visualization. Then over 10 years, hopefully it all evolved and changed, luckily. But that was the starting point for it. And we first used it in our own projects and then it evolved to become actually.
A company focusing only on software for journey mapping and likewise tools like personas and system maps and so on. Yeah,
Daniele: absolutely. It's, in fact, it's one of the first softwares focused on service design that they've covered that I discovered back in the days where I was like, Oh, there are people doing specific software for this community.
And this was also a realization of it. Okay, I'm feeling a lot less alone right now which is something that is very interesting too,
Marc's Service Design Ecosystem
---
Daniele: you're not just building the software, you're also doing all the kind of education community part, which goes with it, can you maybe give us a bit of a hint of how you see this?
Is it just you built, pushing the software. Do you see it as a complete ecosystem? How can we think about that? I
Marc: see if I think about my, what drives me personally is I want to bring service design, however you call that what we're doing. Cause I think it runs under different names.
I want to bring it into as many organizations as possible, because I think it's really a way to change. What we are offering to the better, if we care about employee experience, about customer experience, about citizen experience, service design is just one way to really improve it sustainably. And that is my personal mission.
So that's what's driving me because I see the impact it can have, the impact we can have as a community. And if I think about how we can drive this publishing books is one way. It democratizes things. It brings it into the hands of many people. I give courses, public courses. I give exclusive courses for companies.
I I work in education at different universities. That's another thing. And software was just. Again, another thing to bring it into the hands of more people. And so if I look at what I'm doing, these are separate streams, actually separate foots of myself. And I think they fit together nicely. What I Always try to do is not if I do courses, I always do it software agnostic.
Like I don't use my books or my my trainings to sell more of my stuff. Cause I think it's, people need to look what's out there and make their own decision and and that's it, but helping more people to do what we're doing, I think is is what's drive me and where I see right now, we're having an impact beyond what we.
ever imagined when we published the first book or when we started working on the first book 15 years ago. At that time, it was a fairly small community, right? We were all at Twitter, we knew each other and it changed dramatically from there. So thank you also to you for pushing it, not only in Switzerland, but through these events globally.
Software agnostic Journey Management
---
Daniele: You said something that I'd like to build upon, which is this idea of software agnostic, I think that's a, it's a very important element, to learn all of these ideas, principles, and knowing that there are many softwares that exist, some made for it. Some not made for it, I've seen friends doing kind of journey maps on Excel, but, proper high level stuff, where you, with formulas and stuff and for them, it works well, and
Marc: so I think Not only for them, Excel is still the most used software to do journey maps. Okay. Or you know what is the second most used software to do journey maps? It's PowerPoint.
Daniele: Obviously. Yeah. And sometimes it's just the best tool, sometimes it's just the best tool. Sometimes you need something else.
And I think that's a very good reminder that I'd like to give to the community, which is, try out the different tools, Smaply is one, there are many other ones. Obviously some today we'll give also a bit of hints about that particular tool because you're aware of it as you're part of the organization, but again, always, Take this lens that it's just one tool and what is true for software is then also true often with methods.
But as I think this is a bit of a parenthesis that we sometimes need to address so that people don't feel like, Oh, we're pushing in one direction or the other, because in the end, we're just trying to make people aware of what exists in the world and then try them. And see what works for you.
Marc: And I have clients who are actually running journey management on Confluence like the Atlassian documentation tool simply because they can't use anything else and it's working, make it work. So it's more about setting up the right governance structure, finding your way of working and whatever resonates in your organizations, use that.
Daniele: And then there is also the kind of looking at some tools, where you say tool is interesting, but it's not for us, but we might steal a few ways that they, push the process or there are interesting ideas that you say, we're not going to use that tool because of X and Y reason.
But we still can get inspired by the way it's set up, by the way, they, they educate stuff, and, get inspired, build on that, and obviously you can also say, always reference where you're stealing from, which is always one thing that we do in the design world, but I think that's definitely something that we need to do.
Why Marc hates the terms Service Design, Touchpoints and Journey Management
---
Daniele: But I'd love to go on a rant with you because there are three words that I heard, someone told me there are Three words that you hate. Can you tell me which are these terms and why do you hate them so much?
Marc: I actually talked about this, like currently I'm running our our journey management course and the TIS deep dive course.
And I went on a rant this morning. So yes, happy to rant a little bit more. I Start with service design and if you been to one of our courses that especially Adam and myself, I'm always making fun of that because we don't like this term. And the reason why we don't like it is because people who hear it for the first time always have a misconception of what they mean.
They think they immediately know what it means because it consists out of two words where people know immediately what they think it means. Service, they understand as, oh, service is how the waiter brings me my coffee. And then they hear design. They think about design as aesthetics, like the design of the new iPhone and so on.
And then they put those two words together and they think service design, I know exactly what it means. It's the aesthetics of how a waiter brings me my coffee. And when they hear that, they think it's. It's trivial. It's, I know what it means, but it's, I don't really need that. What we mean with service design is service is making 80 percent of our economy, of our GDP.
And if you follow approaches in Marceting, like service dominant logic, it is a hundred percent. Everything we do is in fact a service. Design is changing a state of something into a better state, so improving or innovation. And if you put those two meanings together, what service design means for me, it is the innovation or improvement process of what makes the majority of our economy.
And that has a very different meaning than the aesthetics of how someone brings you your coffee. That was the first rant. Should I go on?
Daniele: Yeah. Absolutely. I love when you rant.
Marc: All right. Let's zoom in a little bit. We often use in service design, the word touchpoint. And I think touchpoint is just, it's a bit ridiculous.
If touchpoint comes from, it comes from branding, right? The brand touchpoint was the billboard on the highway and so on. But how we're using it nowadays in service design, we use it for things that are rather an interaction between people. It's nothing you can touch, right? It's an interaction we have.
And and it's definitely not a point, right? It's a moment in time. So the whole phrase doesn't make sense in service design. Still, we're using it. Often we use it synonymously with channels and there's not one definition for it. Every agency, every organization is slightly using touch points.
different. That's why we have so many so much confusion when we work together as a community. One of the first things if someone uses this in when we work is please can we define what you actually mean with that? Because otherwise there's a risk that people don't understand each other.
And even the journal of service design by SDN is called Touchpoint. So I think we're going to stick with the word, even though I don't like it. Same with service design, right? I'm going to stick with it. I don't make fun of it. And the third rant maybe is about journey management. I also don't like that term.
And that, like we, we started using that. And I think around 2016 or so, I tried to to help organization to bring it in. And we realized that just the notion of management in it makes it really difficult to bring it into the organization. And that's not true for all organizations, but for many organizations, if you, Bring in a new management approach, people see it as a threat because, oh, there's a new management approach, there is, I'm going to lose power, I'm going to, we're going to change how we make decisions and all that, they're afraid of it, and that's why they want to hold back on that, and what we try to do is, Please change it to a label that resonates in the organization.
Same with service design, right? Many of my clients call it differently. So use what you like. Use whatever resonates in your organization. Same with journey management. I often prefer to call it Journey Map Ops or call it an information system. Just lowering the hurdle to actually talk about this and bring acceptance to organizations.
End of rant. These are the three terms I don't like, but I still use them.
Daniele: But it's good because through your ranting, you give also definitions. And that's my hidden my hidden agenda was also to get you to help the newcomers in the world of service design to have also this kind of definitions.
And I think it's been extremely useful, especially. More fun in a RAN form. And the title that we had for this event is about the origins and the future.
The origins of Journey Mapping
---
Daniele: So I'd like to jump on the origins side. How, did this happen that, we went from Building journey journey maps to then thinking, Oh, we have to manage that aspect.
And, are there, with time, we sometimes can say, Oh, there were pivotal moments or there were trends or moments in history that were interesting. Do you have a
Marc: take on that? Yes. so If I, When I've been asked to describe what JourneyMaps is, I always describe three distinct use cases of JourneyMaps.
And it's often helping you and your organization if you differentiate between them, because it clarifies like, what is the context in which people use the JourneyMap. thE first one is using JourneyMaps in a workshop. We call them the workshop maps. And you typically do this either focusing on current state, so for research and researching how the experience is right now.
If you do a co creative workshop, you invite your customers, you invite your frontline staff, and you try to understand what are the pain points, what are the unmet needs, and so on. Or you do it for future. Prototyping, doing imagine like prototypes and future state maps that show this is how the experience could look like.
Sometimes we combine it as well. But what is common in this workshops is that the map itself is actually not so important. It's more the conversations we're having. A map helps us to make sure we talk about the same thing. We use them as what's called a boundary object. If we were to design a physical object like this pen, We can put it on the table and everyone knows exactly what we're talking about.
That is a boundary object. So people with different backgrounds can take a look at the same object and retrieve the important information for them. So for a pen like this might be someone from Marceting can look at that. And how can we actually Marcet this? Someone from sales can look at that and say, how can we sell this?
How can we put it into our shop? Someone from engineering can look at that and say, how can we manufacture it? So the same object have a different meaning in different worlds, but it makes sure that we all talk about the same thing. When we talk about experiences, there is a danger that we actually don't talk about the same thing, unless we put in a boundary object.
And that is what a journey map often is. It's a boundary object for us to make sure we talk about the same thing, especially in the context of a workshop. So this is the first use case, the workshop maps. And that is what we saw a lot in the early days of service design and we still see it, obviously, it's still a very useful thing to do.
It's a valid research method to run a co creative workshop and so on. But the second use case then came along and I would say it is Right now, still the dominant use case, and that is using a journey map within project, called project maps. That means we use a map to visualize our research data. We create a research based current state map showing how the experience is right now with all the research data underneath.
Maybe we even start assumption based and then add research data on the go. Once we established a current state map and we understand what are the pain points, what are the unmet needs, what are the opportunities we're having, we spin off different future state maps which then hopefully goes into an implementation process.
I just want to stress it out since we're talking about service design. Implementation for me is a part of the design process. Service design does not end with a beautiful journey map or blueprint. It ends as soon as we had an impact. on the user, on the customer, on the employee, on the citizen, whatever we focus on.
So these project maps can live on for a long time. Like some projects last about years, but once the project is done, they often end up in a drawer or even worse, you keep up them, you keep them hanging in your in your creative space and it actually becomes a museum for journey maps and especially leadership likes these maps because they are nice background for interviews.
You often see that, but then suddenly the C level is giving an interview in front of a three year old journey map just because it looks nice and inspiring, right? But you don't use these maps anymore. And The third use case of maps is what we saw probably starting around 2016. And that's what I call the management map.
These are maps that you don't use only for one particular project, but you keep them up to date. You set up a governance structure around it. Who is in charge of this map? Again, we can talk about labeling and naming. Some call it like the journey owner, the journey manager. I prefer, again, to tone it down because language matters so much in organization and rather call it the journey coordinator.
But you set up someone or a team who's in charge for it. And some set up like a RASI approach where you then also have people who are following the map, who can serve as an expert to the map and so on. And you use these maps not within one project, but to understand what are all the projects we are doing.
What is the backlog of our work? What are the pain points we need to tackle? What are the next journey maps we need to map? What are the things we need to research on? What are the unmet needs? What are the opportunities we should be tackling? So you use them as an information system in the organization.
And what happened over the years is that it's not only one map, but we built out different zoom levels. So I think that is also around 2016 when we saw high level maps with lower level maps with we've done it in projects forever. But as a system that you keep up to date with a governance structure, I think that was around the time.
And now what happens then in the years after we added we added live data to it. We added. The connection between journey maps, decision making tools and and backlogs. So how can it actually tie into your research ops, tie into your design ops, tie into your dev ops and so on.
Daniele: Yeah, that's, that gives a very good overview.
Thank you so much. And I'm quite interested to transition to the present where, you know.
Beyond the tools for Journey Management
---
Daniele: Outside of the tools, I'm very interested in you, in the processes, the rituals, the routines, the mindset changes, when we, when I first discovered back in the days, a journey mapping, it came not just with tools and methods, but it came also with a different way of thinking, and what's like the upgrades that we make when we come from journey mapping to journey management? Are there specific ways of thinking that we need to address? Is there new ways of working that we need to implement?
Marc: I think it's a natural transition because the transition is from, focusing only on one project to the strategy of what are the next projects we should tackle.
And that comes also with an increase of service design teams where you have loads of designers working on it. And you actually need to come up with a strategy and a roadmap for what are the next things we need to tackle. And Also, this need in organizations that the design team was often navigating without a clear understanding of what is happening in the organization.
Because one of the problems we are facing is most projects that impact customer experience does not come from the team who's responsible for customer experience or design team or the innovation team, right? It comes from everywhere in the organization. Think about the a change of software, be it customer facing or employee facing.
It has a huge impact on the experience, but often the design team becomes aware of that way too late. It's a change of standard operating procedure there. Think about the impact of GDPR on us. We often don't know what is going on. And this kind of journey management allows us to also tie in and understand what are the different parts of the organization actually doing and how will it impact customer experience?
How can we fit in and how should be our roadmap to improve experience, not only step by step, but also looking ahead and being more, more strategic in it and less tactical.
The possible futures for Journey Management
---
Daniele: So we have the past, we have the present, or some elements of the present. You know where I'm
Marc: going with this. Yeah, AI, right?
Daniele: No I would say futures with an S.
Like what are the possible futures? Obviously, AI might be one but I think that's like the fancy one at the time, which obviously is fun, but what are the multiple futures that you see? And maybe what's the one, the ones where. You already see, like seeds and where you see, Oh, this is growing.
And not many people notice it, but this is bigger than maybe AI or this kind of stuff.
Marc: So I think AI is the obvious one, right? Everyone sees it right now. Everyone. It feels the impact it has on our own work, on your personal work as well. We see it in every tool picking up, no matter which activity and design you look at, it has an impact on everything, right?
In how we do research, how we go through our data, how we get into insights. AI plays a big role. Same in, in, in ideation, like you can. You can use ChatGPT to come up with with decent, at least to a certain standard of ideas for any problem. And and it happens fast, right?
We always showcase that in our trainings and. People are always amazed. We are amazed how fast it is. And prototyping, same stuff, right? It's happening everywhere. Nowadays we can be so fast in that. And sometimes we are overwhelmed by the pace of it. it Also comes with dangers and we did earlier this year, some experiments with generative AI for for journey maps, like it's so easy, right?
You put into chat give me a journey of 20 steps for this experience and bam, you have it. You can even get pictures for it, and you have a journey map. The problem I have with that, it's always, it's very general, it's not based on the actual experience you're looking at. And I think there is a craft to do journey maps because like maps in geography, a map is not there to represent reality as accurately as possible, but it is there to reduce complexity so it becomes manageable.
And that needs to be accurate to the zoom level you're looking at. And it's often rather a political battle in the organization to agree on certain terminology and certain steps in the journey. So zoom levels and so on, where I think AI, yeah, might not help, but actually harm. Like we saw experiments where folks didn't focus on the journey maps and when the creation of journey maps anymore, they just took what they saw and they say okay that's what we work with and it results in shitty decisions because there's no one really in really knowing the customer experience by heart anymore.
If we look ahead what we see is that journey management or however you call it Helps us to bring service design into organizations without using the term service design. And I think that is a really good thing because people always have in organizations a misunderstanding of what design actually is.
And sometimes we struggle to bring it into the organization simply because we're using the phrase design. So again, language matters. And if you get around it, it brings actually. Customer centricity service design approaches and way of thinking into organization without talking. Because in the end, it is a team game, right?
We need different parts of the organizations to contribute to it, to really propel forward. Um, maybe another thing that I'm seeing is it helps organizations who didn't focus on the topic yet to start focusing on the topic because it brings away. Service design from, or customer centricity, improving of customer experience, which is often regarded as a, as an add on as a nice to have, we now finally want to be want to be nice to our customers and so on, and it moves it away and brings it into an investment decision where people clearly can see what is the investment we need to take?
What is the budget to change something? And what is the return of it? By understanding how much does it decrease cost in our organization? How much does it actually improve our revenue and how much does it improve the impact on patients and healthcare and so on? So it gives more data to it.
And that's what I really like.
Daniele: This goes beyond, this technological determinism where we just say, Oh, it's going to be AI everything.
And we're just going to take out our brains, but also say, Hey, there are, there is a danger in making it too easy. For certain phases of of any work. And there is good questions to ask yourself. It's a good question to ask yourself. Should we make that part easy or should we not? And obviously the answer is different in for everybody, but I think it's a very good question to ask yourself.
Are we willing to make it easy or is it the fact that it's hard? Is that where the real work happens? Is it the fact that we have to go through the research, we we have to empathize with that, and it's not just ChatGPT summarizing, okay, these are the insights now, based on that, I'm making your journey, and based on that here are the three action points that you have to decide on, and, oh, by the way, I've made the decision for you, do that.
So that's, I think, a good a good reminder.
Marc: To quote my my friend and colleague, Adam sometimes the facilitator needs to become a difficultator. And sometimes that is our role in an organization.
Daniele: Absolutely. So I'd love to transition to the questions of the crowd. I see we have a few people who are very into the questions.
So thank you so much for sending all of that stuff. I will start with this first question which is here:
How does Service Design shape organizations?
---
Daniele: Do you think service design These two could benefit from a different organization design. In other words, have you seen organizations design themselves differently due to service design?
Marc: Yes.
Yes, absolutely. Every organization does reorgs for every now and then, right? And most people hate it if that happens. But some of them are actually useful. And what we see in the last five to eight years, more and more happening is to design around common experiences to design around certain journeys teams are responsible for.
And Naturally, if you are set up around certain journeys or parts of the experience it's much easier to to work on that in service design and to bring journey management into an organization and so on. The, what we're facing often are silos in organization and if, and the thing is customers don't care about silos.
Preaching the known here for us. Customers don't care about silos, but organizations do, and we need to ask ourselves, why do organizations have these silos? Because it's easy to manage, right? It's easy to keep an overview for it. How can we actually nudge organizations towards Breaking down silos or connecting silos.
Think about things like having cross silo KPIs that are rather tied to an experience, tied maybe to a journey. And every organizational department silo that is part of this experience gets the same KPI. Because the problem we're often facing is that you measure success within an organization within a silo and not from a real customer's perspective.
So anything you can do to break that will help you to bring this into an organization.
Daniele: And I think it, it creates a lovely transition for the next question.
Metrics and Journey Management
---
Daniele: You spoke about the KPIs. So one question is how important are metrics and data in journey management? Obviously that's the next question that comes up.
And obviously then there is the very technical nitty gritty question. Like how well do the tools. In the end support and integrate to other systems. How does that look like in practice?
Marc: Yeah. I could do another rant now about NPS and, but I've done it so often. So I think it's boring to do that again.
It's rather a thing underneath it, like what we saw in the last 10 years was sometimes horrible when companies over focused on net promoter score. And the problem is also net promoter score and that it lacks like academic underpinning and validity because we don't know if it really measures what it's supposed to measure and all that stuff.
But apart from that, the biggest problem is if an organization just uses one KPI. What happened there was, if an organization is just using one KPI, projects that impact the KPI, but not what the KPI is supposed to measure. Companies build huge driver models to understand what impacts this KPI, and then do this little thing, which has the biggest impact on the KPI, and in the end, they do two things.
They run a campaign about how great their service is And their five star service and 10 points and so on. The second thing is you get every employee to ask in every interaction to give them 10 points in the follow up survey that they get by phone or by email next day. And that is horrible and has a really negative impact on the company, but the KPI skyrocketing.
So that is the problem about KPIs. Never use one KPI. For any journey or any experience, always triangulate, always use a mix of KPIs. So if you learn from business, use a balanced scorecard approach for each journey. What are the core set of KPIs? As a rule of thumb, three experience centered KPIs, three business centered KPIs.
If you have a balanced scorecard, You reduce the risk that people start doing projects just to impact the KPIs and you rather focus on what the KPIs are supposed to measure. The problem you have is if you have a balanced scorecard per journey and you have different journeys, be it horizontally connected to each other or vertically connected to each other, You want to get some sort of comparison between these journeys and a tool I like to use for that is called the JPI, the Journey Performance Indicator, a very simple traffic light system, red, yellow, green, which kind of summarizes your balance scorecard and shows you how healthy this journey is.
Again, our clients all have different names for it. They don't call it a JPI, they call it health index or whatever. BuT this little traffic light system, if you look at an overview of your journey hierarchy, shows you immediately which journeys are healthy, green, which journeys you need to monitor, yellow, and which journeys you need to act on, red.
And that is a nice overview to understand where do we need to focus on. Then you can dig deeper into the KPIs and hopefully dig deeper into the qualitative research to find out what actually triggers this change in the KPI. Because a quantitative metric will never tell you. Why you see a certain behavior, you always need to ask, observe people.
And that's it. Yes. Use multiple KPIs. How you implement that in tools? If we think back, we started 2016 with the current version of Smaply By having integration with Google Sheets, for example, Google Sheets can be filled from any other sources. And then you could visualize this data there.
It was rather rudimentary at that time, but that was the first step towards that direction. We implemented Jira for example. So you could also see. Do you use a story mapping and see like what is the state of it and so on. And nowadays, if you look at different tools, I saw another question there.
What are the top tools right now for journey management? I would say there are four out there. There is a CX Omni, they do MilkyMaps, Maply, and then probably tools like Spreadsheets, which are used as well. And we all do it slightly different with different different advantages here and there.
But I think it's a trend we see in general that integrations play a major role in that. However, no tool will make up for lack of governance structure and governance setup. The most important thing when you set up journey management is your governance structure. Who is responsible for what and how do you follow up on things that you identify?
And as long as it didn't crack that nut, the tooling and the integrations are secondary.
Governance and Journey Management
---
Daniele: That brings me to a very personal question, which is. Okay. How do I do that governance? What's, what are you've seen many of these journey management applied in companies. So you see what works, what doesn't work.
So are there like mistakes, that are the newcomers mistakes and that you see, okay, this is normal. You want to do this, but that doesn't work. And what are These these elements that you just learned with years of journey management and that you can basically say today.
Start with that. You don't get it maybe right now, but you will see in a few years, it's going to pay off.
Marc: I would never say that this is the right way to do or this is the wrong day, because I got proven so often that there are many ways to reach a goal. But a common mistake I see is to start too big and too fast.
Too big means involving too many people at once creating too many journeys in the beginning. And too fast means if you, so Let's do it one by one. If you involve too many people at once, if you set up a whole hierarchy at once with one or more high level maps, frameworks end to end journey, however you call the highest level that you have, and then one, two, three sub level, even I see companies who do five levels down and that is okay if you are set up for it, but most companies in the beginning are not.
So rather start small, start with a high level map and 1, 2, 3 sub level journeys, not more. Also reduce the amount of people who you involve in that, because the more people you involve, the more structure you need, the more politics comes into play. And First, you need to prove that it's working within your own organization, because people will always look at the big examples out there, how they are doing it, and they say it works there, but we are different.
And they're right? Every organization is different. So you need to prove that it's working within your own context, and only then you can scale it. It's not really a sales approach to to it. It is what is more sustainable. So the second thing is the pace you start with. What you want to do is what, how you want to use it is you want to identify what are pain points, what are unmet needs.
You want to you want to add research data to it. You want to get opportunities out of it. You want to use that data to make decision where you focus on, maybe connected to your triple track agile. So how does it relate to the backlog of research or to the backlog of design or to the backlog of dev ops, and then actually follow up on that.
And the problem is. If you start with too much pace, you're opening up the funnel. You're involving too many people. You're too fast. You're filling up the funnel with pain points and opportunities that you then don't have the capacity yet to follow up on. And after a year or so, it might result in frustration because people see we're maintaining this system, right?
We document a lot of stuff. We put a lot of stuff in, but we only see very few small changes. What is going on there? If you lower the pace and also lower the expectation there, start with a small team, build up the capacity to follow up on your opportunities and actually get stuff out of the door.
Because as I said earlier, Implementation, having an impact on the customers or employees. That is what we're aiming for. Not to have an amount of journeys or whatever. And once you can prove that, then you have a case to show. And then people start trusting it. Then you can scale it up while you're also scaling up the capacity to follow up.
So start small. Then scale and start slow and then increase the pace.
Daniele: We have one question, which I think relates quite well to just what we, we spoke about, which is from Pasi, which says.
Can an organization start with Journey Management?
---
Daniele: The following thing, which has, can companies who are getting started with service design go directly to journey management or journey management is more for companies that are already mature with service design. So what comes first, the egg or the chicken?
Marc: Yes, you can start with that.
If we have more time, tell you a story about that.
Daniele: Go on for it. I think, you're teasing it too well. You're teasing it, you're teasing it too
Marc: All right. All right. I think six or seven years ago, a company contacted us and and told us, Hey, we want to bring service design in, and we want to use your software to do that.
So journey mapping software to do that. And we said no, it doesn't work that way, right? You first need to know how service design works. And then once you like then it helps you to do your work faster and better and so on. But it's like you say, I want to use Microsoft Word to learn how to write a book.
The tool itself will not solve that for you. But I got proven wrong because what they've done is They made journey maps mandatory for every project and we set up a little training there. They told their teams journey mapping is important, thinking about custom experience and so on.
You need to do a journey map now for every project. And there is to make your life easier. We got a software in so you can do that simpler. And then there's a bit of training on the software. You're well set up for that. And that was easy for the team to, to say, okay, we're doing it.
We did a training. We told them what makes a good journey map. There are a few aspects. You also know some of them from our book from the doing book where they're in. And one aspect of it is that a journey map should always be based on research and not on assumptions. And then the This company called us after a few weeks and said, Hey, it worked.
So what's happened? The first team contacted us and said, look we created this journey map, but it's actually based on assumptions and we need research data. Can we please do research with customers? We would love to do some observations and interviews. Brilliant. I never thought of that.
So I was proven completely wrong until I learned that. I think it is the same thing happening now with journey management. Yes, you can start with that and use it as a trigger point to bring service design in. Awesome.
Future of Service Design students should be aware of
---
Daniele: I have a question from my mate Emmanuel for those who come often who asks, okay he has students learning service design.
So how will the service design profession evolve? Over the next years, do you have maybe one idea of how students can prepare themselves outside of AI? Because I think that's the usual answer. Outside of AI, do you have Something that students should prepare themselves for.
Marc: If you asked me 10 years ago, I probably said something like, in 10 years there won't be service design anymore, right?
And service design will be the new normal. We don't talk about it. We just do it. It's not true. It is normal now, but we're still doing it and still talking about it. I think it will be still the case in 10 years. But what we're seeing right now is on the one hand, a democratization of it. We see that it is part of curriculum, right?
Not only design schools, business schools are learning it. Architecture schools are teaching it. And even high schools, like I live in Austria, and service design is Part of the high school curriculum in Austria. So students at the age of 15, 16 learn service design in school already. I know of high schools in the US who are teaching it.
It's fantastic to see that. And yes, maybe it definitely will change how we're doing it. The. The processes, the activities, the tools, the methods, I hope in 10 years we don't talk about phases of service design anymore, because it's also one thing I absolutely hate. And I hope that in 10 years not the same stuff happened that we saw happening to the term design thinking, which got burned by many bad designers, where people blame bad facilitators or bad consultants on on actually a good thing.
It's hard to predict for 10 years. Gosh, I'm, I just hope it will. What I see is like more and more people are doing it. And maybe another trend I'm seeing is we see more and more specializations. So we see agencies who are focusing on specific industries. And a general trend we're seeing already since the last five, six years is it's getting more and more in house.
So it's a capacity you need to build in house and That's what we're seeing already.
Daniele: I can definitely relate to the in house and specialization. That's definitely one thing that I see a lot and hearing from this, if it's going to be something that is basic, it's going to be part of the basic education, it means that if you're studying it as something that you want to do as your job, then you need maybe to level up furthermore which is a good, which is a good push, to know that, oh the next generations, it will be just It might be basic stuff.
So we have to also step up and to step up. One of the best things is to practice just a lot, and I think that's for students. It's just maybe the best advice is just practice,
Marc: prActice. My best advice is always join a jam or host a jam. Yeah, the Global Service Jam as a nonprofit event.
Fantastic. Go for it. Run it an easy way to get experience. Absolutely.
Better terms for Journey Management
---
Daniele: I know you, you love to rant, but let's find the solutions to your rant. So there is this question from Bruno who asks, okay, there are terms that you don't like, but what are the opposite terms or what are good terms that you use instead?
What have you learned that works well, that doesn't make managers, feel threatened. by, by you or by what you're bringing. So how do you adapt these terms? Maybe do you have maybe two or three terms, maybe just for journey management that you use, depending on context that people could steal and test in their own
Marc: context?
So I. I always ask the client, the company what are the terms you use? And I adapt to whatever they use. And that's the same for service design. In some companies, it's called still, it's called design thinking. In others, it's called experience design, a term I hate even more, because you can't design an experience.
Design is always happening in your head. And you can only design a service. With the intent to create a certain experience, but if it's called like this, fair enough, I use it and I won't rant then if that's how they call it, right? Some call it also just UX design, but they don't limit themselves to the screen, right?
It's all fine as long as everyone knows what you're talking about within your organization. The same with with the word touchpoint. If you have a definition that is working and people know what you mean with that then it's cool to use. I avoid it by not using it at all. I talk about the steps of a journey, for example, and I combine it with different channels and so on.
I talk about impact and ownership, like which, which of these steps can do you own as an organization where you can have impact on. One of the common mistakes in journey mapping is if you. Map out a journey that only consists out of touch points, as if your customers don't have a life outside of being your customers, right?
So understanding what is really happening in between is not in between, it is the experience you should be mapping. So I use the terminology of of the organizations I work with. Synonyms for journey management, some call it, I like to call it journey map ops or journey map operations or journey operations.
It's rather lightweight and bringing it like as a the notion on you want to operationalize the journey and not only visualize it. Some call it the journey atlas or journey framework. So rather focusing on that thing, journey hierarchy and. Then you can add whatever verb you like what you do with it, whatever resonates in your organizations, really.
Daniele: One thing that I've learned from experience is this idea of when you come in a company, asking them, how do you call this? And then there's two tricks. One is asking people, how do you call this here? So that I use your language, which is a great sign of empathy, etc. But then giving three examples.
Okay. Oh, journey management. Do you call it journey management? Could you call it journey maps of operations or this? And just by saying that, if people know the terms, they will tell you this is a term we use, but if they don't use the term, you're already just helping them to understand there is different ways of saying it.
We can pick one that feels In your internal communication because often, terms have a history in organizations. I know some organizations where you are not allowed to say the word Agile, because if you say it, they will say, they will tell you, we had this one project, which was meant to be Agile, and blah, blah, blah, blah, blah, blah, blah.
And then it's, your project is lost. But if you just say, hey, we're going to go do it in a bit of a different way. Then it's it moves. It works. And some, and that's why I would just add that little recommendation. Ask people, and don't give just one word, but give several ones just to go out of that of that possible rant that could, people could have about one specific term when what you want to speak about is the principles and the ideas.
And
Marc: if I may add to this, also ask what they mean with it. Because very often people say they do something, but they actually don't. Like I have this one story in my head where someone told me, we do service design. I said, great, what do you do? Oh, we do it every Thursday. What does it mean? In the end it shows yes, every Thursday they meet, they put some stickies on the wall with ideas and they never follow up on that.
Yeah, that's not what we mean with that. So look beyond the term and look at what are they doing? What is the, what are the processes, the culture, the the way of working and so on.
Daniele: Yeah. And do the same for yourself. There's a. This thing that I've learned in the last few years to say when, whenever I use one of these, umbrella terms like strategy, prototyping, blah, blah, blah, I try to say, okay this is a strategy.
What I mean with that is in this context, this. Okay, now we have a bit of a common language.
Marc: I think for us as a community, it's important to have a term like service design, but what we use with externals within organizations. It's secondary, one is expert language and one is the language that we're using in reality with the organization. And I have to say as an, our expert language, I think the term journey management is settled, right?
Marc's next book: This is Journey Management
---
Marc: We're going to use it. And also my next book is called, This is Journey Management. I signed a contract for that two years ago and almost done with the manuscript. Yay. By the way, there is, since there was a question again. Yeah.
Daniele: You answered the question before I asked it. It's
Marc: awesome. You're welcome. Sorry.
Yes, that's perfect. That's perfect. . There's a website called this is Journey Management. If you donate, we follow the same process as we did with our previous books. You can sign up as a contributor to it. Next year we are going to invite folks like last time around a hundred people per chapter. You get early access to the chapter.
It's a Google Doc, and you can then contribute to it. And I can just tell you in the last book, in the Doing book, we had. Comments, threads that went over several pages of people fighting against each other on a very skilled level on what is the right way to phrase things. It's fantastic to see.
So I'm really looking forward to it. Not so much looking forward on curating all that input in them, but that's part of the game. So if you'd like to sign up, this is journey this is journeymanagement. com. Sign up for the book and looking forward to working with you next year.
Closing words
---
Daniele: Thank you so much for sharing all your knowledge. Once again, a big thank you to you, Marc. And I leave the closing word to you.
Marc: Just so I have to do some advertisement for the new book, cause I saw just many asking for the link. It is thisisjourneymanagement. com. And I just would like to thank everyone who participated and you, Daniele, cause.
We can only bring service design in so many hands, in so many minds, if folks like you are pushing it. So thank you so much for driving the community.
Thanks so much. Bye bye. Take care. Bye bye.
This webinar transcript was generated automatically, so it will contain errors and funny sentences.
Share your thoughts
0 RepliesPlease login to comment