Refining strategy with Wardley Mapping.

This is a draft chapter.

As best I can recall, the first time I heard about Wardley Mapping was a discussion between Charity Majors and Liz Fong-Jones on Twitter. Of the techniques discussed in the [strategy refinement chapters]/refining-eng-strategy/), it’s the technique that I’ve personally used the least. Despite that, I decided to include it both because it highlights how many different techniques can be used for refining strategy, and because it does and excellent job of considering broadly and widely. Where the other techniques like systems thinking and strategy testing often zoom in, Wardley mapping is remarkably effective at zooming out.

In this chapter, we’ll cover:

• TODO: fill this list in
• …
• …
• …

After working through this chapter, and digging into some of this book’s examples of Wardley Maps, you’ll have a good background to start your own mapping practice.

This is an exploratory, draft chapter for a book on engineering strategy that I’m brainstorming in #eng-strategy-book. As such, some of the links go to other draft chapters, both published drafts and very early, unpublished drafts.

When are Wardley Maps useful?

If you don’t accurately understand the problem at hand, then you can’t accurate evaluate potential solutions, and your chances for successfully deploying strategy will be rather low. Conversely, if you have a clear sense of reality, even if you don’t initially have a good proposal of how to navigate that reality, you are much more likely to filter through the potential options successfully. Wardley Maps think of that as creating situational awareness, and creating situational awareness is their foremost goal.

Wardley Maps are helpful:

• develop diagnosis
• strategy refinement
• exploring the landscape you’re operating in

Where systems modeling is particularly valuable at assessing and optimizing your approach to solving a diagnosis, Wardley Maps are most useful for understanding the evolution of the environment that surrounds the problem you’re solving. If you’re operating in a sufficiently narrow timeframe (e.g. this year), you may not find Wardley Mapping to add too much clarity to your problem. If you’re operating over a longer timeframe (e.g. this decade), you may well find that ignoring Wardley Mapping is causing you to miss out on essential industry dynamics.

Ten minute primer

TODO: fill this section in

• what to read / maybe pull these in from the first sections
• similar to what I did for systems modeling

Tools for Wardley Mapping

Systems modeling has a serious tooling problem, which often prevents would-be adopters from developing their systems modeling practice. Fortunately, Wardley Mapping doesn’t suffer from that problem. At worst, you can simply print out a Wardley Map and draw on it by hand, or you can use OmniGraffle, Miro, Figma or whatever diagramming tool you already use.

There are more focused tools as well, with Ben Mosior pulling together an excellent writeup on Wardley Mapping Tools as of 2024. Of those two, I’d strongly encourage starting with Mapkeep as a simple, free, and intuitive tool for your innitial mapping needs.

After you’ve gotten some practice, you may well want to move back into your most familiar diagramming tool to make it easier to collaborate with colleagues, but initially prioritize the simplest tool you can to avoid losing learning momentum on configuration, setup and so on.

How to Wardley Map

TODO: fill this section in

expand along lines of what I did for systems modeling

0. Commit to starting small and iterating.
1. List users, needs and capabilities.
2. Establish value chains.
3. Plot value chains on a Wardley Map.
4. Study current state of the map.
5. Predict evolution of the map.
6. Study future state of the map.
7. Share with others for feedback.
8. Document what you’ve learned.

Breadcrumbs for Wardley Map examples

With the foundation in place, the best way to build on Wardley mapping is writing your own maps. The second best way is to read existing maps that others have made, and a number of which exist within this book:

• TODO: fill these in
• LLM evolution
• Gitlab strategy
• need at least one with climatic patterns emphasis on evolution of space: where to invest now/in future

In addition to the maps within this book, I also label maps that I create on my blog using the wardley category.

How to document a Wardley Map

Echoing the point from how to create readable strategy documents, it’s always tempting to structure documents around the creation process. However, it’s essentially always better to write in two steps: a writing-optimization version that’s focused on creation, and then reworking into a reading-optimized version that’s supports easier comprehension from readers who may or may not be interested in the details.

The writing-optimized version is what we discussed in “How to Wardley Map” above, and then the reading-optimized version is:

1. How things work today

2. Transition to future state

3. Learnings

4. Users and Value chains – ??

   In a sufficiently complex, it’s very reasonable to split this into two sections, but generally I find it eliminates redundency to cover users and value chains in one joint section rather than separately. This is a good example of the difference between reading and writing: splitting these two topics helps clarify thinking, but muddles reading.

This may well feel a bit counter-intuitive for you, as the person who has the full set of details, but my experience is that it will be simpler to read for most readers. That’s because most readers read until they agree with the conclusion, then stop reading, and are only interested in the details if they disagree with the conclusion.

What about doctrines and gameplay?

This book’s components of strategy are most heavily influenced by Richard Rumelt’s approach. Simon Wardley’s approach to strategy built around Wardley Mapping could be viewed as a competing lens. For each problem that Rumelt’s system solves, there is a Wardley solution as well, and it’s worth mentioning some of the components I’ve not included, and why I didn’t.

The two most important components I’ve not discussed thus far are Wardley’s ideas of doctrine and gameplay. Wardley’s doctrine are universally applicable practices like knowing your users, biasing towards data, and design for constant evolution. Gameplay is similar to doctrine, but is context-dependent rather than universal. Some examples of gameplay are talent raid (hiring from knowledgable competitior), bundling (selling products together rather than separately), and exploiting network effects.

I decided not to spend much time on doctrine and gameplay because I find them lightly specialized on the needs of business strategy, and consequently a bit messy to apply to the sorts of problems that this book is most interested in solving: the problems of engineering strategy.

To be explicit, I don’t personally view Rumelt’s approach and Wardley’s approaches as competing efforts. What’s most valuable is to have a broad toolkit, and pull in the pieces of that toolkit that feel most applicable to the problems at hand. I find Wardley Maps exceptionally valuable at enhancing exploration, diagnosis, and refinement in some problems. In other problems, typically shorter duration or more internally-oriented, I find the Rumelt playbook more applicable. In all problems, I find the combination more valuable than anchoring in one camp’s perspective.

Summary

TODO: fill this section in

…