Wardley Mapping is a core part of our book: 'The Value Flywheel Effect'. And it's a topic that people always ask about it. It's a difficult thing to learn. We've spent many years thinking about it, stumbling around, and then practicing. So we figured we would do a quick series on Wardley Mapping.
We have spent almost 10 years mapping, give or take. For me, it has been an absolute game-changer. One thing that's come along recently is the Wardley Mapping canvas by Ben Mosior @hiredthought. It's a nice canvas with six steps on how to map. Before I started using the canvas, I used to find that maps could get big and go off in 60 different directions.
Purpose and scope are the first two steps. And then the third one is users. The fourth one is user needs. And then the fifth step is the value chain. It can be difficult to keep things abstract. And not go too deep. But it is good to be as abstract and high-level as possible, even just to start to get something down.
Once you have the value chain of the user, a need, and a couple of dependencies, that's when you then bring it across to the map. And I would usually put them in the middle of the map. Drop them all into Product, to get you started. So you've got them all in a vertical line on your map and canvas. You start moving different components from left to right. And you might work out that one of the dependencies is Commodity or Custom. And you can see how that interaction goes. That's when you start to add in dependencies because you've got more room in the map.
This is where the conversation really starts to kick into gear. And this is where people start to challenge each other's context and think about where that component belongs or what's missing from the map. So it makes for a very collaborative exercise.
If you are planning a mapping session, you need to be a good facilitator. If a participant feels something is in the wrong place. Don't say no, you're wrong. It's in the right place. You want the individual to explain why they think so. If it is something that's blatantly just them for raising the challenge. The last thing you want is an unsafe environment where nobody wants to speak.
It doesn't need to be too fancy. You might map for an hour. And if you're facilitating, five or 10 minutes off the hour, you take a couple of notes, If someone says we should move that component from x to y that's an observation, You're not committing to do it but just taking a few observations. Always just keep it simple.
So here are a couple of really good links. We talked about Ben Mosier @hiredthought. He's got a brilliant site called LearnWardleyMapping.com. Ben created the Wardley Mapping Canvas, which is on Creative Commons Open Source.
Simon's also got a couple of links. There's a site on GitHub called Awesome Wardley Maps. It is by John Grant on List.WardleyMaps.com. Simon's original book is on medium.com/wardleymaps. Simon's content is great but deep.
Hi folks. Welcome to the next edition of Serverless Craic with Dave Anderson, Author/Contributor at The Serverless Edge and Architect at G-P.
Mark McCann:
Hi everyone. Mark McCann, Architect at G-P and Author/Contributor at The Serverless Edge.
Michael O'Reilly:
Hey everyone, Michael O'Reilly, Architect with G-P and Contributor at The Serverless Edge.
Dave Anderson:
We've been doing quite a lot of talking about Wardley Mapping and throughout the book. It's it's a topic that always comes up. And people always ask about it. It's a difficult thing to learn. We've spent many years thinking about it, stumbling around, and then practising. So we figured we would do a quick series on Wardley Mapping. I think we have spent almost 10 years mapping, give or take. It is worth kind of reflecting on what we think of the technique. For me, it has been an absolute game changer. The way it introduces you to thinking is second to none. It is far better than any strategic technique I've come across. And I tend to read quite a lot of things. We will cover how we use it today with some good tips to get you started, if you're new to it. Because it is daunting when you see maps done by Simon Wardley on his Twitter feed. My question is do you still value the technique. Are you still thinking in that way?
Mark McCann:
Yeah, absolutely. It's a great way to bring sense to your thoughts and the things that may be concerning or troubling you. Once you start thinking about how to map, it brings clarity to your thinking. We've being doing it so long we think about how things are interconnected. And what the value chain looks like and how one component relates to another. You are doing it instinctively. In your head, you're thinking about components, the value chain, dependencies and how evolved they are. Once you practice this technique, you think about things in a different way. And it really helps to facilitate good conversations with everybody. It doesn't matter how senior you are or how familiar you are with mapping? It allows you to have a better, richer conversation about what you want to discuss.
Michael O'Reilly:
The triggers for mapping are quite
interesting:
if there's decisions to be made, how do you prioritise certain things? Or, how do you decide on the next right thing to do and have conversations with people from multiple disciplines. Mapping can be a good technique to facilitate conversations to drive towards decisions and where you think focus should be. Or to drive towards a common understanding. When I find myself in those situations where conversations need to be had, it"s a good opportunity to introduce a mapping exercise. Also, when you're in a new area, or you want to immerse yourself how something hangs together. I'm sure Dave, you're doing a that at the minute. Whether you are in a new position, or want to understand a business, tech stack or industry, it can be handy and quick to assemble a map with a bunch of people for a different perspective.
Mark McCann:
There's nothing better than putting up a a value chain of components, collaborating with domain experts and pointing out where it is wrong. That's what you want. It's a bias reaction. So it's about getting something on a whiteboard or collaborative MIRO. And letting the experts challenge you and say that's not over there or you forgot about this. It's a great way to get an understanding of a new area or domain that you may be working into. It's an accelerator for understanding for new people coming in.
Dave Anderson:
One thing that's come along recently is the Wardley Mapping canvas by Ben Mosior @hiredthought. It's a nice canvas with six steps on how to map. The purpose of a map is to figure out who the user is. And to do a value chain, which shows what the user needs are, and what that depends on, and then plot the evolution of those things. From Genesis, which is brand new to custom where you think you can make this item. To product, we need this and it's really important. And finally to commodity, which is the price for doing business and everyone has one. So every component evolves from left to right. But there's a nice sequence of steps that Ben has put together. And this is open source. We have posted links in our notes. So I figured it might be useful to walk through this because the steps before the map make the map successful.
Mark McCann:
The purpose bit is the most fascinating. What are you trying to achieve? And what's the trigger for this? What purpose do you have and what are the things you are trying to accomplish? Do you have a Northstar you're trying to align with? Or why is this group of people together? It could be even your why. What does this team do? And what is the purpose of this tech stack. Having that initial conversation is such a rich thing to have with teams, Especially if they haven't been thinking about it and it's just been about building and building and building.
Dave Anderson:
If a team are deep into something, the first thing to do is lift them back to why do you exist? Why does this project exist? What are you trying to achieve? And you'd be surprised at the amount of teams that have to stop and think about it. So getting a crisp definition of purpose is the first step. And the second step is scope. What are we trying to map. Some people will try to map everything. But you need to narrow that as much as possible up front. Because there's a temptation to map the world. You need to narrow can stay focused. Sometimes a way to do that is to decide on what not to map. We're not going to worry about a third party thing, or a different team. We're going to focus on the current scope.
Michael O'Reilly:
Before I started using the canvas, I used to find that maps could get big and go off in 60 different directions. So as a shout out to Ben, his canvas has been a lifesaver for keeping maps focused, and fit for the topic.
Dave Anderson:
I think Ben's canvas came out five years ago. When we staryed mapping we didn't have this canvas. And that was the thing that always went wrong. We always went too wide and confused ourselves.
Michael O'Reilly:
Yeah, map the world.
Mark McCann:
Absolutely. I was already guilty of that. Go deep and your maps have 50 to 60 components. And then you have to take a step back and group ten items together as one thing. You get better at naming things after a while.
Dave Anderson:
So purpose and scope are the first two. And then the third one is users.
Michael O'Reilly:
Who are the main users and who's part of this flow to narrows what we're trying to capture. It's a good exercise because a lot of people don't know who the users are.
Dave Anderson:
This is pure design thinking. It's a blatant first question for your project to ask: 'who's your user?'. You should have at least one user be very clear who that is, and gives that person a name or a role. You'd be surprised because for alot of teams the answer is we don't really know. So that's the third step. The fourth one is user needs. Because once you've figured out who the user is, you need to work out what are their needs? What do they need in this scope. It's usually only two or three things.
Mark McCann:
With users, it's good to zero in on core needs. There may be a lot of stuff that other userswant. But it's good to have a conversation on the needs of your core users, and focus on those. There will be lots of peripheral stuff that doesn't factor in what teams are trying to accomplish.
Dave Anderson:
When you're going through these first steps, keep it simple. If there are two or three users, pick one to go on, And if that user has six or seven needs, pick two or three, to get you going. You can always add more later. It's important to move through the steps because if you get stuck on one, you will stay there for a long time. And then the fifth step is value chain. So this is where it starts getting interesting. Fingers crossed, you've got a single user with a single need. And that need could be a driver needs a car. And that car depends on something. This where a value chain comes in. You've got a user with a need, and then that need has dependencies. For example a car may depend on a manufacturer or on petrol.
Michael O'Reilly:
It can be difficult to keep things abstract. And not go too deep. But it is good to be as abstract andhigh level as possible, even just to start to get something down.
Dave Anderson:
I always remind people at this point that this is not a formal notation, We're not not doing a diagram or a model. It's okay to be generic. What you're doing is driving conversation. By looking at the most important needs and dependencies in that value chain, It's not everything and it's okay to leave a couple out. So once you have that value chain of the user, a need and a couple of dependencies, that's when you then bring it across to the map. And I would usually put them in the middle of the map,. Drop them all into Product, to get you started. So you've got them all in a vertical line on your map and canvas. I usually put the user and product at the top. And then you look at the need, you think is that need in Product, Custom or Genesis, and you move from left to right. You start moving different components from left to right. And you might work out that one of the dependencies is Commodity. Or is Custom. And you can see how that interaction goes. That's when you start to add in dependencies, because you've got more room in the map.
Mark McCann:
This is where the conversation really starts to kick into gear. And this is where people start to challenge each other's context and thinking about where that component belongs or what's missing from the map. So it makes for a very collaborative exercise. Try not to do this on your own, but try to do it with a few people who might be new to the domain or in another context. Because then you can get into collaborative challenge where you challenge the map and the components and elements on the map. But you're not challenging the person. You're challenging what can go here, or is it better on the left or right. And by asking why you may get a hidden context that's revealed. It could be something that was forgotten that you now understand and where the're coming from. That's when the richness and the value starts to
Dave Anderson:
If you are planning a mapping session, you surface. need to be a good facilitator. If a paricipant feels something is in the wrong place. Don't say no, you're wrong. It's in the right place. You want the individual to explain why they think so. If it is something that's blatantly just them for raising the challenge. The last thing you want is an unsafe environment where nobody wants to speak.
Mark McCann:
That in essence is your first map and the basic 101
Michael O'Reilly:
As a facilitator, if it's a really of mapping. good session, you can derive outcomes.And you would capture notes or next steps.
Dave Anderson:
And it doesn't need to be too fancy. You might map for an hour. And if you're facilitating, five or 10 minutes off the hour, you take a couple of notes, If someone says we we should move that component from x to y the that's an observation, You're not committing to do it but just taking a few observations.
Mark McCann:
Adding an annotation or note to each of the elements or things that are surfacing is important. For exaple, have a few notes to say why we custom built our own database etc. That's something we should probably tackle, right? As maybe there's an evolutionary step, so we can move that across to a commodity or database offering. It's usually a good example of something that you want to evolve rapidly. Once you have your initial map, you can talk about how to evolve it. And where you think this should go for meeting the needs of the users into the future. You have a conversation about what's stopping us from evolving? In the database example, if you have a database that you're dependent on that's custom built, you might want to evolve that to be a commodity. So what's stopping you doing that? Maybe we don't have the skill set, the underlying capabilities, or a tech stack or whatever. You can start to have notes around what's stopping you removing the inertia barriers. And that's something that you could get to your next session.
Dave Anderson:
Always just keep it simple. So here's couple of really good links. We talked about Ben Mosier @hiredthought. He's got a brilliant site called LearnWardleyMapping.com. Ben created that Wardley Mapping Canvas, which is on Creative Commons Open Source. Simon's also got a couple of links. There's a site on GitHub called Awesome Wardley Maps. It is by John Grant on List.WardleyMaps.com. Simon's original book is on medium.com/wardley maps. Simon's content is great but deep. So that's the craic. Well will continue this series and look at other things as we go. Please keep an eye on the Twitter@ServerlessEdge, subscribe to Serverless Craic on YouTube and the blog TheServerlessEdge.com. Thanks very much. Bye.