Wardley Mapping
Wardley Mapping is a visual way to map the components of a business or service strategy based on their value to the customer and the maturity of those components. This helps organisations understand their environment and make informed decisions.
Goal
The goal of Wardley Mapping is to break down a solution into multiple parts to identify where to invest, what to outsource, and potential areas for innovation.
Context
There are a lot of table-stakes components in a product that are not differentiators. By mapping out the value chain, we can identify the components that are differentiators and those that are commodities. This helps us understand where we should outsource work to other products versus where we should build ourselves.
Build vs buy
The most common use of a Wardley map for a Stream Team is the build-vs-buy decision. The map gives the team a defensible answer to "should we write this ourselves?" without falling into either of the usual traps.
The first trap is building everything. Engineers tend to overestimate how much value the team will derive from owning a custom-built version of a commodity capability. Auth, payments, observability, feature flags, search are all capabilities where buying or using open source is usually the right answer for an early-stage product, but where teams often write their own anyway because the act of writing is more satisfying than the act of evaluating vendors.
The second trap is buying everything. Once a team has been burned by build-it-ourselves rework, the pendulum swings the other way and the team starts using a SaaS for capabilities that are core to the product. Now the differentiator is constrained by a vendor's roadmap, the team has no leverage on the part of the product that is supposed to be unique, and switching costs lock them in.
Wardley mapping resolves the trap by separating the components by their stage of evolution rather than by team preference:
- Genesis and Custom-Built items are where the differentiator lives. The product's competitive position depends on these. Build them, and own the code.
- Product/Rental items are well-understood capabilities with mature commercial offerings. Buy or rent. Use the saved engineering capacity on the items in the previous category.
- Commodity/Utility items are capabilities that look like infrastructure: auth, hosting, monitoring, payments. Use a vendor or open source. Rolling your own is almost always a distraction.
The principle: the team's engineering effort is a finite resource. Spending it on items that have already been productised costs more than it returns, because every hour spent building a worse version of an off-the-shelf capability is an hour not spent on the genesis-stage items that actually differentiate the product.
Stages
| Stage | Description |
|---|---|
| Genesis | This stage represents completely new, novel items that are being built for the first time. They are highly uncertain and often custom-built. Innovation is key here. |
| Custom Built | Items in this stage are still relatively unique but have moved beyond the initial innovation phase. They are more understood but still require custom development. |
| Product/Rental | By this stage, the item has evolved into more standardised products or services. It's widely understood, and economies of scale start to kick in. |
| Commodity/Utility | The final stage of evolution, where the item is completely standardised, widely available, and treated as a commodity or utility. |
Steps
Identify the Purpose of the Map: Understand the solution, underlying opportunity and the overarching product vision and strategy.
Define the Users: Identify the key users / jobs-to-be-done for the product.
Break Down the Value Chain: Break down the solution into technical components..
Map the Components to the Value Chain: Place these components on the map according to their value to the user (vertically) and their stage of evolution (horizontally).
Connect the Components: Draw lines between components to show their relationships and dependencies. This helps in understanding how changes in one component might affect others.
Analyse the Map: Use the placement of items to investigate off-the-shelf alternatives for commodity and product items. Focus delivery effort on the genesis and custom-built items.
Inputs
| Artifact | Description |
|---|---|
| Validated Solution | A solution that has been tested and validated with users through Continuous Design, ensuring that it meets their needs and expectations. |
Outputs
| Artifact | Description | Benefits |
|---|---|---|
| Wardley Map | A visual representation of the value chain, showing the components of the solution and their stage of evolution. | Guides decision-making and prioritisation of resources for maximum strategic impact. |
| Commodity/Product Items | A list of items that are commodities or products, and can be bought or rented. | Focuses delivery effort on the genesis and custom-built items. |
Anti-patterns
- Focusing too much on current operations and neglecting future strategic opportunities.
- Overcomplicating the map with too much detail, making it difficult to derive actionable insights.
- Ignoring external market forces and competitor activities.
- Failing to update the map regularly, leading to strategic decisions based on outdated information.