In the previous post in this series, we covered why you need to focus on oucomes. In this post we'll look at a couple of techniques I like to use to elevate the conversation to a more strategic level.
Extend Your Remit
I believe we need to extend our remit beyond ‘Lean UX’ to encompass strategy to help our organisations into a position of being able to consider outcomes.
I have two favourites 'tools' for this Wardley Mapping and Impact Mapping.
Wardley (Value Chain) Mapping
Something I've found extemely helpful talking to senior leaders is what Simon Wardley describes as 'Situational Awareness' and the manifestation of this as Wardley Value Chain Maps.
I'd suggest you read everything on his blog – if you're like me, you'll probably read it more than once as there's a lot to absorb.
You may not want to do that right now, so an extremely high level (and probably inadequate) description of the idea is this:
- Start with user needs
- Create a value chain
- Map this on the vertical axis from invisible to visible
- Map your components along the horizontal axis as evolution with a scale of: Genesis > Custom Built > Product(+ Rental) > Commodity (+Utility)
This shows you where you are.
From this you observe the map, look for where you can gain strategic advantage. This might be done by moving a component forward through it's evolution, aggregating existing technologies to reduce waste, consuming other's technologies, or a myriad of other possible solutions.
You can then use this for planning your actual work, from what technology choices you might want, to what process best suits managing where a component is in it's evolution.
Beyond the planning however, comes the real value, by visualising where you are in this fashion, you can spot new routes to disrupt your industry, potentially surpassing your competitors, by concieving of a future they hadn't.
Impact Mapping
Impact mapping is an idea and book from Gojko Adzic.
The below explanation is lifted from here. I've restructed it slightly to explain the value before the process.
An impact map is a visualisation of scope and underlying assumptions, created collaboratively by senior technical and business people.
Project plans and requirements documents are often shopping lists of features, without any context why such things are important. Without a clear mapping of deliverables to business objectives, and a justification of that mapping through impacts that need to be supported, it is incredibly difficult to argue why certain items should or shouldn’t be invested in. In larger organisations with many project stakeholders or product sponsors, this leads to huge scope-creep as everyone’s pet features and ideas are bundled in.
An impact map puts all the deliverables in the context of the impacts that they are supposed to support. This allows us to compare deliverables and avoid over-investing in less important areas of a system. It also helps to throw out deliverables that do not really contribute to any impact that is critical for a particular goal. Finally, by connecting deliverables to impacts and goals, an impact map shows the chain of reasoning that led to a feature suggestion. This allows us to scrutinise those decisions better and re-evaluate them as new information becomes available through delivery.
An impact map is a mind-map grown during a discussion facilitated by considering the following four aspects:
Goal
The centre of an impact map answers the most important question: Why are we doing this? This is the goal we are trying to achieve.
Actors
The first branch of an impact map provides answers to the following questions: Who can produce the desired effect? Who can obstruct it? Who are the consumers or users of our product? Who will be impacted by it? These are the actors who can influence the outcome.
Impacts
The second branch level of an impact map sets the actors in the perspective of our business goal. It answers the following questions: How should our actors’ behaviour change? How can they help us to achieve the goal? How can they obstruct or prevent us from succeeding? These are the impacts that we’re trying to create.
Deliverables
Once we have the first three questions answered, we can talk about scope. The third branch level of an impact map answers the following question: What can we do, as an organisation or a delivery team, to support the required impacts? These are the deliverables, software features and organisational activities.
Further Interesting Ideas
Outomes, goals, capabilities, activities – so many words so many ways to think about things. I find reading as many views around an idea as possible helps me triangualate what I think makes most sense / works best, but also give me alternative approaches should something not be working with a particular group. From a pure 'outcomes' point of view, I find both of these ideas a bit 'in the weeds' and would prefer to operate at a higher (more 'destination') level.
However they both become really useful once you have your higher level outcomes clearly defined. Then you need to get into the weeds!
Here are a few articles I've enjoyed around this topic.
Liz Keogh's Capability based planning which is a follow up to Estimating Complexity in which she discusses her risk scale.
- Just about everyone in the world has done this.
- Lots of people have done this, including someone on our team.
- Someone in our company has done this, or we have access to expertise.
- Someone in the world did this, but not in our organization (and probably at a competitor).
- Nobody in the world has ever done this before.
Jeff Patton's work on story mapping is well worth reading around (He talks about 'abilities' which seem similar to capabilities in Liz's terms).
It's no coincidence that most of the things on this page are ways of mapping. For me, visually representing information makes it less confusing and intimidating, and more coherent. Of course beyond helping us better understand the situation as individuals, the real power is that you can see it as a group.