Product Delivery mapping
A possible approach to take a Wardley map and turn it into a product roadmap your team can use to build a backlog in line with strategic objectives.
This is a use case of delivery mapping (which I am working on) which is in turn a use case of event mapping (which I am also working on). There are different use cases for mapping how teams interact (individuals and interactions) and understanding cause and effect.
Event mapping is important I believe because it can help understand how things interact with and affect other things and get us a better understanding of how understand the present, shape the future and understand the past.
I ran this past a few coaches and got some good feedback at the Glasgow Global Diversity Call For Proposals Day then ran it past some coaches at work who also like it so here’s the first iteration.
Thanks to Simon Wardley for the Wardley maps and Chris McDermott and Roman Pichler who I heard speaking last year and got me thinking along these lines. I struggled a bit with Wardley maps when I ended up with a map and then wondered if it was clear what to do next to implement it.
(alpha version — may contain bugs — feedback welcome)
1. Build the Wardley map
2. Map to feature teams or component teams as appropriate. See https://www.cio.co.uk/it-strategy/introduction-wardley-value-chain-mapping-3604565/ as an example. This is the output
4. Create a mission for each team, preferably as part of a team canvas. In the diagram above some are “improve what we do already” (more lean oriented). Others are moving across the tech landscape and building new products. Team three is transferring to using a commodity production systems.
5. Build the value outcome statement. When the map is complete, the value realised will be “XXX” — fill this in yourself, with something that each team contributes to. This is the value of the work. Consider OKR format. e.g. We aim to save money on our production systems by transferring to commodity technology. We will measure our progress on this by transferring 10% of our estate this year, which will reduce £XX costs.
6. Now we have goals, teams and measurable steps.
7. Take the team goals and put some value against them (cost reduction, risk reduction, opportunity ennablement ) etc
8. Map time against The Important Thing. e.g. cost. (why is this valuable work). Your important thing may be different.
9. Plot the activities on the timeline against cost now, future cost (or profit / cost ratio)
10. Shape this to form product roadmap — realisable high level features aligned to value. This is just the visible bit which users see, the stuff under the waterline is the delivery tactics that more internal to the organisation.
This is the product roadmap in context. It is derived from a product vision and strategy to ensure alignment. The product strategy and vision should likewise align to organisational vision and strategy.
11. Under the water, the “bit under the water” in an iceberg analogy — see the connections and dependencies aligned to “things that get in the way” (e.g. risk). This where the problems occur which derail projects. Look at the riskiness, ideally governance should adapt to foreseen risk rather than one size fits all. Risky stuff justifies more governance, agile and experiments, by putting experiments in the risk goes down. Recognise there is more than one potential path. Consider the pros/cons/risks of each. You might end up with something like this on its side!
In the above diagram we can see there are multiple pathways to the same outcome. There are also multiple conflicting outcomes in this scenario. For the latest version see Jon Worth on Twitter.
It isn’t just brexit which has multiple pathways, here’s a few maps of transport options between Edinburgh and London showing the same.
2095 flight combinations of getting a return trip to London for the week.
Knowing the destination is not enough, we need some guidance on how to get there otherwise with many options it is easy to have different interpretations of “how do we get there”.
12. The bit under the water is the “delivery map”. This is the WHY of WHY are we building it this way. You can use this to do storymapping from (thanks Andrea Gigante). Hence you can now build an actual storymap which is the basis of your product backlog. This then aligns back to your “how” delivery map and the above water product roadmap and ultimately the strategy aligned to the Wardley map. it’s in two parts. The product roadmap above, the delivery map underneath. Risk on the delivery map is high risk at the bottom, so that the least risky stuff is closest to the product roadmap above.
this is just a sketch of an idea — the pictures and better explanations will follow later :-)
See also the daily scrum as an event map and strategy maps.
