2026-05-13
May 13, 2026
Most TPMs only show up for Develop and Deliver. The job at staff level is to be in the room during Discover and Define — when the program is still a hypothesis.
Walk into any planning room and watch what happens when the Double Diamond gets mentioned. Designers nod. PMs nod harder. The TPM, almost always, is looking at the Gantt chart on the second monitor — the one with milestones, dependencies, and a launch date already pinned to Q3.
That instinct is exactly where the staff-promo conversation goes sideways.
The Double Diamond — the discover-define-develop-deliver model formalized by the British Design Council in 2005, refined again in 2019 — is two diamonds, not one. The first diamond is divergent exploration of the problem space, followed by convergent definition of the right problem. The second is divergent ideation followed by convergent delivery. Most TPMs operate exclusively inside the second diamond. They take the problem as given, scope the work, run the program, ship the thing. That's tactical execution. It's necessary. It is not, by itself, staff+ work.
Senior TPMs — and the tech leaders they report to — earn their seat by showing up in the first diamond, when the program is still a hypothesis. That's the room where a quarter of engineering capacity gets locked in for two quarters based on assumptions that nobody has stress-tested. That's the room where "build vs. buy" gets decided before anyone has mapped what's actually a commodity. That's the room where a peer leader says "we need to do X" and the right move is not to scope X but to ask whether X is the right shape of problem to be solving.
There's a long-running tension in the TPM craft between discovery and delivery. Marty Cagan made the framing canonical fifteen years ago at SVPG: product discovery is figuring out what's worth building; product delivery is building and shipping it. The two activities run in parallel, not in sequence, and they require different rhythms, different skills, and often different rooms. Cagan's recent point — sharpened in his "Product Management Theater" conversation on Lenny's podcast — is that organizations frequently strip PMs of discovery, hand it to TPMs to "coordinate," and end up with neither group doing it well.
For senior TPMs and tech leaders, this is an opportunity, not a complaint. The discovery half of a program is where the highest-leverage decisions happen — and where most large engineering investments quietly go wrong.
Three places the discovery diamond pays off for technical programs.
First: problem framing. The Discover phase isn't "go talk to users" — that's a product activity. For a technical program, it's "what is the actual problem we're trying to solve at the system, org, or operating-model level?" A migration program framed as "move us off the old stack" delivers very different work than the same program framed as "reduce mean time to integrate a new service from 12 weeks to 1." Same engineering, radically different scope, very different success criteria. Senior TPMs do this reframing in the first week. Junior TPMs accept the brief and start drawing the Gantt.
Second: opportunity mapping. Teresa Torres's Continuous Discovery Habits (2021, now turning five and being re-read in a Product Talk book club through May 2026) introduced the opportunity solution tree — a structure that pins one outcome at the top, branches into customer opportunities, then enumerates candidate solutions and the assumptions each one rests on. The original framing is product, but the structure travels. Replace "customer opportunities" with "leverage points" or "constraints to relax" and you have a discovery artifact that works for platform programs, infrastructure migrations, AI governance rollouts, and reorgs. The point isn't the tree shape. The point is forcing the team to articulate what they don't know before committing capacity.
Third: mapping the landscape. Simon Wardley's value-chain mapping is the discovery tool I keep seeing senior TPMs underuse. A Wardley map plots components of a value chain (Y axis: visibility to user) against their stage of evolution (X axis: genesis → custom → product → commodity). Run one at program kickoff and the question of what to build, what to buy, and what to ignore stops being a debate and starts being an observation. David Haberlah's recent piece on agentic-AI build-vs-buy in 2026 walks through this for AI programs specifically — useful template for anyone scoping an AI strategy program right now.
What this looks like in a real program.
A frontier-AI infrastructure program lands on your desk. The brief: "We need to scale our experiment platform 3x by year-end." A delivery-mode TPM accepts the 3x target and starts capacity planning. A discovery-mode TPM asks: what's the actual job the experiment platform is being hired to do? (Jobs-to-be-Done framing — Tony Ulwick's articulation: functional job, emotional job, social job.) For an AI lab, the functional job is "let researchers run more experiments faster." The emotional job is "make me feel my career is not bottlenecked by infra." The social job is "let me publish results my peers respect." Frame the program against those jobs and the work shifts: 3x capacity is one possible solution, but so is reducing experiment setup time, so is changing queue prioritization, so is shipping the right observability so a researcher knows their run is healthy at hour 3 instead of hour 18.
Same brief. Different program. The discovery work changes which engineers you need, which vendors you call, and what you stop doing. None of that is in the Gantt.
The failure mode is not skipping discovery — it's running it ceremonially. TPMs who hold one "kickoff workshop," fill a Miro board, and call it discovery have done worse than nothing — they've inoculated the org against doing the work seriously. Real program discovery is days, sometimes weeks. It looks like interviewing the actual operators of the system being changed (not just the leaders sponsoring the change), sketching a Wardley map and rejecting the first three versions, and running assumption tests against the riskiest beliefs in the plan before committing capacity. It looks a lot like Steve Blank's "get out of the building" — but the building is your own engineering org.
Try this week. Before your next program kickoff, write the program brief as a one-paragraph hypothesis — "We believe that {investment} will move {outcome} for {stakeholder} because {assumption}" — and identify the three assumptions in that sentence most likely to be wrong. Make stress-testing those three assumptions your first week of work. Not workshopping. Testing.
What it is. A visual structure that connects a single desired outcome to the customer opportunities (or, for technical programs, leverage points) that might move it, then to candidate solutions, then to the assumption tests required to validate each. Introduced by Teresa Torres on Product Talk in 2016 and formalized in Continuous Discovery Habits (2021).
When to use it. At program kickoff when the outcome is clearer than the path; whenever a leader hands you a solution and asks you to "go execute" before the problem is articulated; any time you need to expose hidden assumptions in a plan before capacity is committed.
How to run it:
When NOT to use it. When the outcome is genuinely fixed and non-negotiable (incident response, regulatory deadlines, compliance), or when you've already invested heavily and the cost of restructuring is higher than the cost of pushing through. Discovery is a sunk-cost-fighting tool, but it has its own sunk costs once you're far in.
One-line example: an infrastructure team running an OST on "reduce on-call burden by 30%" found that two of their four opportunities (better runbooks; reduce alert volume) had two assumption tests each that could be run in a week — and one of those tests killed half the original solution space before any engineer was assigned.
Anthropic is hiring a TPM, Discovery — The job title itself is the news: frontier AI labs are now naming "Discovery" as a discrete TPM domain, separate from delivery. Read the JD for a glimpse of what discovery looks like at the research/infra boundary — compute planning, RL-environment health, vendor pipelines. The shape of the role is the shape of the work.
Building better platforms with continuous discovery — Stack Overflow's engineering team on how platform teams use Torres-style continuous discovery to figure out what internal users actually need before shipping a developer tool. Useful read for anyone running a platform program.
Wardley Mapping for Operators: From Map to Operating Cadence — Antoine Buteau's recent operator-focused Wardley mapping series is one of the better practitioner walk-throughs I've read this year. The "operating cadence" installment is where to start if you're trying to get a Wardley habit going inside an existing program.
"There are no facts inside the building, so get the hell outside."
— Steve Blank
Don't miss what's next. Subscribe to Critical Path: