2026-10-07
October 7, 2026
Your kickoff deck is a Define-phase artifact. If nobody ran Discover first, you have converged on a guess.
Look at what a typical program charter contains: a problem statement, a scope, a milestone plan, a RACI. Every one of those is a convergent artifact. They exist to narrow options and commit people. That is exactly right for the second half of the work, and exactly wrong as the first thing you write down.
The Design Council's Double Diamond has been making this point since 2004: good work diverges and converges twice. First you widen your understanding of the problem and narrow it to a defined challenge. Then you widen the space of solutions and narrow to one you deliver. Most engineering programs run only the second diamond. The first one happens in a hallway, in a leader's head, or in a planning doc written in a week, and then it gets laundered into a charter that looks like a decision.
The TPM is the person best placed to notice. You are the one who sees the program six months in, when the thing that is on time is also the thing nobody wants. Today's issue is about making the first diamond a deliberate, scoped, visible phase of the program rather than something you hope already happened.
The Double Diamond is the Design Council's best-known visual: four phases, Discover, Define, Develop, Deliver, drawn as two diamonds side by side. The Council launched its Framework for Innovation in 2004 and has since added principles (put people first, communicate visually and inclusively, collaborate and co-create, iterate) and a methods bank grouped as Explore, Shape and Build. The Council is explicit that the process is not linear; teams loop back as they learn. Programs mostly draw it as a line anyway.
Here is the failure pattern. A leader senses a problem ("our platform is too slow to adopt"). A small group converges on a framing in days ("we need to migrate to the new platform by Q3"). That framing becomes the charter. Everything downstream, the staffing, the dependencies, the status reports, optimizes delivery of the framing. When the framing is wrong, the program is a high-quality answer to the wrong question, and the first diamond's divergence, the part where you would have discovered that, never happened.
Three things make this worse at program scale than at team scale.
First, the people who feel the problem are not in the room. In a product team, discovery means talking to customers. In an internal program, the "customers" are other engineering teams, SREs, security reviewers, support. They are diffuse and busy, and their incentives are not yours. A migration program that never interviews a consuming team about what they are actually trying to get done will discover their real constraints during the cutover, which is the most expensive time to learn anything.
Second, convergence is socially rewarded and divergence is not. Leaders reward the person with the plan. A TPM who says "I need two weeks before I can commit to a scope" sounds slow. So the first diamond is skipped not for lack of knowledge but because the organization does not have a respectable name for it. Give it one. Call it a discovery phase with an exit criterion, put it on the roadmap, and give it a date. The exit criterion is what makes it respectable: "We exit Discover when we can state the problem in the language of the three teams who feel it, and each has confirmed it."
Third, the Define step is where most of the leverage sits, and it is routinely a single sentence. The point of the first diamond's second half is a reframed, specific challenge, not a restated request. "Migrate to Platform X" is a solution. "Teams cannot ship a service change without a two-week environment queue" is a problem. Programs that carry a solution as their definition cannot be wrong in a useful way; they can only be late.
What does a lightweight first diamond look like for a Staff-level TPM with no mandate to "do design"? Keep it small and time-boxed. In the Discover phase, spend one to two weeks on eight to twelve conversations across the teams affected, using a structured interview rather than a survey. (Today's Method, the Jobs-to-be-Done switch interview, is built for exactly this.) Capture what people were doing before, what triggered them to look for something different, and what is stopping them. In Define, synthesize on one page: the job being done, the forces blocking progress, and a problem statement a consuming team would recognize as theirs. Share it back to the interviewees before you share it upward. That one step converts skeptics into co-authors.
Only then enter the second diamond. Develop is where options live: two or three candidate approaches, each with the assumption it depends on. Deliver is where the usual machinery (milestones, RACI, risk registers) finally earns its keep, because now it is attached to a validated target.
A fair objection: this adds time. It does, up front, and it removes it later. A rough, honest rule of thumb is that rework discovered at cutover costs an order of magnitude more than the same insight learned in an interview. You do not need a precise ratio to see the shape of the trade; every TPM has lived through a launch where "we didn't know the payments team needed that" surfaced in the final month.
A second objection: AI has made building cheap, so skip discovery and just build. Marty Cagan's recent writing argues nearly the opposite: when prototypes cost almost nothing, the scarce resource shifts to knowing what deserves building. If agents can generate the migration tooling in a week, the bottleneck is no longer delivery. It is whether the target was right. The first diamond is where you spend your newly cheap capacity on the question that is still expensive.
One more practical note for leaders above the TPM: ask for the first diamond by name. "What did we learn in Discover, and who confirmed it?" is a question that changes how programs get started. If the answer is "we had a planning offsite," you have found a converged guess.
Try this week. Pick one program currently in planning or early execution. Write its charter's problem statement on a single line, then list the three teams who actually feel that problem. Book 30-minute conversations with one person from each, and ask only: "Tell me about the last time this got in your way. What did you do instead?" Bring back what you hear before the next steering review.
What it is. A structured interview technique from the Jobs-to-be-Done tradition, popularized by Bob Moesta, that reconstructs why someone switched (or refused to switch) to a new solution. It treats a solution as something people "hire" to make progress in a situation, and maps the decision as four competing forces: push and pull toward change, anxiety and habit resisting it.
When to use it. At the start of any program that asks other teams to adopt something: a platform migration, a new tool, a process change, a deprecation. Use it in Discover, before you commit to a scope or a rollout plan.
How to run it:
When NOT to use it. When the decision is mandated and nobody can decline (a security deadline, a regulatory cutoff); there the useful question is how to ease the transition, not why people would switch.
Example: a team that "resists" a new CI system often turns out to be anxious about losing an undocumented workaround, a force no benefits slide will touch.
Experts Lead Experts — Marty Cagan (Sept 25, 2026) argues that leaders who stay hands-on with new technology, AI included, outperform leaders who manage at a distance. For TPMs and directors, it is a reminder that you cannot run a credible discovery phase on a domain you do not understand.
The state of the tech industry in 2026 — Gergely Orosz's keynote snapshot (Oct 6) says most productive engineers now run several parallel agents and that code review is straining under volume. If building and reviewing change this fast, deciding what to build is the part of your program that most needs human rigor.
The Double Diamond / Framework for Innovation — The Design Council's current page on the framework, including its principles and methods bank. Worth a read to see how much more the framework contains than the diagram people reuse.
"Plans are worthless, but planning is everything."
— Dwight D. Eisenhower
Don't miss what's next. Subscribe to Critical Path: