2026-05-20
May 20, 2026
Issue 014 — The build-vs-buy boundary that anchored your last three quarters has slid one square toward commodity. Senior leaders who aren't redrawing the map this quarter are funding headcount that no longer makes sense.
The line item is in every plan I see this month. "Custom integration layer — 6 engineers, 2 quarters, in-house build." Or: "Internal eval harness — staff up a 4-person ML platform pod." Or: "Agent orchestration framework — own it, don't depend on a vendor." Three quarters ago each of those was a defensible call. Today, two of the three are almost certainly the wrong square on the map.
The problem is not the decisions themselves. The problem is that the people making them are working from a value-chain picture that crystallized in 2024 or 2025, when LLM APIs were still custom-built, agent frameworks were still genesis, and there was no off-the-shelf eval tooling worth depending on. The components evolved. The mental map did not. So every quarterly planning meeting locks in capacity against a landscape that has already moved one square to the right.
This is the discovery half of the program job — and most senior TPMs and tech leaders are running it inside the wrong frame. Discovery is not user interviews and JTBD canvases. At program scope, discovery is landscape work: knowing where each component of your architecture sits on its evolution curve, anticipating which climate forces are about to push it further along, and adjusting the operating model before the next planning cycle locks the wrong bet in for two quarters.
The tool for this is forty years old in spirit, twenty in form, and still the most underused artifact in the senior TPM and tech-leader stack: the Wardley map.
Simon Wardley published the first complete version of his mapping method in the 2015–2017 Wardley Maps series on Medium, building on work he'd done as a CEO at Fotango in the early 2000s. The mechanic is simple enough to fit in a paragraph: pick a user need, decompose it into the value chain of components that deliver it, then plot each component on a horizontal axis from Genesis (novel, custom, expensive) through Custom-Built and Product/Rental to Commodity/Utility (standardized, cheap, undifferentiated). The vertical axis is visibility to the user. The result looks like a network diagram tilted sideways. The insight is that components move, predictably, from left to right — and the right operating model for a component depends entirely on where it currently sits.
This is what Wardley calls climate: the set of patterns that change the map regardless of your actions. Everything evolves. Efficiency enables innovation. Past success breeds inertia. You cannot stop these. You can only anticipate them. Climate sits above doctrine (the universal principles like "use a common language," "focus on user needs," "challenge your assumptions") and below gameplay (the context-specific moves you make once you know your map). Most strategy decks confuse these layers. A Wardley map keeps them separate.
For senior TPMs and tech leaders in 2026, three climatic moves are already in flight, and each one is invalidating program-level decisions that were correct twelve months ago.
Move one: LLM APIs have crossed into commodity. When GPT-4-class capability cost $30 per million tokens and was available from one vendor, the model layer sat at Product. Today the same capability is available from five vendors at standardized API surface area, with utility-style pay-per-use pricing, near-zero switching costs, and multi-cloud failover patterns that are now table stakes. David Haberlah's Build vs Buy in 2026 puts LLM APIs at roughly 0.82 on Wardley's evolution axis — past the Product/Commodity boundary. Implication for your program: any line item that funds in-house LLM tuning, prompt-engineering specialization as a long-term skill, or vendor-specific orchestration as a strategic differentiator is funding a custom-build of something that is rapidly turning into electricity.
Move two: agentic frameworks are compressing the Custom-Built-to-Product boundary at unusual speed. A year ago, building your own agent loop with tool-use, memory, and trajectory tracing required a small team. As of mid-2026, frameworks have absorbed most of that work, and observability layers (Honeycomb's Agent Timeline; the OpenTelemetry agent semantic conventions ratified earlier this year) are turning trajectory tracking into a configurable feature rather than a custom build. The agentic layer is, in Wardley terms, in late Custom-Built / early Product. Implication: the right move on most agent programs is to rent the framework and own the evals, not the inverse — which is what most plans I see are still doing.
Move three: eval tooling has moved from genesis to product faster than any senior leader expected. Eighteen months ago, internal evals were artisanal — bespoke harnesses written by ML researchers, no standardization, no obvious vendor. Today there are credible commercial offerings, open-source baselines with community traction, and Anthropic's Demystifying evals for AI agents framework articulating the practice in a way that any well-staffed eval pod can adopt. Implication: the headcount you allocated to "build our own eval platform" should probably split — two engineers to integrate a product-grade harness, the rest redirected to writing domain-specific eval tasks, which is the part that genuinely needs to be custom.
The discipline these three moves share is anticipation. Wardley's repeated insistence — most explicitly in his Cynefin piece on Medium — is that strategy without a map is just storytelling. The map's job is not to be precise. The map's job is to make the position and direction of each component visible to a room of people who would otherwise debate them in the abstract. Once the components are on the map, the strategy conversations collapse from "should we build it?" to "where is it now, where is it going, and what is our operating model for each phase of its evolution?"
A practical operating cadence emerges from this. At program kickoff, you draw the map of the value chain. Pin every component. Place each one on the evolution axis. Mark the ones likely to move within the next two quarters with an arrow. Now you scope the program: components in Genesis or Custom-Built get pioneer-team operating models (small, autonomous, exploratory); components in Product get settler operating models (productizing the workable, building reliable interfaces); components in Commodity get town-planner operating models (vendor management, SLA negotiation, cost optimization). This is Wardley's Pioneers / Settlers / Town Planners doctrine, and the underlying point is that a single team operating model is always wrong for a program with components at multiple evolution stages — which is virtually every interesting program in 2026.
The redraw cadence matters too. Most programs draw a map once and treat it as a poster. The honest cadence is monthly during a fast-moving phase, quarterly when stable. The 2026 climate around AI components is fast-moving by any historical comparison. Monthly is right. The redraw takes 90 minutes. It is the highest-leverage 90 minutes a senior TPM or tech leader can spend, because the cost of not redrawing is half a quarter of capacity allocated against last quarter's landscape.
There's one further move worth knowing about, which is the Wardley-Cynefin overlay. Wardley's own writing — and the 2026 INNOQ talk on staffing and procurement strategies for fast flow — uses the two frameworks together as orthogonal lenses. Wardley tells you where on the evolution curve a component sits. Cynefin tells you what kind of problem it is right now — Clear, Complicated, Complex, or Chaotic. The combination is what makes the operating-model choice precise. A component in Custom-Built and Complex needs a probe-sense-respond team. A component in Commodity and Clear needs a best-practice playbook and a procurement contract. The two answers look almost nothing alike. Most senior leaders are running one operating model across both, which is why the program feels alternately stuck and reckless.
If you take one thing from this issue: the discovery half of a senior TPM or tech-leader job is not "facilitating brainstorms." It is keeping the map current, redrawing it on a cadence that matches the climate, and letting the redraw drive the operating-model decisions that planning meetings otherwise make on autopilot.
Try this week. Pick the largest in-flight program on your plate. Draw the Wardley map of its value chain in 90 minutes. Mark every component you think will move one square right within two quarters. Then re-examine the current staffing plan against the map. If any pioneer team is sitting on a Commodity component, or any town-planner team is sitting on a Genesis component, you have your next conversation with the sponsor.
What it is. A method for visualizing the value chain of a program, product, or business as a network of components plotted on a two-dimensional space: visibility to the user (vertical) and evolution stage from Genesis to Commodity (horizontal). The map exposes where components sit, where they are moving, and what operating model is appropriate at each stage. It is a strategy artifact, not a Gantt chart.
When to use it. At program kickoff, when "build vs. buy" is on the table, when reorganizing teams around a technology landscape that is moving, when challenging a multi-quarter capacity commitment, or when a senior stakeholder asks "what's our strategy here?" and the honest answer is currently a list of projects.
How to run it:
When NOT to use it. Don't use Wardley maps for tactical execution planning, sprint scoping, or anything where the value chain is already well-understood and stable; you'll waste time visualizing what a checklist would have captured. Don't use it as a one-time poster artifact — an un-refreshed map is worse than no map because it manufactures false confidence.
Example: a 2026 platform program drew its map and discovered that the "internal vector database" component their roadmap funded as a Custom-Built effort was already a Product offering from three vendors. Two engineers were redirected from infra to eval-task authoring; one quarter of capacity recovered.
Build vs Buy in 2026: Using Wardley Mapping to Navigate the Agentic AI Shift — David Haberlah re-runs the build-vs-buy calculus through a Wardley lens with explicit evolution scores for LLM APIs, agent frameworks, and orchestration layers. The reference table alone is worth the read for any senior leader scoping AI capacity.
Staffing and procurement strategies for fast flow — INNOQ talk that uses Wardley + Cynefin + DDD as overlaid lenses to decide how to staff and procure for each component zone. Aimed squarely at architects and engineering leaders, not theorists.
Wardley Maps and Cynefin — Simon Wardley's own essay on combining the two frameworks. The short version: Wardley tells you where on the evolution curve a component sits; Cynefin tells you what kind of problem it currently is. Use both.
"A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness."
— Alfred Korzybski, Science and Sanity (1933)
Don't miss what's next. Subscribe to Critical Path: