Can you tell the story of your product value? Simon Wardley’s Value Chain Mapping can help.

Dave: Hey everyone. This episode, I talked to Aidan Molloy, I’m talking to him about Simon Wardley’s value chain mapping. It’s a technique to identify the way forward for your product service company. Which, first as with most things, helps you identify truly where you are, and then figure out where it is explicitly, you’re trying to get to.

The thing about this episode is that we are discussing a tool that is very visual in nature. So I would suggest before you listen to this episode, you may look in the show notes and review some of the sites. Now, I wouldn’t spend a lot of time on it, but just so that you can see exactly what it is we’re talking about and what it might look like. I know myself, I would be extremely distracted, just trying to hear a somewhat complex visual tool is described by the two of us.

So, in fact, I’ll actually put an explicit link for showing you exactly what it is that we’re talking about. And in that way, you can just look at that specific link, and then come back and enjoy the episode. or potentially look while you listen. So yeah, that’s a really will be useful to view that before listening. But it’s still a good episode. And it’s a really interesting journey of how Aidan went through and created the value chain map for his team and their work. So, enjoy.

Intro Music

Dave: Hello, and welcome to the podcast. I’m your host a Dave Albert. In the show, I talked about technology, building a company as a CTO and co-founder and have guests to discuss their roles in technology and entrepreneurship.

Today, we’re joined by Aidan Molloy, a senior product manager at Workday. We’ll be talking about the Simon Wardley value chain mapping. Thanks for joining us Aidan.

Aidan: Hey, it’s nice to be here.

Dave: Awesome. Can you tell us a little bit about yourself?

Aidan: Yeah. So, I’m currently a senior product manager from the platform and infrastructure team in Workday. Actually, it’s I think it’s my second year anniversary next week. Yeah. So yeah, time flies in here. So, you know, it is one of the best places to work. So we’re all having fun. But yeah, I guess we’re here to talk about the kind of value chain mapping from Simon Wardley I have a huge interest in it. Yeah, and, you know, feel free to ask questions.

Dave: I guess, probably the best thing would be to start with, since we don’t have any visual aids on an auditory audio podcast, then maybe just describe what it is. And then I’ll act like I don’t know anything about it. I did read your article twice and did research, but I’m going to talk to you on behalf of the audience. So that’s my code for I know, I’m going to sound like an idiot.

Aidan: That’s fine, it’s going to be the two of us. Okay, I’ll start with when I joined Workday, I joined as a product manager for components called grid. So but I find that I think people sometimes underestimate, you know, moving job from so I was previously in telecommunications, where that would be quite a different, but they kind of had similar infrastructure challenges, like, everyone was talking about OpenStack, Kubernetes, you know, where the, where the industry was going.

But from our product manager point of view to come into a different, like technology stack. So you coming from telecommunications was background, and you know, into a kind of Workday doors, which is kind of financial, and you know, your p-type solutions, you needed to kind of understand quickly how the product got to where it is today, and where they wanted to go in the future. So, I was curious to learn, like what would be the best way to learn about the product’s history.

Now, one of the principal developers on the team, him was talking he goes, “Hey, have you heard about this guy Simon Wardley? You know, he’s talking some lot of sense.” So, Simon has a, so he pointed me to this kind of like a Google Talk from Simon called Crossing the river by feeling the stones. And so, I sat down and watch that. It was actually an eye-opening. So what Simon is trying to say is, you know, you need like the term map like it was ironic as a product manager, you redefine roadmaps yet they’re not a map, right?

So, when Simon was saying, you know, he looks at I thought his best thing was, he gives an example of a Greek, you know, domestically, he was wondering, should he? You know, how better would you try and win the battle? Would it be with a map pro to be with a SWAT diagram? And I think that when it comes to business, you need to understand the landscape of where your product sits against the competitors. And I found out that that was the kind of thinking that should be around like a kind of a, it’s an art of war, really trying to have that you’d need a map to kind of outline your landscape and where you need to go.

So, what I did here was that we sat down with the team, and we outline you know, what decisions were made back then. So, in the blog we talked about the developers really cool too, we want to get the idea as quickly as possible makes it really easy. But not, you know, not everyone’s a developer at this business decision you made and customers had a risk-averse nature. And that’s completely like that was not just like, that was every industry, right? There was always, Oh, that one story about this adage. And we’re not going there. That’s crazy. Yet, you know, everyone’s own data centre was always, you know, falling over and they just never thought about it.

So I find that was very interesting. So yeah, we were able to plot out. Now, you know, I took Simon’s mapping as a kind of, like, you’re a, you know, you’re able to do what you want with it because it will my personal belief is around getting the discussion started about where people think the product is in their life cycle. Like so the map itself, right? So has two axes. Yeah. X and Y put up, on the x-axis you have the value to the customer, right, the customer need and how, how visible is to them. So if you’re doing a website, you know that the landing page is probably most visible to the customer, then you need to think about the maturity of that product, right? So if you are building, so you know, the good old days of like a customer building into each customer data centre and they all have little variations, and they’re all custom built. And long term, that’s kind of not the same. So you can see, and when Simon talks about the kind of modelling he shows why cloud makes a lot of sense.

It takes away all the pain of like those long upgrade stories that we’ve had from different vendors. And that everyone kind of gets onto the same person, I thought that was, you know, it’s very good and Simon goes true, shows you why now I know he’s a big fan of the server list. Let’s probably discuss that for another day. I just thought I just find I really like when you see a map in action, you see, when you map out the different components that you believe are in your product. And, you know, get the team talking about like, one thing that I found was that the team at different viewpoints, but where they taught certain to grow at a certain age of a product was so I thought that was good to flesh that out and get alignment on the team as well. So

Dave: To a really interesting way to get into it. Yeah, so to kind of give an image for the listeners of what the map looks like. Now, of course, I’ll add in links to the blog post and a few other resources for listeners in the show notes. But as they’re listening now..

Aidan: Well like, you know, you can picture any map like a map has an anchor, you know, for example, which way is north, right? You know, and which way you need to get to so you kind of, you know, a lot of people in business and strategy, aren’t thinking about where they’re going to kind of, I think there was some statistic around like 67% of businesses just copy what other businesses are doing fine. You know, that’s, you know, everyone’s doing the same thing.

And I find that really interesting, you need to put like, I think Simon said about that a lot of people are playing chess, but the dominoes are on a chessboard. It’s, I’m hoping to do credit for this kind of paraphrasing, but I think he’s right, though. Like, there’s a lot of companies that need to, you know, sit down and see where they are not just in terms of the product they deliver, but in terms of the actual overall business landscape that they’re in. Like, where, where they want to end up in or challenges are in the way so like, you know, a lot of companies that would be moving ironically, like listen, for example, you could see that moving to the cloud, and, you know, solves a lot of challenges, because it removes in the map, you’re getting, you know, compute and power, and all the other things, you know, as a commodity, right. So in the maturity model, you literally their commodities, and you should only try and buy as much commodity as possible because building custom solutions, causes you a lot of longer-term pains and it’s not a solution to it. So, yeah, I’ve lost track of.

Dave: Yeah, sorry. So to give an idea of the, I guess that the vertical index

Aidan: Yeah, the vertical is really around the visibility and the value to that customer. Right. So what the customer wants? The interaction points? And actually, what, who is the customer like what, you know, it’s kind of ironic, when you’re building a product, you’re like, who actually use it, you know, when you deliver a pack and product into a support team, but you don’t think that they’re the customer? You know, it’s like, Who’s going to day to day, using this product. And that was kind of one for me to think best. When we were designing the map, like who, like what, you know, we talked about, there’s like an integration platform.

But I don’t necessarily see the end customer, I see the teams that deploy on the platform. And that was kind of where we had to focus. What are their needs? And what value like, what do they see they only see the integration platform, we don’t see the underlying infrastructure that we provide, so that, you know, that had less value. And, and it was kind of less mature like you can see on the map. And, you know, like storage, for example, like, can customer didn’t really care about storage, they just care about when I wrote about an integration it will run. In x time, that’s the kind of value you deliver that’s an SLA, that’s really, what you want to show your customers to the storage, like, you know, using the power and connect completely, those things are way off. So you shouldn’t spend time trying to reinvent, like, this is a great example about. And you’re opening up a coffee shop, right? Do you want to sell toast? Should you build a toaster? You know, and some people have tried to do that, you know, don’t go down that kind of model. And that’s when you kind of have to think about who’s your customer? And what are you trying to deliver? And how are you gonna get there quickly? Myself, that’s a great example show. Like,

Dave: That makes a lot of sense. Yeah. And then so across the horizontal axis, you start on the left-hand side with Genesis, then custom-built product and commodity.

Aidan: Yes so you know, I think everyone’s first product is in Genesis, right? As your first customer, you kind of grow over time. And you kind of see where it is in like, for example, there was a time when, like, you think back to computing, there was like, everyone could build their own computer. And now you kind of reserved instances and AWS, like, you know, it is a commodity now that that’s kind of that’s where it is on that kind of maturity model. But you think like the 80s and 70s. Even for us, you know, when stuff breaks, you have to go fix it yourself, it’s very specific to your problem. And now you kind of see that it’s no longer your problem is still a problem, but it’s much less of a problem. And that’s kind of where in the maturity level of say computing that will kind of display on the map.

Dave: It’s unlikely the majority of the people who are in the, quote, DevOps world are ever using a soldering iron.

Aidan: Exactly. Yeah, and it would like it’s like, it’s, it’s funny, you mentioned DevOps because you can see from the map that that’s a move to kind of cloud, like full cloud, and even several us has spawned that kind of DevOps model. So like, it’s really around, how quickly can I get my server back and running, right. And you can see, like, 20 30 years ago, when a server broke, you had to ring someone in mortar server, it takes weeks now we’re down to like, second, so nice to have. That’s why you need a different type of model to run your business. And I think that’s where it’s like, you can see how that DevOps model came about from that. So that’s another interesting thing about how the tooling has changed. And that’s making us a different level of how we work. And, you know, I find that really interesting.

Dave: You mentioned when you were going through, right, building your own map, that you had different members of the team involved. who wasn’t involved necessarily, that you think could have been much more valuable? So like how, how high through the long day? I’m losing words, the people who care about things, stakeholders.

Aidan: Yeah stakeholders will like to think that my exercises, really, I wanted to know, that the kind, First of all, I wanted to map right, so that was, I felt that the product I was managing at the time was kind of a nice one too because it’s been there since I started Workday like, how does it what challenge like every product has kind of very difficult challenges before they kind of scale. And I found that was really interesting to find out. So we when we talk to stakeholders, I literally, the grid was is a platform, right? So it, it literally has a platform full of API’s that service teams can call to run the integration. So integration is, you know, a job that runs on a computation will create, in a certain sense, so and so like, we knew that was fairly well mature but I was like so we knew we have a set of API’s. But there was a time when we needed to figure out like, say, I think 2010 like how, like the first customers getting on ahead, we solidify the AP. How do we make so that was much more custom? Right, so we’re getting the customers on-boarded?

How do I move me, like solidify the platform and the API? So that becomes much more of a product offering? So once you get into that phase, I don’t like then the scale starts happening, because you don’t need to be focusing on each individual customer. You know, like, like, Amazon isn’t, you know, I keep mentioning Amazon, but like, their, their prime example of like, they have a massive cloud computing platform. It’s, you know, it scales because they don’t have custom they have we are, it’s one size fits all for everyone. In terms of the varying, CPU’s. But the, you know, the same process for everyone. And that’s why, once you got to that phase, we could see large amounts of scaling involved. And that kind of scaling then brought in different challenges, right. So you know, different types of use cases appeared on the platform. And you can see that it’s like any big cloud provider as well, they provide a platform you see in these all-new business types come out of, you know, this business that room completely unlike Salesforce or Amazon. And that was the same with the grade, you can see different types of use cases that appear based on different needs, right? So you could like tweak, even tweak the platform for running, say payroll, or similar a small integration. So that’s kind of where we’re at. So yeah.

Dave: So maybe a good way to ask the question. Let’s say you’re going to come to hang out with me and my company for what a week, would you think? I think that’s how long it would take like if you were to come in fresh? A week, two weeks?

Aidan: So we did it over to like, do a mapping exercise? Oh, yeah. Look, we, I think today, like two to three days, like, okay, like, so I went to Simon’s map company in Denver, last year. And like, if really, it was just, it was just really good. Like, it was like a really small conference, but it was two days, it was like, it was one day, actually a single day. And the explains mapping in the morning, the afternoon is like a session where we went through kind of a use case example. And just made me think about, you know, going through it, like the best thing, if you had your team in the room, and figure out what exactly you’re offering to your customers. Where do you think that is? And can it scale? Right?

So I don’t think you should, I don’t think you take a week, but you can definitely take one to two days. Okay. It’s really around once you have that starting points of like, where are we in this space? And there are different types of maps as well, right? So like, you’re mapping your individual components within your product. So like your reason that my SQL database, we’re using whatever, or you can map out where your business fits inside the kind of competitive landscape, like who your competitors are, you know, what did they offer their user? How do I differentiate myself around that? So try and just mapping that out, I think is a win for any company.

Dave: Okay, and so you just start first, by listing out the different areas that, that you provide the value to your customers?

Aidan: Yeah. Like, it’s, like a general you should ask yourself, like, what, what do I provide my customer? What does my customer see? So what I found funny was that, like, developer, a development team would developer, develop a feature for your product, but they would never know how it’s being used. Like, and you think that features really important, but when you actually go out in the world, and see, no, one’s easy. You know, and I, and that’s why a lot of people talk about this, like, you know, don’t be building features because I was like, no features is like find out what your customer or your user needs are and go after that. Because, yeah, I mean, that’s what we really should boil down to around the anchor of what you customer needs.

Dave: Okay, did you have any missteps? While you were trying to define that yourself?

Aidan: We did. Yeah, I guess, it was really around, like, defining who our customer was. So you know, we kind of had different teams, but like, with customers from the start, but like, so most people forget that, you know, supports organization, they’re your customer, like you’re building, we have a platform for various teams put like, we need to support this like people need to sports platform, but can you make a much more usable, supportable platform for your environment operations teams, like, you know, if that was kind of one for me? Besides, they’re also your customer, like, know, whatever it takes for them, you know, you deliver a piece of software and everyone’s happy with like when you go home, there’s a 24/7 team that has to make sure, that stays up.

Yeah, you know, you need to talk to them and say, Hey, like, how can we make their lives easier, and you should consider them a customer? So like, on our kind of mapping journey, we had to think about them, you know, like, what, what did we deliver it to make their lives easier? And that’s really kind of, it was kind of an interesting, you know, I remember one developer saying, like he never actually taught of, you just sort of support to support the didn’t think of support as like a customer for what we’re delivering. And once we changed, we just talked about it and that mindset, it made us a lot more, you know, like I always said, like, we don’t want to be our first name terms with support, that’s a good thing. And they will like, like us more for if we have that approach to delivering software. So.

And, yeah, the mapping was one thing I found, there was one mapping, we were doing around, like, say, for example, as any as us a company versus a traditional premise company, and why people move to the cloud, right? And we were like, we had a kind of brainstorming session, and you think it’s because of the cost? Or you think it’s because of something else? Like they don’t want to buy hardware? It’s actually, we found out that it was like, maybe it’s the upgrade process, right? Yeah, maybe customers, the whole entire upgrade passes, due to the fact that everyone has custom software. That’s why like, going to the cloud sounds cool, but actually makes a lot of sense.

You know, and you map it out and go, Oh, I customer, I don’t have to upgrades any more. Like, you know, it’s not like a huge sales engagement where they come one side. And they’re like, Hey, you know, there’s a big contract, you know, because the longer that software stays on-premise, the longer it diverges from the other side. Yes. Yeah. Yeah, I found that was revealing. I was like, like, you kind of make sense when you think about it. But when you draw, like, the fact that we had to think about it, I think that was the win right. So we, I was glad for mapping in that way able to see just how, you know, customers are thinking about it. It was kind of I thought was interesting.

Dave: Have you helped any other teams within Workday? On the same process.

Aidan: Yeah, so it’s funny, we like when we published one, I published the blog, we had a little like mini road-show inside Workday, like, I found it very strange that everyone that kind of heard of it, but not really dwell too much into us. And I think that was a case of like, you know, people had an interest in it. But sometimes people just don’t have the time. I just think there’s a real value for customer-facing teams. And like, even the take the grid, like just finding out what I was trying to look, here’s, for example, right? We went down, some people were like, why are people using Kubernetes? Or why are people moving to the cloud, you could see that if you drew a map and show, you know, Kubernetes allows us to deploy on any kind of cloud infrastructure obstruction layer?

And once you could kind of draw that up there and show a this makes a lot of sense. You know, I think. So we’ve done a lot of Yeah, kind of mini road-shows showing, we are showing those examples about why it’s important to map out your products, both internal and external, its good, excellent routine as well. Like, it’s just really something to really consider, because I think strategy sometimes last on, you know, on teams, they don’t know you to always ask yourself, why you’re building that feature or product to show on a map at a point where that product fits. And I think that’s really good for like, junior developers all the way up to like VP’s to know why you’re doing something. So, yeah, and why you know, why you chose different technologies.

Dave: So this was posted back in April. So I guess we were working on it in February, March.

Aidan: Yeah. Yeah, February, March, I, there was an asked to do a blog post. And I usually put my hand up first, I can write about something. And came to pass that I was like, I really want to write about the, you know, how we use the Wardley mapping. And I just find that just to show like that people are like, it’s incredible how it’s taken off. I think Simon is quite humbled by it all. Yeah, like starting in February. It was really it was just good. Like I said, Hey, doing this kind of blog on how we map things might not be correct, right. It’s very scary when you’re doing your own blog, but it’s your own blog from the corporate blog it’s a bit different. So a lot of people were happy with the direction we were taking, I was a big fan of making, you know, like, it’s a credit to the grid team that built it. Excellent product for the last 10 years, I think, like to just get to get to the scale of what today like that, that that doesn’t come cheap or easy.

And trying to show that, I have you made the right decisions overtime and how, you know, you can see that we’re focusing on Kubernetes. Now, and I’m, I’m hopeful that that’s the right choice? I think it is. So yeah, it just it was good to like eight weeks, where we just read making words on paper, really, and getting the maps to a certain like, certainly read, like, for me, it was like telling a story. Like I want the reader to go. Okay, I understand, like, I wanted to let our product managers like, Don’t be nervous, but moving into a different industry. You know, once you can hear the story about how the product gets there, I think you’ll be able to say in just fine. So.

Dave: So how long until you think you’ll have to make some additional amendments to keep it up to date.

Aidan: Question, really, it really depends on the type of map you have. So I’d hate to say this. It’s not like a Gartner magic corner. Yeah. It sounds like that.

But it is. It should be revisited periodically. Because maps do like the landscape changes. That’s kind of a big thing for and that’s I think one of the points I make, the landscape is always changing, right? Even your competitors put in the kind of underlying technologies that we use, we’ve had some other ones thinking that like from, and that’s why I find that the varying levels that you can map out your things are incredible, like, yeah, go down to the lowest level up to highest I think, you know, it’s, like tentative, what kind of language, we’re going to use to write a code for up to, which cloud provider, we’re going to like, and then even higher, like, what kind of competitors are right there, what industry, we’re going to go out where different industries are going. Like, it’s, it’s a really just good exercise too, you know, to, to make yourself more learning, I guess, a bit what’s going on in the industry and why certain companies make certain decisions. And, you know, that’s kind of.

Dave: Was there anything specific that after having the map, you were able to remove from the kind of the expected work over the next bit or add that you that no one anticipated?

Aidan: Yeah. So the map kind of validated our assumptions. That for one, we were on the right track. So as part of my task right there. And, you know, in the blog, I mentioned that the grid is essentially a scheduling platform. And, you know, Kubernetes itself is pretty good scheduling. Maybe we should, like, focus our efforts there on a community of like, 30,000 developers. And so that was kind of why we felt it was also around, like, why people are using Kubernetes, right, it’s, it’s not just a new cool thing, and actually solves a lot of pain.

Dave: A lot of pain, not all of it, though, but a lot of it

Aidan: Not all of it but a lot of it, like it solves, you know, the scheduling kind of issues, it solves, a kind of standardizing the underlying platform that we’re going into, we can, you know, everyone’s offering Kubernetes now, like, I’m surprised at the amount of people that are offering Kubernetes now. And everyone’s got their own flavour. I just, I’m glad that it’s kind of staying vendor-neutral. And, and I think everyone just, I think infrastructure, folks are just tired of endlessly customizing stuff, and having these horrible spaghetti deliveries that they just want to know. Here’s Kubernetes. Here’s, you know, here’s our schedule, my containers, like, what we did notice was that you know, the move to Docker and how we move to connect containerized workloads, that was definitely the right decision for us. And you can see that with AWS offering a similar product called Fargate, I think, yeah. Yeah, like companies are looking for us to this kind of solution. So I don’t know, what’s your experience of Kubernetes?

Dave: We’re using it as our production environment. And it’s great. So we’re using Azure. And we’re using we’re in the middle of the migration to AKS, which is the Azure Kubernetes Service. When we installed it, originally, that was still in preview. And so you had to use ACS, which was the Azure Container Service that used Kubernetes. But the hosts are static. So there’s no, there’s no way to doing a migration to a newer version. So once we get on AKS, that should make some things easier. But

Aidan: I knew this would design was Kubernetes

Dave: Yeah, but I mean, I was able to, in about a day, maybe two days, take our existing Docker containers that we’re running and Kubernetes that we’ve been deploying with the MO files, some Helm charts, but right, maybe 50 lines, Python program that just our bit bucket pipelines, send a web or two. And now every time we commit to master or merge to master after a pull request, it just puts itself the test.

Aidan: Yeah, we found that, straight, those kinds of improvements have been excellent.

Dave: Yeah. I mean, it’s like, oh, you wasted a day. Yeah, yeah. Except for every other time I was doing a deployment, it was like four hours. So I save myself four hours, every time we show it.

Aidan: That’s why we, you know, when you’re doing a mapping of different technologies, you can see, like, even if you do like, the history of computing and data-centre, I think about most companies or software companies, they’re like, but they’re also experts in data centres, right? Because they need to build their own data centres they need to develop and like they kind of dilute the whole, you know, what’s the offering to the customer? Like? Yes, Workday customer doesn’t see all the good and really great effort that goes into our data centres, they just see, everything’s up, like, and that’s where we talked about the map about, the only see the web page, and the only see that, you know, what behind that is like a team of brilliant engineers, and developers make sure that you know, and that’s why you can see that sometimes companies go, we need to update the rest, continue to scale. And to give young, there’s plenty of work to do. And so I know, for many, many years puts a lot of customers we see now, like you’re asking you about AWS and Azure, because they ironically, are already in AWS and Azure and that kind of, anyway, yeah, that’s right. I just find that really interesting. But I kind of get worried about. Is everything going to be on the cloud? I don’t know. It’s something.

Dave: Just for those non-technical people. The cloud means someone else’s computer. That’s all it means. Someone else has that hardware in a data centre somewhere.

Aidan: That’s the key, right? So I don’t have to worry like, Yeah,

Dave: Exactly.

Aidan: It’s like renting a car, I don’t need to worry about I just pick it up using where I need. That’s what I always thought the cloud to be. And that’s where you can see a mapping away, it makes more sense from a utilization point of view. So, you know, from a data, if you have all the data centre, you can see that that’s a sunk cost you need to pay for it. You know, with a scalable cloud infrastructure, you can spin up and down and re reassign workloads. And that’s why, you know, when in terms of mapping, you can see why a lot of companies have moved to that model. It just makes like, I don’t you only pay for what you use. I think that’s huge for business.

Dave: Yeah. But virtual instances don’t appreciate. So every time you spin up a new one, you get the newer hardware. I mean, obviously, that depends on the provider. But you know, it’s if you’ve built your infrastructure, right, pushing a button, pushing a button will migrate you to the new hardware. It will fix the the the bugs there. So what was the last?

Aidan: foreshadow? Or

Dave: might have been thinking about one even older than that, but yeah, you know, so if you’re, if your whole virtual plane has a bug, how do you fix that without bringing down your entire data centre? Yeah, yeah. Well, if you’re on the cloud, on someone else’s computer, it’s their problem. Yeah. Yeah. Kill that instance, and bring up a new one. And there you go.

Aidan: Yeah. Yeah, sorry, if we’ve rambled, once I asked about Kubernetes I just kick-off. But I believe Simon has some map camps coming up in the UK and I’m actively trying to get them to come to London.

Dave: That would be nice.

Aidan: Because I it’s like, just a bit bit, maybe I’ll go back to a bit of history with Simon Simon was he joined canonical, where they use his mapping technique to pretty much make a bone to contain over 80% of the cloud market OS? So like, it works.

Dave: Yeah. There’s a case study for it.

Aidan: Exactly. You can the show, you know, there’s a number of publicized maps on his medium page. And he can share with time and time again, like why it, it kind of makes sense. And they can now I know, there’s been some criticism of that. So I think there’s a Wikipedia page about it.

Dave: Let’s see what it like.

Aidan: Like, the fact that you get people in a room to talk about where you’re going as a product or compete is a win. Regardless of maps and no maps, I think that’s really important. And so I was just trying to show, you know, like, just to think about the bigger picture on what you’re missing. And trying to, you always have to iterate because I know you’re going back to that question around. How often should you update your app? Like, what I think about that question, you should be checking, like, it’s really bad, how quick your competitors can move in the market, right? So if you’re doing a competitive play, and you’re on your map, and you’re seeing what others are doing, you need to you need to be constantly looking at that, right?

So let’s just say the IBM red hat acquisition, like how does that change them in a mapping kind of sense? What do they now offer their users? You know, and you map that against Oracle, and Amazon and the others, and just show how they move their offerings into a more mature, more valuable, you know, kind of offering to their end customers, right. So I find that you know, sometimes you see acquisitions, and they go, why did they make the acquisition? You know, it’s, it’s really around their customer needs and what they can offer. So, yeah, I and you can see that through sitting down and mapping IBM history until what we’re going to do today thanks to our retail company something. But yeah, they, sorry, I just want to produce it.

Dave: But have you considered trying to use this process in any other area of your life?

Aidan: No, that’s, I should though.

Dave: Totally stealing from, you know, using a personal KanBan type of theory.

Aidan: Yeah, I think he could probably, actually, there was one from Jay Bloom, I think was his name. And he was, he was saying about or Gordon McDermott, or Gordon McMahon. So I went to the Scottish map camp, there was a presentation there, I can send it out to you.

Dave: Yeah, please.

Aidan: He was on a bit how they. So he works with JP Morgan. And he was showing how he had to manage different teams, skillets on how different skills were on the map. So like, some folks weren’t good at such thing and how do I made them much more of an expert’s and what like, you know, once they make some expert, they’re much higher value to my ordered customers. I have to take it off to you. But I found that interesting about how they applied mapping to like, person skills. And where you could focus on so like, what, you know, what do you offer, as a person? What skills you have and what skills here you’re like, are unique to you, I guess you could say, and what do you need to actually, I sound like commodities myself. But I

Dave: Well, there are certain elements of what you do that should be commoditised. Absolutely, I mean that’s kind of what outsourcing is all about.

Aidan: Yeah, yeah. Exactly. But I think right, I think I can take up from that fear and I think his name was Gordon. I’ll send you a link but it’s really interesting, how they. I thought was very clear how you applied it to people, and what skills they had and how we assign different teams, groups, teams, and you could see like, you know, certain teams are missing such scale, and how could they not be jitter. And I found out that was very interesting. So

Dave: I have to be careful myself. It’s like the old adage about when you learn a new design pattern that you then inflict it on every program you write. So I have to be careful when I learn new techniques for optimizing life that don’t make everything try to fit that.

Aidan: Yeah, I do too. I hope and have some custom unique skills on the map. So they commoditize product manager like you know, you just buy it off the website.

Dave: Yeah, I really doubt that. It’d be hard to commoditize something that is different in every single situation.

Aidan: Yes, that’s true. Yeah.

Dave: Although I don’t know. Yeah, no. Yeah. So are there any other elements that we should cover that are beyond the visual elements that I’m sure some people are probably still trying to wrestle with understanding which I don’t know how I could paint pictures any better than what we’ve done so far?

Aidan: Yeah, I apologize.

Dave: Well, what I might do is asked that they look at an image of it beforehand.

Aidan: Yes.

Dave: So I’ll throw in some a bit of a caveat before listening to this episode.

Aidan: The more people that just like I would just be happy if people went on to Simon Wardley’s medium page. And just read that I know there’s some other called Ben Monseur who is on Twitter. Simon, who are actively, you know, showing people how to do mapping and you know, why they what benefits they can get out of it. Like, it is gaining popularity, there is actually a map, map camp slack group. And I could send you all the details, see where, you know, users can figure it, it’s amazing. Like, what we’re seeing is like, mapping of stuff that I didn’t even think could be mapped. Yeah, and it’s just a really, it’s really good for my. So, I’m currently a master mates strategy and I brought that up in one of the classes. And there’s a big debate around how do you make it more academic? So like, strategy is a interesting topic.

Dave: Let’s make this less usable.

Aidan: Yeah. You thought it was a big debate, like how do you teach strategy? You know, there’s definitely different methods. But Simon was trying to show you around a different one on a value chain, and what you can offer? And I think there was some effort Simon’s there was an academic paper written on us. I know, I kind of wrote on it and my kind say my course. I think it made sense, in the past so.

So yeah, I think the takeaway from it just to try the most basic map of your product, it depends on where you’re like, if you’re a developer, what tools you’re using. And it’s really a learning experience all the tools are there. And, like, it’s, the person I try to reach out to is like that. But Product Manager, or manager who’s like new, the need to figure out where stuff like learn, you know, learn boy decisions were made, and learn where you need to get to. And I think that’s really important, if you want to succeed. So

Dave: Nice. What’s next for you?

Aidan: So I’m, in terms of mapping? In terms of, so I used to, I moved into the what’s called the platform and infrastructure team, so as you know, it’s related to Kubernetes. Can you tell how excited? So yeah, I’ve been trying to get that kind of built within Workday. And so we have that single, you know, we can show that we have that single abstraction there. I guess, like, you know, we worked in Workday, Worked in AWS workday and wherever you want. You know, that’s kind of what everyone’s already doing. So yes, I’m responsible for making sure that that’s is being sort of hands ensure that we have the proper storage platform for that as well. So yeah, we did, like you kind of do a mini mapping of their choosing a technology. And I think that’s an interesting one as well to say, hey, like, you know, is it an enterprise supported solution? Is this, you know, is it going to be just two guys on the phone? To call for support? Is it a proper, you know, decent community? And, like, I don’t know what your thoughts are on open source, but like, my my only concern is that if community disappears, real problems supporting us and then yeah, I think I think there’s a lot of hype Kubernetes keeps going for a while.

Dave: Yeah, I think so.

Aidan: Because I actually saw was more than just spinning up VMs and that kind of stuff. So I, yes. So currently, I’m just trying to make sure that Workday continues to scale. And, yeah. And then continuing learning rate mapping.

Dave: So if there’s nothing else, how can people reach you?

Aidan: So I guess you can reach me on Twitter, LinkedIn, so my Twitter is @aidan_molloy, I think you can find me easy if

Dave: Oh, I’ll add it in the show notes as well.

Aidan: I’m able to reply and talk to you guys about how, how we went through mapping, if you have questions about it, and, you know, I’m part it’s like being a product manager for a open source. Like I find that’s very interesting. And have you manage, technically a third party product, what features do you need to build? And I’d love to talk about that again. That’s kind of where I where I’m comfortable. So yeah, you can add my LinkedIn I guess, you could just search for my name. Because people like our people will listen to this and makes sense.

Dave: Yeah. What, you know, I said, I read that article a couple of times, watch a couple of videos, listened intently. And I just feel like I’ve just scratched the surface of understanding this. And it’s not that it’s so difficult to understand. It’s all the nuances and how deep you can go and how deep you should go. And how you should back away that I still

Aidan: The fact that you’re taken about that. I think it’s a win in itself. Right? So that’s really where and I hope Simon wants to get to right. So you think about. Yeah, right. You’re thinking about it, which is already first step. You’re the master tool like, the fact you’re thinking what components should I put in, you know, and you can flash out with someone else. Like the best thing I found was that doing it with another person to make sure that you’re not in your little bubble gum. Everything’s awesome and how I value to my customer. So yeah, I definitely a team effort that we plan to post. But you know, different people are very different experience. They think of they’re like, “No, my product is a fully-fledged product.” It was good. It’s good example.

Dave: All right. Well, great. Thank you so much for joining us.

Aidan: Thank you for having me on.

Dave: It was a pleasure.

Aidan: I hope it made sense.

Dave: Yeah, I think so it did for me. But please do. If you didn’t get it in the beginning, which I haven’t recorded yet. But I will, check out the blog post and at least some of the images so that it will make a little more sense. But thank you and thank you all for listening.

Until next time, remember any sufficiently advanced technology indistinguishable from magic.