2026-10-21
October 21, 2026
Most program plans assume the landscape holds still while you build. A Wardley map is the cheapest way to find out which of your components are about to be sold to you for pennies.
Pull up the last platform program you ran and look at the plan's quiet assumption: that the thing you are about to build will still be worth building when it ships. For most of the last decade that assumption was close enough. In 2026 it is a bet, and in AI-adjacent work it is a bad one. Tian Pan, writing in July, cites inference prices falling by roughly 9x to 900x a year depending on the capability threshold you track, along with constant churn in agent frameworks and gateways. A program that spends two quarters hand-building a model gateway is racing a market that is giving the same thing away.
The dependency map and the RAID log cannot see this. They describe how your pieces relate to each other. They say nothing about where each piece is heading in the world outside your org. That second question belongs to Simon Wardley's mapping method, and it is the question a TPM or a tech leader is least equipped to answer by instinct, because evolution is invisible from inside a project. You only see it when a vendor ships the feature you spent six months on.
This is not a call to adopt a whole strategy discipline. It is a narrower claim: the kickoff meeting is where build, buy and rent decisions get baked into milestones, so the kickoff is where a two-hour map pays for itself. Today's Deep Dive explains how to run one, and what it tends to change.
What a Wardley map actually is. Two axes. The vertical axis is visibility to the user: your product experience at the top, the infrastructure nobody sees at the bottom, with a chain of dependencies running between. The horizontal axis is evolution, from genesis (novel, hand-built, poorly understood) through custom-built and product (rentable, with competing vendors) to commodity (standardized, utility-priced). Boris Mann's note on the method describes it as a way of reviewing and developing strategy around business and markets, and credits Wardley with developing it around the evolution of cloud computing. The first axis is a dependency graph you already know how to draw. The second axis is the new part, and it is where the value is.
The one rule that does the work: components drift right. Competitive pressure pushes things from genesis toward commodity, and not the other way. Pan makes the speed argument explicit: databases took about twenty years to commoditize, whereas he expects AI layers to take 18 to 36 months. So the question to ask of every component is not "where is it today" but "where will it be when our version ships." Seen that way, a build decision is a forecast, and a forecast can be argued with.
What the map changes in a plan. Pan draws three rules from it for an AI stack. Do not hand-build what is about to commoditize (gateways and routers are his example, which he describes as already commodity). Put your differentiation where it cannot commoditize, such as domain eval harnesses, operational data pipelines and workflow integration. Treat genesis-stage layers, like orchestration frameworks, as rentals: keep abstractions thin and expect to swap them. These are his judgments about mid-2026, and you should redraw them for your own stack, but the shape of the argument travels to any program.
The twist: AI also moves the build side. David Haberlah's March piece argues the old rule (buy at product or commodity, build at genesis or custom) has shifted because agentic tooling is cutting the cost of building software. He cites a Retool 2026 survey in which 35% of teams had already replaced at least one SaaS tool with a custom alternative. His answer is not "always build." It is to find the decisive component, the one that connects only to the build path or only to the buy path, flag the inertia on buy-path products such as annual contracts and data lock-in, and prototype first over a few days before deciding. I would treat the survey figure as his citation, not an established benchmark, but the method for isolating the decisive component is sound whichever way your numbers fall.
Why this belongs at kickoff, not in a strategy offsite. Craig Webster's August workshop write-up for Barking Iguana is the most practical thing I read this week, because it prices the activity: two hours, four to six people, a facilitator who does not place components. It runs from a user need at the top, through a value chain built by visibility alone, to an evolution assessment where you ask whether you would build or buy it if starting today and whether three alternatives exist. Then you mark inertia, annotate movement, and tag each component BUY, BUILD, WATCH or MIGRATE, ending with owners and dates. The "three alternatives" test is a good one because it replaces a philosophical argument about placement with a countable fact.
Where it goes wrong. Webster lists the failure modes, and they are the ones a TPM will recognize. The map turns into an architecture diagram with no people or process on it. People place their own creations as custom-built out of attachment. Everything lands in the product column. A senior person has already decided, so the session is theatre. And the most common: the map produces a good conversation and no owners, so it ages on the wall. The fix for the last one is already in his agenda, which is why the wrap-up step with owners and dates is not optional.
The TPM angle. The person who convenes this session is rarely the strategist. It is the one who has to translate the output into a plan, which makes it a natural TPM move. You are not claiming strategic authority. You are giving the group a structure for a debate it was going to have badly in a hallway anyway, and then you own the follow-through. Redraw it quarterly, as Pan suggests, and you also get something unusually useful for program reviews: a blameless reason to sunset an internal project ("the market commoditized this") that does not require anyone to have been wrong.
Try this week. Pick one program that has a build line item over a quarter long. Book 90 minutes with three engineers and the budget owner, put the user need at the top of a whiteboard, list ten components beneath it, and for each one ask Webster's question: "are there three credible alternatives we could rent today?" Anything that gets a yes goes in a column labelled "justify this build," and that list goes into your next steering review.
What it is. A way to draw a strategic landscape as a value chain placed on an evolution axis, so you can see which components are commoditizing and which are still novel, and decide where to build, buy or rent.
When to use it. At program kickoff when a build-versus-buy decision is open, before committing to a multi-quarter investment in infrastructure, or at a quarterly review when vendors keep shipping features that overlap your roadmap.
How to run it:
When NOT to use it. When the decision has already been made and the map would be ratification, or when the group will spend the hour arguing about placement instead of movement.
Example: a team maps its internal agent platform and finds the gateway sits with commodity and the eval harness sits left, so the gateway project is rescoped to a managed service and the freed engineers go to evals.
Wardley-Map Your AI Stack Before You Build Another Layer of It — Tian Pan (July 2026) gives three rules for AI infrastructure: rent what is commoditizing, hold churning layers loosely, and invest where data and evals differentiate. The commoditization timelines are his estimates, so test them against your own vendors.
Build vs Buy in 2026: Using Wardley Mapping to Navigate the Agentic AI Shift — David Haberlah (March 2026) argues cheaper agentic building shifts the old rule and proposes "prototype first, decide second." He also ships an MIT-licensed Claude skill for generating maps; read his survey figure as a citation, not a benchmark.
The Workshop: Wardley Mapping — Craig Webster (August 2026) turns the method into a timed two-hour agenda with a list of failure modes. It is the template to copy if you run your first session.
"Know your landscape before you choose your route."
— Editor's note, not a quotation: today's issue in one line
Don't miss what's next. Subscribe to Critical Path: