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
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
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.
From Roman Pichler talk at BCS Agile SG, 8/Nov/2018
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!
Outcomes and probabilities mapped
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
It isn’t just brexit which has multiple pathways, here’s a few maps of transport options
between Edinburgh and London showing the same.
There is one route, with 4 different options
Now there are three routes — which one?
There are 2095 options.
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
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.