Arkaro Insights

From Inside Out to Outside In: Aligning Teams Around User Needs with Rich Allen

• Mark Blackwell • Episode 42

Share episode

Most organisations plan strategy with the outside world in mind, then implement it using unchanged internal structures. The result? Good teams with clear intentions still end up working at cross purposes.

In this episode, Rich Allen, author of User Needs Mapping, shows us how to shift from "inside out" to "outside in" thinking—anchoring change on what users actually need, then designing teams to deliver value with less friction and greater flow.

We explore why strategy so often stays trapped in slide decks, never translating into sustainable change. Rich introduces User Needs Mapping as a practical, visual technique that helps organisations identify users, define their needs, map capabilities, and align team boundaries accordingly. Drawing on principles from Wardley Mapping and Team Topologies, the approach makes visible what's usually hidden: unclear ownership, excessive handovers, duplicated effort, and cognitive overload.

Rich shares a compelling case study from Blue Lagoon, where co-created maps revealed that what seemed like a single "booking" need actually concealed multiple distinct user journeys. By refactoring team boundaries around actual value streams, they improved both clarity and trust whilst reducing dependencies.

We also examine AI through a sobering lens: AI amplifies whatever organisational design you currently have. Clear team boundaries and value flows mean AI can reduce toil and boost outcomes. Confusion and misalignment? AI magnifies that too. User Needs Mapping provides a grounded way to decide where AI belongs and how to govern it properly.

Key takeaways:

  • Why most teams don't suffer from lack of effort—they suffer from lack of alignment
  • The critical difference between wants, needs, and jobs to be done
  • How to use visual mapping to surface gaps and create shared understanding
  • Practical first steps: start with users and needs, not systems and structure
  • Why getting alignment right matters more than ever in the age of AI

If your organisation struggles with handovers, unclear ownership, or "agile" that moves tickets but not outcomes, this conversation offers practical tools you can use.

Read more on: https://arkaro.com/user-needs-mapping-team-alignment/

Subscribe to Arkaro Insights and share with colleagues navigating change in uncertain times.

Send your thoughts to Arkaro







Connect with Arkaro:

🔗 Follow us on LinkedIn:
Arkaro Company Page: https://www.linkedin.com/company/arkaro
Mark Blackwell: https://www.linkedin.com/in/markrblackwell/
Newsletter - Arkaro Insights: https://www.linkedin.com/newsletters/arkaro-insights-6924308904973631488/

🌐 Visit our website: www.arkaro.com


📺 Subscribe to our YouTube channel: www.youtube.com/@arkaro

Audio Podcast: https://arkaroinsights.buzzsprout.com


📧 For business enquiries: mark@arkaro.com

Mark Blackwell:

Hello everyone, this is Mark Blackwell. Welcome to the Arkaro Insights Podcast. This is the podcast where we help busy B2B executives navigate themselves around uncertain times and equip them to thrive in an adaptive world. And today we've got a guest who can certainly help us map and chart our way through these challenges. Today we have Rich Allen, who is author of Use the User Needs Mapping, Aligning Teams Around What Matters. So Rich is an independent consultant and a socio technical architect. I think we'll learn about what that means today on the podcast. He's the founder of Conjura Solutions, a boutique consultancy based in the UK. He's got over two decades of experience from a software engineer to technical lead to architect and startup CTO. Rich specializes in helping organizations reduce friction, evolve team boundaries, and align around a central imperative, the faster flow of value to meet user needs. He's the creator and of User Needs Mapping, a practical and visual methodology for connecting organizations to the people they serve. This highly accessible technique is based on the first four steps of Wardly mapping and integrated with Team Topologies principles. Indeed, Rich is also recognized as one of the longest-serving Team Topologies value practitioners, having played an active role in the evolution of Team Topologies practice. So many of you will know about Team Topologies, many of you won't. So, Rich, welcome to the show. Tell me about yourself. How did you get here?

Speaker 1:

Awesome. Yeah, great. Thank you very much for inviting me to be here. Mark's really, really awesome to get to spend this time talking about user needs mapping. So brief history of where I've come from. As you mentioned, I've been hands-on developing software since um the early 2000s. So graduated from Bournemouth University. I did a degree in microelectronics and computing, coming at it from the hands-on, learning how the tech works, sort of things. I sort of earned my stripes in what we call agile software development fairly early on. I was actually working with a startup called High Integrity Solutions, which was building software for organizations like BAE systems. And at the time it was very much around this thing called the V design model. So very much waterfall, where we would start with sort of doors requirements and then go into goal structuring notation and then creating or using tools such as Artisan and Rational Rose to kind of design systems. But we were in a startup and we were trying to apply those same ideas within the startup. And it we I kind of saw it fail fairly early on. So then actually the Agile Manifesto came out around that time. And I was quite an early adopter of that, thinking, well, this is like we're working in this waterfall, but what we're building needs to be quicker than that. So actually, I earned my Agile Stripes fairly early on, fairly fresh out of university. And then that kind of went through followed my career. So I ended up working in the technical role, but then I would end up leading the teams, and then I'd end up kind of spotting waste within the teams, and then thinking about how we can start to optimize, how can we be more effective in the way we deliver value? So that seemed to be my natural MO, as it were. So when organizations technically and so basically that then um takes me through to like the late uh late teens. So I was working in a company called PureGim, and I was helping them build out uh their software team, so bringing their software team in-house and starting to grow it from scratch. Um, we were using lots of good practices, all of those things, um, cloud-based development, um, single um single-piece flow, all good solid practices. Um, but as the organization wanted to add more people, they wanted to get more mobile developers. Um we were deploying what 16 times a day, which is you know fairly decent. But we recognized that the processes that we had were not going to support additional people in that way. So we needed to think about how we can actually reorganize ourselves to be more effective. Um, I tried a number of different ways to kind of help that message land with the senior leadership at the time. And Agile for a long time was all about processes like um how you deliver the software lean, and everything is all very kind of linear and how the workflows, but nothing really about how you organize teams. So I was struggling to articulate that. And then the book Team Topologies actually came out, which we'll go into a bit later, but that became a catalyst. So I read that and said, This is what I've been trying to say all along. It became a catalyst for change at PureGym. Then I reached out to Matthew and Manuel, so this was probably early 2020. Reached out to Matthew and Manuel, who were the authors of Team Topologies, and said, This um, we've just applied it at PureGym. They said, Can you write a case study? I said, Yes, I can. Wrote the case study, and that actually became the first case study of someone reading the book and attempting to apply the principles. And so actually from that point onwards, I've been working closely with them and the core team at Team Topologies to help develop the ideas and help other organizations adopt the patterns and principles so that we can become more effective and optimize for faster flow of value to users. So that kind of brings me up to essentially where we are today. And then as part of that work, I introduced user needs mapping to the to the toolkit. And so over the last five years, we've been using user needs mapping as part of our way of helping organizations. And so I finally felt that after five years, it was time to write a book.

Mark Blackwell:

Well done. Thank you for that. I mean, there's lots of really good ideas in the book that uh resonated with ideas we've already covered in other podcasts, and we'll talk through those today. So it's a beautiful linking. One of the big ideas is this inside out versus outside in thinking that you come at. And you know, thinking about organizations, especially when they're doing strategy, you think, oh, what's happening in the external world? Yes, this is what we want to do. And so they might plan a strategy based upon competing in their ecosystem, and they might be thought of as outside in. Yeah. But typically, when it comes to implementing their strategy, I would say they're still thinking about inside out. The hierarchies haven't changed. They're typically, you know, hierarchies more than, as I said that by accident, but I really meant organization, but really implied was hierarchies remain the same. And so there's a an imbalance, I would say. What would you comment on that?

Speaker 1:

And yeah, definitely. And I think that that's absolutely right. So lots of organizations are kind of having this inside-out thinking where they are looking or focusing on the current structures and the systems and maybe the assumptions that they already have. And um, but like you said, the real alignment starts by working from the outside in. And I think basically inside out thinking it stems from sort of the tailorism scientific management times of the early 90s, where the focus is very much on sort of linear factory manufacturing lines, how do we optimize the kind of the way that work flows internally to deliver that value? And those kind of inside-out thinking organizations that may have thought about that strategy, they think they're considering the users, but then it immediately becomes about how do we make our processes more efficient, things like that. And so a lot of modern-day management practices are based around that tailoristic thinking. And that was all kind of fine when the rate of change was a lot slower, essentially. So organizations, we we would have like a norm, a normal way of running, and then we would run a project. And when the project was done, we would go back to a norm and we could kind of settle into that. So we didn't have to change the organizational structure or the way we were structured as quickly in order to still deliver that value. But in the modern world, the the rate of change is now accelerating kind of so quickly that the organizations kind of need to be able to keep up. And actually, like change is the new constant. You know, the amount of new technologies, the amount of uh the way in which uh the environment or the customer needs are changing is it's accelerated so quickly. So that I think is the kind of significant shift from why organizations now to need to become more outside in thinking and shift away from this inside um out. And really for me, the the big driver um or shift and think around going to in outside in is comes from a gentleman called Simon Wardley.

Mark Blackwell:

Yeah, I I know about Simon Wardley, but I'm guessing that many of our listeners have not heard. So please. Okay.

Speaker 1:

So basically, so Simon um in around 2005, Simon Wardley, um self-confessed failed CTO, uh uh sorry, CEO, was kind of struggling with his company, didn't really know um what to build his strategy on. Um, so he started to turn to Sun Tzu's art of war. So he configured, well, he he considered if our organization is kind of fighting within is fighting a mini-war within the competitive landscape, can we use the principles from that in thinking about how we win within the competitive landscape? And so he then started to bring in those ideas. Um, and it's essentially based around this idea that strategy is at this ongoing cycle and pivots around five key points, which is purpose, what's your moral imperative uh for be for existing, why are you there as an organization? Then understanding what your landscape around you is, where are you actually fighting the battle? Are there hills? Are there um who's in in that world? Then you have the kind of climatic patterns or the climate around you. Are there storms coming in? Are they, you know, what's what's going to influence the landscape that you're currently acting? Then you have your sort of doctrinal principles, which are the way that you've trained your your armies or your staff, your the capabilities or the the ways of working inside of your organization. And then finally, after combining all of those things, we can start to think about the sort of leadership stratagems, which are kind of ways in which we would play within the market. But many, many organizations kind of jumped straight from purpose to leadership stratagems without really considering the broader landscape, climate, and doctrine and principles. And so that was really the kind of big inspiration uh for me was kind of getting this outside in thinking. And one of the key aspects of that is that Simon anchors everything on the user and what it is they need. So we start there and then we work backwards, so outside in to the organization to then look at how the organization delivers what capabilities they need in order to meet those organizational needs. So that was really kind of the key inspiration for me. And when I was then doing the work with um team topologies and working with clients, I was fully aware of all the all of those principles. But as you can kind of say, like there's quite a lot to take in, there's quite a lot to get your head around, climatic patterns, doctrinal principles, like what does all this stuff mean? And I found that um a lot of people's kind of eyes glaze over, like, oh, like there's just too much going on. Um, but it was really valuable. And um, working with various different clients, what I needed to do was get a quick understanding of their current landscape. Um and so I found that there was value in the users, the needs, and the capabilities of building out the value chain um without necessarily thinking about um the evolutionary part of a Wardly map. So a key part of Wardly's thinking is that everything evolves in a supply and demand market, and that's where the kind of complexity around climatic patterns and all of those things kind of creeps in. Um so actually, with user needs mapping, we start Wardly mapping, but we focus on that one kind of doctrinal principle, which is focus on your users. And if we can start to increase the awareness of who the users are and what they need within the organization, that in itself is massively valuable. And so that's essentially what user needs mapping builds upon. It kind of um intentionally reduces the scope of the Wardly map. It doesn't prevent us from moving to Wardly Mapping, but it gets us thinking in terms of users and needs. Um, and if we can get that more across the organization, then it will be a tenfold improvement just in general because people are understanding who the users are. Um and so Wardly really kind of brings the why we should change, and then using needs mapping helps us to kind of provide the how. How can we kind of communicate the strategy in a simpler way that more people can understand? So, really, user needs mapping kind of helps us sharp, helps the organization sharpen how they look at their users, how they currently understand the works that kind of serves those users, and then how we start to design teams around delivering that work.

Mark Blackwell:

Fabulous summary. I'm guessing that there may be a couple of listeners who are a little bit skeptical or hesitant, thinking, hey, Rich and Simon, they're both techie guys, they're both software guys. You know, that's their world, but it's not my world. So I think during this podcast, we need to try and just nudge any skeptics in that direction another way to just to remind ourselves that this is the delivery of value. So one data point perhaps that might nudge some of those listeners is there's a great paper by the consultancy company Bain, which talks about the delivery gap. And it's a really simple to remember statistic, but it's so powerful. So they interviewed over 300 companies and the customers served by those camps by those companies and a range of industries. And they said, Companies, are you customer friendly? You know, and 80% of them felt that their value proposition was highly contingent upon them excelling in customer orientation and delivering customer value. So it's 80%. Okay. They then asked the customers of those companies, do you know what? Was it anything like 80%? No. Only 8% of the customers served by those companies felt that their supplier excelled in delivering customer value. So there is clearly a delivery gap. That's self-evident. And it's really, I think that that paper is very much in tune with the situation you've described. And it really talks uh if there is a delivery gap, what is it that we need to do? And it's all about the flow of value, as I take it. Rich, is that right?

Speaker 1:

Yeah, 100%. And I think, yeah, totally that that Bain's um report around um, you know, the 80% to 8% gap is is just massive, isn't it? And often I think that's it's definitely not necessarily the performance of the people within the organization. Most organizations have willing, capable people um that are able to do that. But for me, it's a big signal um that those all those organizations are are still having this inside-out thinking. So they're focusing on their internal functions or internal silos, but the actual users are getting the whole experience view of the organization. They're not caring about how it's structured internally. And so that for me is the big gap. The the strategy might start with the users, but then they don't translate that throughout the whole organization to think about are we actually organized in a way that delivers value effectively through the value chain that we have? And so when we start to take sort of this outside in view, um, once we have our user needs map, we've got our user and their needs as the anchor, then we can start to sort of spot where the capabilities that we have, and we can start to then sort of overlay where our current teams are involved in delivering on those user needs. And often we'll kind of spot where we might have one team that are involved in every single way in which we deliver value. So that might be a natural signal that that particular team is constantly context switching, like they're having to understand all of these different needs from various different users, and actually, like it's a quick visual way to kind of see cognitive load or like how um the need of those teams to better understand who their users are, or really they don't have a clear understanding of who they are because they're having to serve so many. And so using the map, we can start to kind of reveal the the kind of Bane report, really. So the the gap is you know who your users are, but when you then look at how you've aligned your capabilities and the teams that own those capabilities, actually there's a big um there's a big gap there. And so that's really where the as well, once we spot those challenges, this is where the team topology side of things starts to really kind of help our thinking. Um, as I mentioned, team topologies kind of was released in 2019. Uh it's actually had a uh a second edition just published, uh, which has got a bunch of new case studies and things around that. But what was really groundbreaking about the team topology side of things is that certainly for me was it became it brought a language for how we think about team structure. Um, but specifically, um in a um in a VUCA world, uh, you know, where everything's constantly changing, we need to recognize that organizations are socio-technical systems, right? And this is the idea of why I'm a socio-technical architect, because it's really bridging that. How do we marry up the people within the organization with the technology, the process, and the actual work? And as with any kind of complex system, when we change one part of the system, it will have a knock-on effect on the other parts of the system, whether we like it or not. So if we're changing the way in which we work or that the way in which we're structured, we're gonna impact or have an impact on the people. And so then Team Topologies um kind of gives us this what we call a pattern language. So it's a way of using patterns and practices that actually drive emergent behavior. So it introduces something called enabling constraints. So it's constraints that we can apply, and by applying those, they drive good outcomes, right? So the idea is that then Team Topologies brings in this concept that any organization, if we focus, if we look at them in the way that the teams are structured, that the topology of the teams and how they interact, and we actually can start to define the team structures using three, sorry, four different topology types. And it's those uh topology types and three interaction modes. When they're used effectively, we can start to shape how we deliver value and articulate that in a way that we can start to improve the organization.

Mark Blackwell:

You were talking about enabling constraints because it just captures another link to ideas that we have in the in the podcast. And it's a key thought in the our thinking on the emergent approach to strategy when we've talked to Pete Compo, is that you need constraints for creativity and innovation to happen. And it's having then rules and policies at low levels of an organization that creates emergent properties within an organization so that it can deliver so much more than is immediately apparent by the relatively simple low-level policies as an organization. So keep I'll keep looking out for connections and stop you when I see them if you don't mind. But maybe just get back into your flow. Tell me about the four different types of the topologies.

Speaker 1:

Yeah, and absolutely. Uh, and enabling constraints and doctrinal principles are kind of really, really important in complex socio-technical systems. So the the four uh team topologies that um bring out art starts with something called a stream-aligned team. So the idea here is that this is a long-lived, stable team of around five to nine people that has end-to-end capabilities to deliver the value that they need to deliver. So given a particular user and they're serving a particular user need, that's who they're delivering value to, or it could be multiple user needs, whatever that might be. But that drives the the work or the it drives the work that's needed. And the work that's needed then determines what capabilities that team needs. So, regardless of kind of technology or or anything else, it's it's specific on who the who the needs of the user are, should actually dictate what the capabilities are required in your particular team. So the streamalign team, the idea around the five to nine people is based around sort of Robin Dunbar's kind of trust boundaries and thinking. So we want to encourage high trust within that team so that they work really well together. Um, if we're not mindful of the number of people within the team, um, as we start to approach, say, 15 people in the team, um, the trust boundaries within that team will start to change. You'll start to actually see that maybe that we're acting as two separate teams, almost like um in rugby, you know, um English rugby, you have two teams. Although it's one team of 15, you actually have two teams, the scrum team and the back team. They all have their own separate strategies, but they work collectively as one team of 15. And so they need to interact, but they have trust within, say, the scrum team and the back team. So that five to nine number is based around human aspects. And that's really important part of team topologies is it's very much about how do we create more humane workplaces, right? So, and having this focus on the cognitive load of the people within those teams. So, if we only had one team type, it would be that streamaligned team. So, like you can think of a startup essentially as being one stream-aligned team. And as it starts to grow, we need to make decisions about how we evolve that streamaligned team. And so um, because we're thinking about the flow of value to those end users, as we add more capability into the team, our cognitive load will start to become exceeded. And so then we have other supporting team types which are there to A, help that team improve the flow of value to their end users, and then B, reduce their cognitive load. So we want to think about well, what are the needs of that streamaligned team? And how can these other teams then understand their needs and recognize what it takes to remove or reduce their cognitive load? So the second team type is an enabling team, and that enabling team is really there to sense kind of capability gaps. So it's a team of experts that know, have specialist knowledge in a certain capability. They would recognize that that team is missing a certain capability, whether it's like product management or testing or whatever the capability is they need, they would then work with that team to upskill them. So they're actively and purposefully what we call facilitating that team to make sure that they have the right capabilities. And then when they're done, they want to step away, right? So it's a short-lived interaction between an enabling team and that delivery team. So that's what they're doing is reducing the intrinsic cognitive load of that team. So the skills, the basic skills that that team needs in order to deliver value. And then the second type is called a complicated subsystem team. And that's often where we might have a highly complicated part of the system, something that's um related to uh machine learning or something like that, something that needs kind of PhD level, hard-to-find expertise. We want those streamaligned teams to consume uh those services, but it's kind of overwhelming. So let's set up a separate team that focuses on that thing but provides services that the streamaligned team can then consume. And so they can we want that team to be able to self-service via a simple um API or a wiki page or you know, um, something that they can actually consume and allows them to continue working without doing a handover between those teams. And then the and that's what we we call extraneous cognitive load. So that's kind of taking away things that are necessary for that team to deliver the work, but it's extraneous to the actual core problem that they're trying to solve. And that's one particular part, so highly specialized area. And then the final topology is actually a platform grouping, and that platform grouping is there to again reduce that extraneous cognitive load, but we want to um it's kind of made up of people that are probably easier to come by, but um they're things that are again relevant to that team delivering their work, but extraneous to um the complexities. So the platform grouping, when you look inside of that platform grouping, you then see streamaligned teams. And so essentially inside that platform, it's the same kind of fractal kind of or self-similar nature. So we have a streamaligned team serving our end users, their extraneous or their cognitive load is exceeded. So they need help by supporting platforms. And inside of those platforms are streamaligned teams that recognize the needs of the delivery or streamaligned team and build things or capabilities to serve those needs. So it becomes this kind of fractal view of the organization that truly starts from the outside in, starting with the end user needs. How do we deliver value to those? And what do those teams need in order to deliver value to our internal teams? So the external and the internal users become as important as each other, and everyone then has a clear sense of their purpose within the value chain, and that kind of clearer definition of boundaries leads to a greater sense of purpose, mastery, and autonomy for the people within those teams because the use of those boundaries and the clarity of where they sit and how we need to interact with other parts of the team become more obvious.

Mark Blackwell:

Thank you. So I just as an aside, the technique that you use to get the view from the outside is fundamentally jobs to be done. Yes. And but we are a jobs to be done fan base on this podcast. Yeah. We've had two people who've studied under the founder Clayton Christensen, Stephen Wonka and Scott Anthony, on the show already. Yeah. And we've also had Scott Belson on his latest book, The Jobs to Be Done Pyramids. We're very well covered already, but if you want to mention it, of course you can. I'm more interested in the bits, maybe that we haven't done so much detail, and maybe perhaps bring it to life and with the context, build on what another guest of the podcast, Eric Engelon, has already described with a blue lagoon. Can you you translate the theory that you so eloquently described to make Maybe bring it to life with some practical recollection of that case study.

Speaker 1:

Yeah, absolutely. So, yes, job jobs to be done, kind of picking up on that point. Yes, after seeing Scott and the other podcasts, I there's nothing I can add on top of that. But really, for me, so the Wardly mapping and the needs that we're talking about in the Wardly map is very much aligned with the Jobs to be done theory and this idea that we're looking for needs that help um people make progress ultimately. But when we first start mapping, especially in an inside-out thinking organization, when we say who are your users and what do they need, often what we'll see is people mapping activities or tasks. So it's quite an early signal that you're not thinking in terms of needs. And so that's one of the first kind of ideas is once you start mapping, you start to see um where you need to increase your capability. So that particular team doesn't really understand user needs um in a way of uh jobs to be done thinking. So maybe we need like an enabling team that helps upscale that team to learn more about their user needs. So that would it'd be how we kind of really connect the user needs mapping to jobs to be done. But when it comes to Blue Lagoon, yeah, 100%. This is um a great example of using user needs mapping in a real world scenario. So Blue Lagoon, Icelandic, um how would you how would you define Blue Lagoon?

Mark Blackwell:

It's basically Leisure Resort, is it?

Speaker 1:

Absolutely, yeah, leisure resort, but like one of the wonders of the world, right? Like if you've if you've never been, uh it's just a fantastic experience. And Erica and I had the absolute pleasure of going to work with them, spent a week in their retreats bar so that we could experience their customer experience. And they're very much about user user needs, right? They want to give people a really great experience. But that was a classic example of externally they were thinking in terms of user needs. But when it came to how are we organized, um, it was inside out thinking. Like it would, they'd grown to a point they were looking to kind of scale their um their offering into other hotels, and they um gained awards for their booking engine and things that they were using for um for the Blue Lagoon itself. But they were then finding these challenges about how like how we're organizers not kind of scaling well. And so during the workshops that we did with Blue Lagoon, we went in, ran some user needs mapping workshops where we essentially got around 20 or so people in a room from various different aspects of the organization. So product people, salespeople, marketing people, technical people. And really, it was all about kind of surfacing who are the users. Like, if we're trying to understand how we're going to reorganize, let's just start throwing who the users are up on the board. So we're collectively co-creating who we define as those users. We put them all up on a whiteboard and we start to kind of then question like, are these the same user? Are they the same need? Like, how how what are the differences between those particular users? How does sales refer to them? How do you refer to them internally? So we're starting to align on the language that we're using within the organization and recognizing like, so is the need of booking a Blue Lacoon day pass, is that the same as booking something at the hotel, which is, you know, and and so they're starting to collectively recognize, well, no, it's not the same need. Like the purpose or what the um the job to be done that the the holidaymaker wants to do when they want to book something in the Highlands is different to when they want to do a day pass at the Blue De Game. So we start to kind of surface these differences, and they then can collectively start really thinking about actually, we as an as an IT part of the organization aren't structured in a way that supports the sort of value streams that we started to uncover as part of the engagement. So we used other techniques from team topologies, which I won't go into today, but things uh called independent service heuristics and team interaction modeling, which is very much once you've kind of looked at your landscape from a user needs mapping perspective, we then look at how the value flows through the teams using team shapes to recognize there's handovers between these teams. So kind of diving a bit more deeply into that, a little bit like a value stream map, but actually looking at it from a teams um perspective. And so that yeah, that engagement was really um a yeah, just a brilliant experience. And the what was amazing was that the leadership really invested in their people. So they said, look, we as an organization have this challenge. We need to understand how to reorganize to become more effective in how we deliver value to our users. Let's solve that problem. And Eric and I went in to essentially facilitate that solving of the problem. We use all of these techniques to then help them come to the realization that these are how we might more effectively create our cross-functional teams. We better understand who the users are, and because we included people from those teams in that decision-making process, they were much more bought in to having ownership of what the boundaries were and that were defined. So it was a wonderful, wonderful experience.

Mark Blackwell:

I know I could not agree with me. The importance of co-creation, it gives people the autonomy, the mastery, the purpose that they own it. It makes implementation so much easier. I mean, there's always a sensitivity about the time that's invested doing this co-creation, but it's nothing compared with the extra time that you will need trying to implement and a very high probability of not being able to implement.

Speaker 1:

So I love that. And I think uh to mention another podcast like Hillary mentioned the IKEA effect, right? So it's like people are more invested when they're involved rather than trying to define um going into a small room as a collective and saying, This is the new org design, and go, da-da, this is how you're gonna change. You know, actually involving people in the change just enables them to buy into it. And using these mapping and those techniques by making it visual kind of reduces the psychological safety of them being able to comment and things so they can actually talk about the map rather than it being an interpersonal, you're not attacking each other.

Mark Blackwell:

Fascinating, very important point, like it. So I also like the way you think of this as an evergreen tool, not just once-off, because you're setting itself up for situations where the environment changes. And of course, one topic that's been very important in many of our podcasts is something that's changing a lot of our working lives now: artificial intelligence. Maybe you could comment on how user need mapping will enable organizations manage this change.

Speaker 1:

Yep, 100%. Well, um, as as you mentioned kind of early on, so human organizations are made up of humans, right? And ultimately that's that's what um that's gonna be the case for a long, long time. And um AI is very much an amplifier. So it it will amplify the dysfunction within an organization. And so the organizations that are already outside in thinking and aligning their teams, aligning their humans in a way that delivers value effectively, I think will thrive with AI because they already have a clear understanding of how they deliver value and therefore they can recognize the boundaries in which AI can support them. So, where does it make sense for AI to support us delivering value to this user need, et cetera? Whereas organizations that don't have such a clear idea of how the team structures, how they interact, are potentially going to struggle with where AI can be effective and might be kind of using AI to try to find a solution. Uh got a tool, and they need to find a um problem for this solution.

Mark Blackwell:

Correct. I mean there was a podcast I did with Barry Eustons, and we were looking at this MIT paper that many people are talking about that shows that 95% of organizations have got AI projects which fail to meet their vision. And there's this the story is the shiny new tool that people have got FOMO. If I don't have AI, I'm gonna be out, but not understanding their processes and how they deliver value, causing them to put the tool in the wrong place.

Speaker 1:

So yeah, 100%. And you know, it's it's accelerating, say, the development of code, it's accelerating certain things, but actually, code was never really the problem in the first place. So, like all we're doing currently, say certainly in the in the coding space, but other spaces as well, right? We're just generating more content which isn't actually necessarily serving or meeting user needs. So the ones that will win are the ones that are really kind of considering where does this really help users make effective progress and that actually adds value that people can trust in a way that yeah, doesn't seem to be the case currently with lots of AI tools. You know, let's see where it goes. One one comment is Stuart Wintertier, who's quite uh an expert around AI, kind of coined team topologies as the infrastructure of agency by using these ways to articulate how we're structured, so our team types and how they interact, that will enable agency, whether it's human agency or AI agency, way more effectively in many organizations.

Mark Blackwell:

Yeah, and and to make a further connection, one of the guests that we're going to have in the future, we're going to be talking about governance in AI and the key idea of that it's not an IT issue, it's an organization.

Speaker 1:

Yeah, 100%. And and the and therefore the user needs map. So if each of those teams within the organization understand who their users are, who their needs are, what capabilities they own, they can visualize that and share that. We can start having conversations about where will AI be useful and effective to enable better delivery of value to our customers.

Mark Blackwell:

And also help mapping the governance requirements as well. Exactly. There's going to be it all it's all connected. So it's been a fabulous tour. Uh, thank you for this. If someone's been listening to this podcast and thinking, ah, I'm beginning to detect that we're maybe we are a little bit inside out, and maybe we're in the 80% that we talked about in the report, and maybe we're not serving our customers as well as we think we do. What would you recommend the next steps for that someone to take?

Speaker 1:

So definitely the first step is not to map your kind of technical systems. Don't start with your inside out thinking. Really try to push back against that kind of natural inclination and start with your users. So really, who are your users? Just start having that simple conversation. Maybe in the next meeting that you go, who's this serving? Like, who are we actually delivering this for? And um, just by starting to introduce that kind of language and what is it they need, if we can start to encourage that in not in every single meeting, but ultimately like more and more, the more that the organization begins to talk in terms of users and needs, the more that they'll be able to um start to embrace that thinking of outside in. Um, as what Simon Wardley kind of put it in the preface. So if a Wardley map kind of gives you the landscape and there's lots to kind of take in in order to truly understand your situational awareness in the landscape, then user needs mapping shows you what's been sitting at the end of the street all along. And so start with working out what's at the end of your street, work out what's your organizational life looks like, and then you can start looking at the broader situational awareness strategic landscape. Start with users and needs, and then move on to other things.

Mark Blackwell:

Brilliant, Rich. And if people want to find out more about you and your work, where can they go?

Speaker 1:

Uh probably around for this, go to userneeds mapping uh.com um or rich allen.info, or you can find me on LinkedIn just as Richard Allen.

Mark Blackwell:

Fabulous. Thank you very much, Rich. This has been really engaging and valuable discussion. Thank you so much for your time.

Speaker 1:

Thank you, Mark. It's been a pleasure.

Mark Blackwell:

Bye bye. Bye. Bye bye.

Head Shot

Mark Blackwell

Host
Head Shot

Rich Allen

Guest

Podcasts we love

Check out these other fine podcasts recommended by us, not an algorithm.

Just Great People Artwork

Just Great People

The Sixsess Consultancy