Goodbye Double Diamond, hello Signature Diamond.

For twenty years, the Double Diamond has been the dominant mental model for product development. Two diamonds in sequence: the first for understanding the problem, the second for building the solution. Each one a cycle of diverge-then-converge, each one measured in months.

It is a good model. It was built for a world where building was expensive, where phases had to be sequential because no one could afford to do everything at once, and where the product triad — business, product, design, and engineering — had to hand work off to each other like a relay race.

That world is ending. And the relay race metaphor needs to go with it.

The Double Diamond encodes a hidden assumption: that problem-understanding and solution-building are separate activities that happen in sequence. You understand first, then you build. The triad is split across the timeline — business and research lead the first diamond, design leads the early second diamond, engineering leads the late second diamond, product manages the handoffs.

This made sense when building took months. You couldn't afford to have engineers in the room during discovery because they were needed elsewhere, building the last thing you'd decided. Phases existed because resources were constrained and time was long.

AI coding tools have changed the economics of the build phase so dramatically — from sprints to hours — that sequential phasing is no longer the optimal structure. And when you remove the constraint that forced the relay race, the right model looks different.

Not two diamonds. One.

One diamond where the four edges are what you continuously do: Decide, Build, Ship, Learn, clockwise — and the interior is what you continuously are: a team in an ongoing posture of discovery and definition, never leaving the problem space, always sharpening the understanding of what you're solving and why.

The interior: Discover and Define as permanent posture

In the Double Diamond, Discover and Define were phases. You completed them. You produced a brief, declared the problem framed, and moved into the second diamond. The research was done. The definition was set.

In the Single Diamond, they are not phases. They are the inside of the shape — the environment the team inhabits throughout every cycle, regardless of which edge is active.

Discover is about staying genuinely curious about the problem. Who has it, how badly, in what contexts, and why current solutions fall short. This requires ongoing user contact — not a quarterly research sprint, but a continuous low-level signal from the real world. Interviews, behavioral data, support tickets, sales calls. The team needs a live feed, not a snapshot.

Define is about staying honest about what success looks like. Not the product spec, but the underlying problem statement: what specifically are we solving, for whom, and how will we know we've done it? This definition should be legible to everyone on the team, and it should change when the evidence requires it. A definition that never changes is a sign you've stopped listening.

Together, Discover and Define form a continuous inner loop — not a phase you enter and exit, but a discipline you maintain. Every time you Learn something on the bottom edge, it feeds back into Discover. Every time you Decide at the top-left, you're implicitly updating your definition of what's worth building next.

The edges: the execution circuit

Where the interior is about understanding, the edges are about acting. Going clockwise:

• Decide (upper-left) is where the team determines what the next cycle will test. Not just what to build, but what hypothesis to build against. "If we make onboarding one step instead of four, we believe first-week retention will increase because the current drop-off happens at step two." A Decide without a hypothesis is just a to-do list.
• Build (upper-right) is where the hypothesis becomes real software. With AI coding tools, this edge has compressed from weeks to hours. A well-specified hypothesis goes from brief to deployed code in a single session. This is the edge that has changed the most, and its compression is what makes the whole model possible.
• Ship (lower-right) is where the software reaches real users — not a staging environment, not a recruited user test, but real people encountering real software in the context of their actual lives. This is the only kind of contact that fully counts. Staged feedback tells you what people say they think. Shipped software tells you what they actually do.
• Learn (lower-left) is where the team reads what actually happened. Not instinct, not assumptions about what users intended — behavior. What did they click? Where did they stop? What did they ignore? From that evidence, the next hypothesis begins to form, and the circuit returns to Decide.

Each circuit of the diamond is one cycle. In the old model, one cycle took months. In the new model, a cycle can take days. You run more of them, you learn faster, and you compound.

The triad and the diamond

The most significant practical implication of the Single Diamond is what it means for how the product triad, or quad, works together.

In the Double Diamond, each discipline had a primary phase. Business and research owned the first diamond. Design owned the development phase of the second diamond. Engineering owned delivery. Product managed across all of them. The structure of the work created the structure of the collaboration — which meant that at any given time, different parts of the team were working on fundamentally different things.

The Single Diamond disrupts this entirely — and in a good way.

• Product moves from phase orchestrator to hypothesis author. In the relay model, product's job was to translate between disciplines and manage handoffs. In the Single Diamond, those handoffs mostly disappear. Product's primary contribution becomes the quality of the hypotheses that drive each Decide — staying deeply inside the interior, close to discovery signals, sharp on the definition. The product manager is also the keeper of a living hypothesis backlog: a prioritized queue of things the team doesn't yet know but needs to find out, ordered by impact, confidence, and cost to test.
• Design moves from prototype producer to signal translator. In the old model, design's heaviest output was the artifact that handed off to engineering. In the Single Diamond, the Build edge is so fast that design's role shifts upstream: closing the loop between the Learn edge and the interior — translating behavioral data back into sharper problem understanding, and forward into the next hypothesis. Specifications still happen, but faster and lighter, because real users are providing ongoing validation.
• Engineering moves from implementation factory to build partner. When the Build edge took sprints, engineers were operationally decoupled from the team. When it takes hours, engineers can participate in Decide, in Learn, in the conversations that shape the next hypothesis — bringing a precise understanding of what's technically possible and at what cost. That knowledge should inform hypothesis selection, not just implementation.
• Business moves from quarterly stakeholder to cycle participant. In the old model, business input entered at the beginning and the end. In the Single Diamond, cycles are days — so business can engage at every Decide, with revenue hypotheses, market timing considerations, and cost-of-delay instincts, rather than waiting for a quarterly review of something already built.

The hypothesis backlog: the product manager's primary artifact

If the product manager's job is to author hypotheses and keep the team pointed at the right questions, then the hypothesis backlog is the artifact that makes that job legible and auditable.

A hypothesis backlog is not a feature backlog. A feature backlog says what to build. A hypothesis backlog says what to find out, and makes explicit what building something is expected to prove or disprove. The shift sounds subtle. In practice, it changes how every prioritization conversation happens.

Each entry follows a consistent structure, borrowed from three different traditions:

• The "How Might We" statement is the opening frame, drawn from design thinking. It holds the question open rather than collapsing it into a solution. "How might we help first-time users experience value before they complete signup?" is better than "add a preview to the onboarding flow," because it leaves room for solutions the team hasn't thought of yet.
• The hypothesis is the specific bet — a testable claim with a clear action, a predicted outcome, a direction of change, and a reason. Without the reasoning, you can't learn from a failed experiment, only register that it failed.
• The use case is what makes the hypothesis buildable — a sequence of events the user and system go through together, with a main success scenario and extensions for edge cases. Writing it before building surfaces ambiguity, catches edge cases early, and gives engineering a precise target. It is not a full specification; it is a shared mental model, light enough to write in an hour and precise enough to build against.

The hypothesis backlog gives the Decide edge something to pull from rather than something to invent from scratch. At each Decide, the conversation becomes: which of these is most worth testing this cycle? That is a far better conversation than: what should we build next?

What the interior asks of the triad

In the old model, discovery was often delegated. Research was something a researcher did and reported back on. The interior was not really shared — it was processed by one function and handed to the next.

In the Single Diamond, the interior has to be genuinely shared. Everyone on the triad needs contact with the raw signal — the actual user, the actual data, the actual behavior — not a summary filtered through someone else's perspective. Business needs to hear what users say about price and value directly. Engineering needs to understand why users struggle with the current flow, not just receive a spec that addresses it. Design needs to understand the commercial constraints, not just the user needs.

A team that shares the interior makes better hypotheses. They catch each other's blind spots. They argue better. They're less likely to build something that works for users but not the business, or that achieves the business goal but fails users, or that's technically elegant but misses the point entirely.

The cadence: from two weeks to one

Most enterprise product teams currently work in two-week sprints. The two-week cycle made sense when building took most of the sprint. With AI-assisted development compressing the Build edge from days to hours, two weeks is too long. The team spends most of the first week in planning and coordination, then rushes in the second. Worse: a two-week cycle answers one question per fortnight. In the same period, a team running the Single Diamond could run five to ten cycles and answer five to ten questions.

One week is short enough to feel urgent and real, long enough to do genuine discovery and build something worth shipping. It maps naturally to the working week, and it matches the rhythm of how people actually think about time — a week has a felt beginning and end in a way that a two-week block does not.

For teams transitioning, the first adjustment is narrowing scope. One week forces the team to identify the smallest build that would meaningfully test the hypothesis — which is almost always a better test than the larger build the two-week sprint would have produced, because it's faster to learn from a small, sharp experiment than from a large, diffuse one.

The temptation, and the antidote

The temptation of AI-assisted development is to run the diamond so fast that the interior becomes invisible. If a hypothesis-to-shipped-software cycle takes four hours, it's easy to treat the Decide edge as instantaneous — a quick standup decision, a gut call — and skip the interior work that should be informing it.

This is how you build the wrong thing at speed. Rapid cycles without a live interior are just expensive busywork dressed up as agility.

The antidote is structural. Someone on the triad — usually product, often with design — needs to own the health of the interior as an explicit responsibility: maintaining the hypothesis backlog actively, writing How-Might-We statements before hypotheses ossify into feature requests, keeping use cases current so that what the team is building against is always legible to everyone.

The shape of the new collaboration

The Single Diamond is, in the end, a different theory of how people with different expertise should relate to each other while building products. The relay race theory says: do your phase, then hand off to the next discipline. The Single Diamond theory says: stay in the room for the whole circuit, bring your specific expertise to every edge, and never leave the problem space.

One diamond. Four edges. One interior. One team. One week.

The relay race was a sensible adaptation to the constraints of expensive, slow building. Those constraints are dissolving. What replaces them — a team that shares the interior, moves around the edges at pace, and compounds its learning week by week — is built for what building actually costs now.

Find your edge on the diamond

The Single Diamond is a team's shape — but no one person lives in all of it at once. Each of us is pulled toward different parts. Some are never quite satisfied in the interior, always sharpening the problem. Some come alive on Build, turning a clear hypothesis into working software by the afternoon. Some have an instinct for Ship — for getting real work in front of real people. Some do their best thinking on Learn, reading the evidence for what it actually says. A strong team needs all of it, and the overlap (and the friction) between those instincts is where good products get made.

Your CliftonStrengths are a surprisingly good map of where you naturally create value on the diamond. Strengths like Learner and Input lean into the interior; Strategic and Futuristic toward Decide; Achiever and Focus toward Build; Activator and Communication toward Ship; Analytical and Deliberative toward Learn. Naming your own shape honestly is the first step to placing yourself where you're strongest — and to building a team whose diamonds complement each other instead of collide.