 In this episode, you'll learn how you can transition from journey maps as a single-use artifacts to being the backbone of your customer experience strategy. Here's the guest for this episode. Let the show begin. Hi, I'm Florian. Welcome to the Service Design Show, episode 168. Hi, my name is Marc Fontijn, and welcome back to the Service Design Show. When our guest, Florian, former, told me that he and his team are successfully managing hundreds of journeys and even more innovation and improvement opportunities, I had a hard time believing him. Because from what I'm seeing, most organizations struggle to manage anything more than a handful of journeys. So can you really do journey management on such a large scale? Of course, we have to find out. In the conversation you're about to hear, Florian openly shares that they definitely didn't start out this way and that it took them a few years to get to this point. But today, rather than having to convince stakeholders that using journey maps will make their lives easier and help them to deliver more customer-centric services, people from the whole organization are knocking on his door to work with his team. So if you stick around till the end of this episode, you'll learn how you can build a solid repository of journey maps, even when you don't get that task or resources to do that. What the key criteria are for selecting the right journey management tool and how you need to tweak the service design process in order to reach 100 percent journey map coverage. I hope you're ready because now it's time to jump into the conversation with Florian Volmer. Welcome to the show Florian. Hello Mark, how's it going? It's going great. You've been on my invitation list for a long time. Multiple people have recommended you, including actually our previous guest, but it's just a coincidence because your name was on the list longer than that. Florian, I'm looking forward to this conversation. But as always, we'd love to start with a little bit more context about who you are. Please, could you shine a bit of light on what you do these days? Yeah, what do you do these days? What do I do these days? I do two things. I am the service design lead at NCR, a global technology company. We're about 30,000 people around the world, and I lead a team of really smart service designers within our experience design team and managing complexity on a daily basis there. Fascinating stuff. It's a company in transformation as well. I'm sure we'll talk more about that. And then I teach service design, brand and value creation over at Georgia Tech here in Atlanta, where I live currently, to some industrial design students and human-computer interaction students. Sounds like a busy, busy, busy life. It is, at least for me. Yeah, that's the most important thing. Florian, I don't know if you know, but we also have lightning round, five questions to get to know you as a person, next to the professional, a bit better. Just the first thing that comes to your mind, brief answers will not dive into these answers more deeply, just let's see what comes up. Are you ready? All right, I'm ready, yeah. All right, first question, Florian, is what is your favorite food? My favorite food is anything that involves cheese. Next question is, what was your very first job? My very first job was probably when I was around 16. Our neighbor walked over to our house and said, hey, I'm a photographer. Would you like to learn database programming for me? I need a program that helps me manage my photography practice. And I was like, sure, I can read two books. And then I built him a little mini business management system within, I think, maybe five or six months. I think it was. Hmm, cool. Is there a book that you can recommend to anyone to read? Right now in the state the world is in, I'm just rereading Donella H Meadow's thinking in systems. One of those classics, but a really, really important one for us to just keep it top of mind to just think about the impact we have as humans, as designers, and be careful with our planet. I can plus one on that book for sure. I read it first time last year and yeah, a classic. If you could work from anywhere in the world, which place would you like to be? Oh, I just had that conversation with my wife. And I think we would love to be down in New Zealand, just as far away from where we are as possible. Sit on a sit on a volcano, I guess. OK, who knows? Let's keep in touch and see where you are next year. And the fifth or final question is, do you recall your very first encounter with service design? Yeah, actually, actually I do. So I have sort of an interesting schooling history. I went started off in Birmingham in the UK, then then Berlin. And then I did a guest semester over at the Cologne International School of Design, where I met Birgit Mager in 2000. And service design was a really, really new thing there. Moritz was around at that time, too. And I had some really great conversations with those guys. And then I forgot about service design for a little while and then came back about 10 years later to it. Interesting. 2000. That's the early days. There are really early days of service design. But it's sometimes good to mention that, although it's still a new discipline, it's not like super, super new. People have been doing it for quite a while. Yeah. Oh, yeah. Oh, yeah, for sure. So, Florian, let's dive into today's topic. And I love the title, which you gave it is Service Design at Enterprise Scale Equals Journey Management. That's how you sort of pitched it to me. And I was like, sure, that sounds that sounds great. Now, we're going to talk about journey management, about service design and scale, topics that have crossed sort of the schedule or the agenda of the show more often. Really interested to hear your experience. But first of all, the first question I wrote down on my notes was, OK, so when we talk about service design at Enterprise Scale, how big are we talking about? So what do you mean with Enterprise Scale? How scope, scale? Yeah, for sure. Let me paint a picture of sort of my recent and current challenges. So. But in this role for about three years now and have grown this practice pretty significantly. And we started off doing what I'd call service design for UX. So service design for new product development, really focusing the creating journey artifacts or service and artifacts broader that would lead into a UX digital product development process. Mobile screens, stationary screens and everything in between. For the last year and a half, we've really expended that to also include EX, the employee experience. We've been working with our chief human resource officer directly to do some cultural work and do some employee experience work. And then most recently, really partnering with our CX function and looking at the end to end customer journeys, discovering NCR, buying from NCR, being onboarded to NCR and then being a customer and upgrading and so forth. End of life when that happens. So really having that dimension. So it's the CX, UX and EX that we navigate that triangle these days. And we NCR is a complex global company, like I said before, we have three lines of business, banking, retail and restaurant. And we are driving synergies between those three. So when you go to a grocery store, you don't really have that much of a different experience sometimes these days. And when you go in the restaurant, many have a hot bar, many have a little counter where you can get a coffee, that kind of thing. So we bring in these experiences together and we partner with these three lines of business, restaurant, retail and banking. And I checked on our platform. We have about 250 bigger journeys and nested journeys and not differentiating that with that in that number. And about 500 innovation opportunities that we manage and 500 capabilities slash solutions that are in the system as well to just give you some numbers. My direct team is relatively small. We are lean machine, the extended team, the matrix or whatever you want to call that the community of practice is large because we are believing in democratizing service design and partnering with people really from all functions. Sure. Yeah. Still a lot of unanswered questions, which which I'll ask you now. When you say you have 250 journeys and more sub journeys and 500 solutions that you manage, what does that mean? What do you manage? So that means that we are documenting current state that we are driving a series of workshops to define future state that we then go in and say, hey, where are the biggest innovation opportunities that really drive change in those experiences and what are current or future technology or otherwise capabilities that will make that happen that help us execute against that. We I'm in the process of carving more and more space out for our service designers to be just that designers to be innovators, to be thinking about the future three to five years out and saying, where do we want to go with all these different journeys and why and how to some degree and then partnering with other functional areas to see if they if they can't come on board with us to say, OK, we are helping you manage these journeys. We are connecting this to Jira issues. We're connecting these to other project management solutions to to drive daily progress against that. So another thing I'm curious about what you just said is you said we manage this. You do all these activities, thinking about future state. Can you shine a bit more light on who is we in this case? Yeah, absolutely. So my team, I really think of this as a team of service designers and I've been hard at work to say, OK, what do we need to do to bring the design back into service design? Having them really think about three to five years out into the future, use their interplay between abductive and deductive reasoning, use their systems, thinking approach and everything else to define those North Star future state journeys and then partner with other people in the business to come in as journey managers, project managers, whatever you want to call that to help us execute against those North Star journeys. Can I is it correct to sort of say that your team is like a staff function? So it's it's serving the rest of the organization. It's providing a service to other departments. Yeah, that's right. It's a core it's a core central team that's coaching, that's providing the platform, that's teaching, that's taking on key projects to define best practices. But then we're really interested in this before this notion of democratization and helping others to contribute just as much as service designers as we can, just because of the scale we face every day. That's the current situation. Now, let's rewind the tape and go back a few years. I'm assuming that you didn't start out with mapping 250 journeys. It's even amazing that you are that far. So can you sort of take us back to that moment? How did this all start and what was like the context back then? Yeah, absolutely. So I joined NCR five years ago in a very interesting role initially. So before that, I was a design entrepreneur, ran my own agency, pivoted to a service and agency, and then I came over to to enterprise to to continue my personal learning, learning journey, just to give you some background there. I came into NCR and as part of the sales function, actually, in these large international corporates, there is a thing called pre-sales. That is the technical side of the sales organization. And those are the people that have sort of what I'd call them was the design skills. They have the people skills. They have the technical understanding to say, OK, here's your need. Here's your customer experience that you want to drive. And here's our technology. How do we bring all these together? So we taught that group essentially services and light, some basics of journey mapping, some basics of design thinking, collaboration and so forth. And it was clear to me then, all right, we have so many journeys that we are creating with these different restaurants, with these different retailers, these different banks that are they are different for each bank, but they're also very similar. Right. So early on now, I started experimenting with actually air table and said, hey, can we have a situation where journey mapping joins database thinking and my standard banking journey is 90 percent the same for most of those banks out there. And then those 10 percent, you know, can modify those. So can I just simply click copy on that originating journey and have that being adopted to the next banking need to say with that example? It was really cool. It worked really well. I geeked out on the air table. The problem was that I geeked out on the air table and that my immediate team got it and understood how to work with it. But from a usability perspective, it wasn't really all that scalable. So for a few years, I was sort of on the hunt for a platform that would work well from an onboarding perspective that would enable me to do that journey management at scale without, you know, having somebody in training for three, four weeks. So that's the that's the initial journey. They are that air table database and it worked really well. As I said, I put like a little project management module to it. We had a central inventory of pain points and gain points and we were able to reuse different components of it. But again, I wasn't it wasn't scalable. So I sort of retrenched said, OK, what did we learn from this? What do we need to do to do things differently? And that's where we that those were the beginnings of where we landed today. Super interesting. Yeah, again, I'm going to try to summarize this in my own words. So it started out in sales and pre-sales. And I'm assuming that you were creating journeys back then to sort of lead clients through this process to uncover opportunities with them. And not to say to design or redesign their service, but to discover opportunities, right? That is that correct that that was like the context? Mostly, that's correct. And sometimes we got to redesign their experiences as well, just based on our expertise and working with an entire industry, essentially. Sure. But the journeys back then sort of served as a way to help you bring in more work and find new clients. And and you were creating these journeys anyway. Like there were a helpful tool in the sales process. And you figured like, let's make this more efficient because we're seeing patterns across multiple clients. And I'm not going to, quote unquote, waste my time redoing the same steps over and over again. So you decided I know a bit about Airtable. Let's see if I can put my work and journey maps into Airtable on them. When a new prospect or lead comes in, I'll just pull up the journey map and we'll start from there again, correct? That's correct with one addition. So post sales then in the pain points. OK, we're hearing the same pain point from this client, from this client, from this client, from this client. Shouldn't we be thinking about a new feature in the core product that solves these clients needs? So that's where we bridge the gap between sales and partnering with our clients to actually informing new product development. And that's how I ended up in the experiences I'm team. Yeah, so let's talk a bit about that because I think this is really interesting. And you almost use sales as a research tool, which I think is super, super smart. And you had all these journeys, maybe isolated to you and your team. Let's talk about the making the leap from. You, your team, to finding adoption and use within the wider organization. Because I think this is the space where most people, where we see the most casualties among professionals. How did that go? Like, can you talk us through the steps that you took to find broader adoption? Yeah, absolutely. Step number one was really stepping back from me and saying, OK, OK, where am I? What impact have I had in this pre-sales group? And yes, we've created all these journeys. Yes, we trained hundreds of pre-sales engineers in the foundations of design thinking around the world. Awesome. How do I grow my impact? What else should I be doing? So I looked, quite frankly, outside of NCR and within NCR. And I just talked with our design lead at the time and said, hey, you know what? I've done all this work. I think it makes sense for me to come over to the experience design group and sort of take what we've built over there and be a lot closer to new product development and at the same time move from sort of post-product development implementation upstream to actually more of the strategic bucket and informing new product. And at the time, she said, yeah, that makes sense. Let's do this. And I came over. This is about three years ago and a whole world of new challenges opened up. And I guess I got more than what I bargained for it to tell you the truth. And, you know, we started just porting some of those journeys over from these pre-sales days and then doing a lot of a lot of groundwork, doing a lot of sort of development of different journey formats, working on what we call a topography journey, a topology journey that has sort of software architecture next to a journey, a hybrid journey that has the customer experience path with some screens where I built in and a few variants that helped us actually inform UX work a lot more seamless, because really what we found speed was the name of the game. Nobody has time to take three, four, five months for, you know, a drawn out journey documentation process. It's it's it's a lot closer to sort of real time service design. And that's that's what we did. We sidestepped that catalog for a second. We worked in a number of different tools, whatever the situation required. So we I think the team was very, very resilient, very, very adaptive, not very pedantic, if you will, and just very practical. And at the same time, we never forgot about this notion of like we do in service design at scale and we want to drive reuse. We want to drive pattern recognition and we want to drive scale. So early on, we were doing things and in mural a little bit in mural in Excel spreadsheets and PowerPoints and I'm forgetting a few, but on the side, we built a consistent journey inventory just with having a database doesn't matter at table, but made that searchable and accessible for the enterprise. And that helped us stay connected. And then that all led pretty quickly to the first sort of marquee engagement, if you will, where the restaurant lead restaurant product lead came to us and said, hey, I'm new to the company. We have all these different restaurant products and they're great, but they have been product centric. Can you come in and partner with us to build a set of journeys that are depicting the different restaurant journeys persona centric, not product centric and saying, OK, what's the day in the rest? What's the day in the life of a restaurant manager? What's the month in a life of a regional manager? What's the shift beginning of of a greeter at a restaurant? What's the day of a server look like? What's the day of a line cook look like? And we did that work and that then informed, you know, iterations to the overall product strategy, a real time service design. I like that term. That's a really good one. We need to impress. Yeah, let's try it like. Yeah, yeah. Now it's so you're you're not being asked initially for journey mapping. You're being maybe asked to assist with other challenges. But as a byproduct, you sort of mapping journeys and saving them for later use. And then at some point, somebody walks in who actually has a challenge that is related to journey mapping and maps and you have already the inventory. Now, the crucial part here is most people even struggle to just work on the actual challenge. Where did your team find the time to even to also map these journeys? Because that's, I think, like, how do you do that? Yeah, it's it's it's a daily daily struggle. It's we have to remind ourselves to work proactive in a world proactively in a world that is responsive at best and reactive many times. And it's not always easy, Mark. So we just have a cadence where we say, OK, what else may we be able to do? Where what else is going on that smells like a journey where the journey may be helpful and can we cover out the time? Do we do we succeed 100 percent? No, but do we succeed more often than not? Yes, also, again, comes back to this notion of democratization and saying, OK, how can we partner with people and product, with people and professional services, engineering and show them the value of this approach and have them jump right into the platform and say, hey, this smells a lot like a journey. Would you be able to just take, you know, an hour to just document this along this timeline and will then take it from there? We do that quite a bit as well. And last thing I want to say is we had to get a lot more flexible in terms of the process. Traditionally, discovery, right? Doing the research and so forth. And then you do the journey. We've reverse engineered journeys quite a bit, too, where we've come into a situation where an entire feature backlog already exists in Jira line or Jira and the product team has prioritized it for the next half year or year. But we know it's coming at some point. So we just take that backlog and create a journey based off of that and then and then start the sort of validation research and additional discovery research as we as we go along and then come up to speed without, you know, having to take all that upfront time investment. Yeah, so maybe sometimes making assumption based maps, but that's OK, as long as you know that they are assumption based and having a starting point. I'm really curious about the chain of command here. So what is what is the brief your team has to actually work on this? What is I don't know, what are the KPIs? What are they? They're OKRs like because they are working essentially on quite indirect things when you map journey maps that aren't that people aren't directly using. Yeah, so I should also say that that is the that is the ad on work. There is a core a core set of projects that we are directly asked to like help with the project. And that's the bulk of the work. So those have the traditional KPIs of like, you know, do the two week sprints and, you know, whatever sees it through to the to the product and then customer satisfaction, NPS and so forth. The chain of by design, my team is sort of matrixed in to a lot of different organizations. And I just have regular meetings with product leads, with engineering leads, with PS leads and and see what their needs are. So it's a it's a bit more informal than you would expect at a global enterprise like that. But do they have does everybody have the task to map out journeys? Or is it something that happens intrinsically because people know that in the long term, this will be important or valuable? Yeah, so I've been I've been really successful in painting a vision of saying, OK, if we really want to be customer centric as an organization, we want to have 100 percent journey coverage of all of our products that are out there that we offer to the marketplace so that we can iterate in a meaningful way, listen to the marketplace of a meaningful way, have a home to contextualize quantitative and qualitative information and then prioritize future iterations of these products and services based on journeys. And somebody said, yes, 100 percent journey coverage, which I again, also a great term said, yeah, we think that this is valuable and important to do. Yeah. And I guess that's the sign of that I was looking for. And again, coining that term, like 100 percent journey coverage, I can totally sell that to a CEO. That sounds like it sounds like a very appealing sort of benefit to have. So great. OK. Does this hundreds of journeys that you have already in your inventory, keeping updated? I see that service design professionals are comfortable using this tool, know how to use it, see the benefits. Where does this fit into the workflow of everybody who isn't a service design professional? So how are you managing to get the rest of the organization to actually use this? It's a mixture of different vehicles, right? Sometimes an executive briefing may just have in look at the sort of macro high level journey. And here are top five innovation opportunities that you may want to be thinking about for next year and the following years. For a specific product manager, it may be diving into sort of more of the micro journeys and saying, OK, here are the dozen or so priorities that we think are here for the next year. What's really interesting is that I'll be the first to recognize that journeys can very quickly create cognitive overload, right? And I even go back to a journey that I may have created half a year ago. And I'm like, OK, what was I thinking? What is all of this? What were these comments? So we've also found with the platform that we're using, we also found a way to sometimes use the journey and sometimes not use the journey and just look at a matrix overview of the connected innovation opportunities and say, OK, here are the top five innovation opportunities. High impact, high effort, low effort, high impact. You still want to maybe prioritize there. Low impact, low effort, maybe don't do that. You know, you stand at two by two matrix and then a product lead may just interact with that sort of executive summary as well. And then with the more technical leads, we come back in and say, OK, so we have with our T group, with our software engineering group, we have conversations on the capabilities level and say, OK, we need to bring in single sign on. OK, don't have that. What do we need to do? What's that technical capability? OK, by the way, it shows up in 80 steps in 25 journeys. So must be an important capability to have kind of thing. And that's the interesting thing when you do this at scale and when you can sort of identify something like a technical capability, a single sign on. Hey, this is impacting a lot of journeys. What's the business impact? And that only happens when you actually have some mass and have some data and have done the research. So it is like the big challenge is that it creates mapping these journeys. That's the upfront investment that you sort of have to make and have to believe in that this is important. Somebody needs to have the same fate as well in that. Let's migrate the conversation for a second into the shiny object syndrome area. Let's talk about tools. So you started out with air table. It sounds like you actually, you said it yourself, you geeked out on air table and was able to do a lot. What did you stick with air table? Yeah, I mean, sorry, one question. Some people I'm aware might have no clue what air table is. Maybe you can give a bit of context on that first. Yes, yes, absolutely. So remember the story when I, when my neighbor came over and said, can you build me a database for my photography studio? So that back then was in a database that's actually made by Apple FileMaker Pro. And for years, I did some basic database programming in that. So it's a relational database. You have a couple of tables. You connect them. You can build catalogs and so forth. And air table is a modern web based version of that, essentially. So it's a relational database on the surface. It may look like an Excel, but you can do a lot more. You can connect your inventory with your addresses, with your pricing catalog and create these many to many relationships. You change something here. It has this ripple effect through the entire system. That's maybe the shortest way I can say this. I've been interacting with the air table since their early days. They've come a long way as well. And the power there is that it's all very customizable and that they're bought in scripting and so forth and that you can essentially build exactly what you need. And I think there was probably almost like also the downfall because just because we could build it, we started building it. And it wasn't as visual as we needed it to be. It didn't behave like your typical program or web based app that somebody may be used to. It was sort of, you needed to have a database mind to interact with it. And what we found is that our internal onboarding to the tool was just, people took them a long time to understand it. And then it was too hard for them to actually keep a top of mind to stay with it. So that was essentially it. So there's a philosophy here. If I want my service design team to just be irreplaceable 100% and if I want everything to funnel through us, I can make that a good thing, right? I can make us all the experts and everything has to come through my team and I can probably hire a few more people just to interact with the database. But I don't subscribe to that philosophy necessarily. I subscribe to philosophy of doing the right thing and doing it in a lean way and in a scalable way. So we retrenched from that. I did a big scan of the market maybe three, four years ago. And what I found then was essentially mostly still on a normal insult anybody but mostly glorified journey mapping tools still that would do journey mapping really well. But it was just that. It was a singular map that was just there then in the system. It looked good. You could print it, but it lacked the management side of things. And then on the other side, there's this entire world of products that are really journey automation, right? Logic-driven marketing automation. Like if the customer does this, send them that email, send them that text message, blah, blah, blah. And what I found was essentially a gap in the middle there between journey mapping in the traditional sense and journey automation in that more marketing-driven sense. And that's what I call today with a high level of confidence, journey management tools. And we landed on a platform that made sense for us. It's a relatively young successful startup. There are a handful of solutions out there. I think it's a category that's being created as we speak. I did some research earlier this year on it and published something over at DMI Academic in Toronto. I'm just speaking with experts in the field and saying, okay, what are the terms between journey ops, journey orchestration, journey management? What may stick here? And it seems like journey management is the most robust term for this and most successful term for this. So we have our platform and we're happy with it. With regards to introducing new platforms, there's always that, oh, here's another tool or platform, software solution, fatigue. Have you experienced anything like this internally that people see another tool coming on and are sort of hesitant to start adopting that as well? Yeah, it's always something. One of our design ops guys is joking about a few years ago we were, the experience design team was in there, what did we call it? A TRE, a tool rich environment because it seemed to be somebody wanting to buy a new tool at every turn. And he was the one tasked with the procurement and everything. So we went through a phase of consolidation and all the UX tools consolidated of infigma and so forth. So it wasn't that environment that I pushed the other way and said, hey, we need this dedicated tool and it made so much sense for people that I got it through the system. And I'm assuming that this tool is also being used outside of your team, that that's the whole purpose. That's the whole purpose, yeah. And we have 40 licenses right now where it may be project-based where we give a few licenses to people that come into a project and that's a roll-off. They all disable those licenses and we have a number of permanent collaborators as well. Okay, great. Now, this sounds again amazing that you're doing it on this scale, that people are using it, that you've sort of found and that it's become, it feels like it becomes a pull request from the organization rather than you having to sort of push it on to people to start using maps. Like the evangelizing, maybe you're still there but it's, I feel that in your story, it's shifting. It's translating, people are finding you rather than you having to convince everybody to use maps and journeys. Yeah, it's amazing. I don't know what the timing is exactly but the Q3, Q4 of last year is when we got finally over that hump. I'm saying, okay, it used to be like a half hour conversation until people got it. I can now just do a five minute summary and like, yes, this makes so much sense. How do I get to collaborate with you? Okay, what was the tipping point? Can you now, in retrospect, looking back on this, what changed like in the Q3, Q4, except that you probably had been evangelizing for the last five years? Yeah, I think in short, it's our ability to really profoundly stop talking about it and just taking people into it. And not a PowerPoint slide or keynote slide and not a description of a process, not a high level summary, but say, okay, one setup slide, let me take you into the tool and let me show you how this journey connects to this journey, how this journey connects to five opportunities or 15 opportunities and how these opportunities then connect to all these capabilities and solutions. This is how you can work with it. Wouldn't that be amazing? And that's sort of, I think about this a lot when we teach design thinking like, okay, prototyping, right? Prototyping is not present at presentation. Prototyping is something where you take somebody through the experience so they can really experience it. So in some ways, we've been prototyping this process and now we're at that point where we can just bring people on quickly and easily. Oh, what's the thing when you guide them through this process, maybe even let them do it? When do you see that spark in their eyes when they go like, yeah, I need this? The spark is really when we just remind them about the complexity of the task and how there is very few other methods, frameworks, tools that allow us to sort of a, simplify the customer experience and stay focused on the customer experience but then also layer on that systems thinking and that simplifying of that immense complexity that we have behind the scenes. And then like, okay, if we have, say hypothetically three to five tools across the enterprise that do essentially the same thing. If we can show that across a number of different journey maps and if we can then make a recommendation this is the best in class tool. So what do we need to do to roll off those four that are essentially just a cost center then it makes economic sense as well, very quickly. Yeah, so a simplifying complexity and especially within large scale organizations where there are so many systems, processes, structures, people, divisions, silos, it's impossible to see it all in your head but when you have something that you can help to visualize that. And I guess people start to see how it's going to make one, their lives easier, how they can achieve their goals faster and how they probably will be able to do a better job and achieve the goals that they wanna achieve. That's what I would assume. Yeah, and how this is not an additional thing that we ask them to do but how it actually can fit into their workflows and how at the end of the day can actually save them time and effort down the line. Yeah, so that's a really good point that you bring on here because that's what you hear a lot also. Like what's stopping the adoption and use of journeys is people feel that it's another burden, another administrative task for them and it doesn't sound like that's happening over you at least not anymore. At least not anymore when we really stay with it. Of all the journeys that we have, I will not say that every single one of them is 100% up to date all the time, right? I don't wanna mislead anybody but I think you spoke about this three or four years ago where you used that analogy of a business spreadsheet and where it's like, okay, nobody in their right mind creates a business forecasting spreadsheet or business management spreadsheet and creates it and then looks at it a year later, right? And we had that a lot happening with journeys in the past as well. So that's the other part of that value proposition is like, this is an ongoing weekly, monthly management tool that helps you stay with it. I literally had one of the internal stakeholders that, you know, he sponsored an engagement with an external service and agency. Great, they created a set of beautiful personas, beautiful journeys and half a year later he comes to me and said, Florian, I have all these journeys and I love them. I just don't know what to do with them. I'm like, okay, yeah, we can help. We can turn them into actual business management artifacts. Yeah, I can, I love that term. You've been using a lot of good terms from people. Please make notes throughout. Listen to this episode again and make notes business management artifacts because if you're in a business, that's what you need. You need things that help you to drive decision making, that help you to make smarter decisions, faster, better, cheaper and journeys are just that. There are means to an end rather than the end itself. Of course, we've been repeating this for many, many years and it's easy to say but we've seen that in practice it's really hard to get away from the journey as an art piece and go into a journey as a decision making to a business management and management artifact, yeah, absolutely. One other question I have for you is with the experience that you have now, let's imagine you transition to a new company and you can sort of start this journey all over again. What are the most important lessons that you're going to take with you or if you sort of could start over again? That mindset, what would you do differently maybe? I think I would probably take a little bit more time upfront truly looking at every single aspect of the landscape. We just, we dove right into a few specific projects and staying and observing and analyzing a little bit more at the beginning would have been probably additional time spent without showing actionable artifacts but then we would have been able to engage quicker with the right stakeholders and the right projects is one of the learnings. I continuously underestimate to this day how much time it actually takes to pull off a workshop, to pull off a true detailed journey documentation and then the ongoing management work. So being more, I think I'm now being more realistic with time estimates, both from an overall duration and also from the effort that it takes from the team to do so. And I think we've done a pretty good job building a community of practice. The big thing that I find that we continue to struggle with to be honest is sort of this notion of coaching and saying, okay, we train you in fundamentals of design thinking and journey management. Everybody feels good about it. We've done this with hundreds of people, fantastic. And then that moment where we set people free and say, hey, do your own workshop, build your own first journey. Sort of this notion of an agile coach for service design is something that I'm still looking to fill on my team actually. I wanna go back to the first thing you said about taking more time to maybe find the right projects or can you elaborate a bit more on that? Like what did you rush and what would you like to have done maybe more thoroughly? Yeah, so I mentioned earlier this project for the entire restaurant portfolio. We pulled that off within three or four months and it was a crazy load with dozen, dozen, dozen stakeholders, all these rough journeys that we created and then refining them and briefings and interactions. I think in that example, it would have been better to just focus on one or two experiences, build them all the way through and say, okay, here's the restaurant managers, day in the life, week in the life, month in the life. Okay, here the resulting innovation opportunities, here the resulting capabilities that we need and see that through end to end as one journey, show that to all stakeholders and then go on to the other journeys. What we did is we did all these journeys in parallel and whatever course correction we had to do, we did because we didn't get everything right, nobody gets everything right at first, but then we had to do it for a dozen of journeys and not just one or two journeys. And what kind of difference would that have made if you focused on one or two and do them end to end more thoroughly? I think we would have gotten adoption of the framework faster because they would have seen the so what earlier and simpler. That's a good learning, I guess. Now, as we're sort of heading towards the end of our conversation, I'm curious, what's next? What's next? So I focused a lot on sustainability and circular economy through the year from a learning perspective, but we have some really interesting approaches to say, hey, journey management meets sustainability. I believe there is a, observe, not believe, observe there's a big gap between what a company will put out as a net zero goal and empowering individuals or mid-level managers to do something about it. In some areas, it's really obvious and really simple and some other areas, it's very opaque. And I believe we can do a lot through the power of journey management, giving individuals a specific catalog of interventions that they may consider to green their experiences. Fascinating. I've seen that, I'm seeing this as well, so sort of slowly creeping up. Maybe it's beyond a weak signal, it's becoming a stronger and stronger signal and there is more and more appetite. So, yeah, super interesting to see how journey management will play a role, well, yeah, will play a role there. Maybe a sort of pre-final question is, what is keeping you up at night around this topic? What are some questions that you still have on your mind that you wanna figure out and maybe get some help from the community with? So what keeps me up? One, the ongoing management of it is easier set than done to have the right people to partner with that, have that sort of mindset of coming back to something on a very regular basis. I think a lot about the implication set AI is having on our practice right now, both from an analysis perspective as well as an automation perspective. And last but not least, it's, I think a lot about the dance that service designers have to go through, that dance of, one, we are appreciated for our deductive systems thinking, the very analytical thinking. And on the other side, many of us see our highest best self when we are allowed to be really creative and in the zone. And just recognizing that those are two different parts of the brain and quite honestly creating some space for myself to dance those two different dances and create some space for my team to have those moments of true psychological safety where the systems aspects of politics and everything else just suspended for a little bit and we can purely think about what should be and then come back and say, okay, I don't know literally how did we get there. So that dance and just being mindful and maybe a little forgiving with ourselves as well that that is not an easy thing to pull off for anybody in this world. And we as service designers are actually asked to behave like that on a very regular basis, I believe. Yeah, very good point. Very, very, very good point. The service design dance, again. If somebody is on Twitter, they can get a lot of one-liners out of this conversation and you're absolutely right. I was over the weekend, I was sort of recalling again that innovation is inherently inefficient and when you wanna innovate and wanna do that within an organization which is focused on scale, growth and efficiency, then you're going to have a hard time. So that's, I think, related to what you are saying, like on the one hand, the analytical thinking being efficient and sort of finding the solution but you also wanna be messy, inefficient, like that's you have to be. Cool, and that's a very, very interesting question to Ponder upon for sure. Now, we've covered a lot of ground, Florian. Let's sort of summarize with this final thing and that is if somebody made it all the way to this moment in the conversation, what are your hope is one thing they will take away? The one thing to take away, there's so many things that go through my mind so it's a little difficult of a question but I think there's beauty in simplifying the complex and it goes back to this other part of the dance, right? I find it fascinating to dive into a deeper conversation with the software architect and understand all the nuances that are needed to then just create that one little simple element in the journey. There's beauty in empowering others. I cannot think of a more rewarding time in terms of in my practice, when we wrap up one of those training workshops and people just have these glowing eyes and like what do we accomplish in three, four days in terms of just getting a taste of the journey and then have them be empowered to be true collaborators. And the discipline over time. Now it was three things, but I'm hoping that the discipline of managing things over time. So the journey of journey management itself, thinking about this at a meta level and thinking about how and when these journeys show up with other stakeholders would be the last aspect of this. Really interesting. Will it be difficult for me to find a good title that captures all the things we've discussed so far but yeah, no, I'd rather have too many options than too little so it was great Florian. I know we could have talked for another hour for sure. I think I haven't even covered half of the questions I had on my notes, but who knows, maybe we'll do a sequel in some time. For now, thanks so much for coming on, sharing openly your journey and where you are today, how you've come here, where you wanna go. I've learned a lot and I've found it a very fun and interesting conversation. Thank you, yeah, likewise, love being with you. I'm really inspired by Florian's journey and I'm really curious to see where they will be in a year time. If you were able to find a nugget of wisdom in this episode, make sure to leave a comment and let us know what it was. My name is Marc Fontaine and I wanna thank you for tuning in to The Serbs Design Show and I'll see you in the next video.