Member-only story
Book Review : Wardley Mapping
Review and highlights from my reading of Simon Wardley’s book
The name of this article is misleading because the book doesn’t actually have a name. It is written as a series of articles — so I’m just choosing to call it “Wardley Mapping”. The images here are taken from the book.
I have been slowly going over Simon Wardley’s free book on Medium where he walks us through the problems he faced, which then led to the development of the wardley mapping technique. It’s a long book, but the 6 first six chapters cover the most important parts at a high level and provide a nice closure to the problems and proposed solutions. So I am publishing the highlights from these as a package for those who are just starting out exploring Wardley mapping technique.
For the uninitiated, Wardley Mapping is a technique which plots the user needs and the capabilities a company needs to meet them on the axes of customer-visibility and stages of evolution. Things can be more or less visible to customers (Current location of Uber cars is highly visible, the map data powering this is not), and they may be nascent in nature or highly evolved (Uber’s app is highly customized, the map data powering it is fairly standardized). These two dimensions form the “map” of a business problem, and along with some concepts taken from the military, are the core of a process of using the map to decide the next steps the “general” (the person responsible for making a decision) should take.
Although Simon developed this technique as a CEO of a company and used it to drive the overall strategy, I find it extremely useful as an engineer with a more limited, engineering centric view as well. I have been trying my hand at it, and it allows me to map customer experiences to the capabilities we need throughout the ecosystem at all levels. This was always a feature of architectural discussion for me in the past, but knowledge of wardley maps has made it possible for me to bridge the gap between a product specification and architecture doc a little more formally. I can plot and discuss the entire path from roadmap to frontend needs to backend engineering to infra capabilities more crisply with product managers and other engineers.
