2026-09-30
September 30, 2026 · Issue 110
When building gets cheap, the expensive question moves upstream: what kind of problem is this, and does your program plan even fit it?
Marty Cagan put the shift bluntly in April. Generative AI has driven the cost of prototyping so low that teams can build ten or twenty prototypes a week to test value, usability, feasibility and viability. His conclusion is that finding a solution worth building, not building it, is now the bottleneck. Read that as a program manager and it stings, because most program machinery (plans, milestones, dependency maps, status reviews) was built for the opposite world, where building was the expensive part and the job was to sequence it well.
That machinery is right for one kind of problem: the kind where cause and effect are knowable and expertise can find the answer. Dave Snowden and Mary Boone called this the complicated domain in their 2007 Harvard Business Review piece. Sense, analyze, respond. A datacenter migration with a known target state lives there. A launch of something nobody has shipped before does not. Their complex domain is defined by the fact that right answers cannot be worked out in advance; patterns emerge only if the leader runs experiments that can safely fail. Probe, sense, respond.
Most large programs today mix both, and most plans quietly assume the whole thing is complicated. The failure is not effort or discipline. It is running an analyze-then-execute machine on a problem that needed probes first. Today's issue is about how to tell the difference, using the discovery toolkit (maps, trees, probes) at program scope rather than product scope.
Start with the uncomfortable part. Most programs never make an explicit call on what kind of problem they are. The plan gets written because a plan is the deliverable, and the plan's shape (phases, dates, owners) silently asserts that the future is knowable. If you are wrong, you will find out in month five, when the "unexpected" dependencies and shifting requirements start to look like a pattern rather than bad luck.
The Cynefin framework, which Snowden developed in the late 1990s and which he and Boone brought to a management audience in 2007, gives you the vocabulary for making the call on purpose. In the complicated domain, hire the expert, analyze, and commit to a plan. In the complex domain, that same move backfires, because the analysis is answering a question the system has not yet decided. What works is a portfolio of small, cheap, observable experiments, followed by amplifying what shows promise and dampening what does not. The framework also names disorder, the state where nobody knows which domain applies, and advises breaking the situation into parts and assigning each part to a domain. For a program, that decomposition is the useful work: the data migration is complicated, the customer-facing behavior change is complex, the vendor outage last Tuesday was chaotic, and one status template covering all three is a category error.
Two other tools do the rest of the discovery job. Simon Wardley's maps give you a shared picture of where each component sits between genesis and commodity, anchored to a user need. Wardley makes a point about why this matters for teams that is easy to skim past: when you challenge someone's story you challenge their leadership, but if the story is on a map, "the map is wrong" can be said without saying the person is wrong. A map depersonalizes disagreement, which is worth a lot in a room with a VP and three directors. The Claude Code Wardley Map skill that Mark Craddock benchmarked in April shows both the promise and the limit. Against 25 of Wardley's published maps, it placed 61 percent of matched components within strategic tolerance and 92 percent within the right band or an adjacent one, but found only 37 percent of Wardley's components. Read that as: an AI can hand you a coarse first draft in minutes, and the argument the draft provokes is where the value is.
Teresa Torres's opportunity solution tree covers the third piece. It ties an outcome to the customer opportunities that might drive it, the candidate solutions, and the assumption tests that decide which to pursue. Her guidance carries over directly to program work: work one target opportunity at a time, and revise the opportunity space as you learn rather than freezing it in a plan.
The pattern that ties these together is an ordering. First, make the domain call, component by component. Second, for anything complex or genesis-stage, replace the plan with a set of probes and a review rhythm. Third, for anything complicated or commodity, keep the plan, and keep it boring. David Haberlah's Wardley-based build-versus-buy piece makes the same move at the tooling layer: prototype first, decide second, and revisit quarterly, because AI has made the build option cheap enough to test before you sign an annual contract. He cites a Retool 2026 survey finding that 35 percent of teams have already replaced a SaaS tool with a custom one. Treat that number as one vendor's survey, but the direction is hard to dispute.
What is your job in all this, if you are the TPM or the director? It is not to run the experiments; product and engineering own those. It is to make the domain call visible, to stop the machinery for the wrong domain from being applied, and to protect the review cadence that lets a probe die cheaply. The most common way a complex program fails is that a probe becomes a commitment before anyone noticed, because it appeared on a roadmap with a date next to it. Keeping probes off the roadmap, and out of the milestone report, is a legitimate and undervalued program-management act.
Try this week. Take your largest active program and list its five biggest workstreams. Next to each, write "complicated" or "complex" and one sentence of evidence (for example, "we have done this three times before" versus "no one has shipped this to these users"). For every "complex," ask what a probe would look like that costs under a week and could visibly fail. If you cannot name one, you have found your real risk.
What it is. Small, deliberately diverse experiments run in a complex problem space to make emergent patterns visible, designed so that failure is cheap and informative. The Cynefin Co describes them as ways to let "the nature of emergent possibilities" become visible when analysis cannot settle the question.
When to use it. When you cannot get agreement on the answer because the answer does not exist yet: a new user behavior, a novel platform bet, an org change with unknown second-order effects, or any program where the last two plans were wrong in unpredictable ways.
How to run it:
When NOT to use it. In the chaotic domain (act first to stabilize) or the simple and complicated domains, where known good practice or expert analysis will beat experimentation.
Example: three two-week probes on a new approval workflow (one manual, one AI-assisted, one policy-only), reviewed together on day ten, with only the survivor getting a milestone.
Build to Learn vs Build to Earn — Marty Cagan, April 2026: prototypes in discovery, production in delivery, and a warning that cheap building makes discovery the bottleneck. The distinction is useful for any TPM deciding what deserves a milestone and what deserves a probe.
The Wardley Map Skill: what it is, how we tested it, what the benchmark found — Mark Craddock benchmarks a Claude Code skill that drafts Wardley maps against 25 of Wardley's own. A coarse-mapping tool, not a precision one; a good model of how to evaluate AI assistance honestly before you rely on it.
Build vs Buy in 2026: Using Wardley Mapping to Navigate the Agentic AI Shift — David Haberlah argues that workflow fit, not component maturity, now decides build versus buy, and that renewals deserve a prototype before a signature. Relevant to any leader with an annual SaaS renewal on the calendar.
"Instructive patterns emerge if the leader conducts experiments that can safely fail."
— David J. Snowden and Mary E. Boone, "A Leader's Framework for Decision Making," Harvard Business Review, 2007
Don't miss what's next. Subscribe to Critical Path: