Watch almost any talk about AI and product right now and you land in the same place. PRD to code. Harnesses that keep agents from shipping slop. How to take a spec and turn it into a codebase that scales, stays compliant and survives contact with real users. It is a fair thing to care about. The concern is real, the work is hard and the people doing it are solving genuine problems.
But it is the last third of the story. And we are treating it like the whole thing.
The part everyone is excited about is product delivery. Getting from a written spec to a working increment. That matters, but it sits at the end of a much longer chain that starts with two questions delivery never asks. What should we build and why. Those two questions are where AI changes the work most and they are the part of the conversation almost nobody is having.
I have been mapping the whole chain rather than the delivery slice and the shape I keep coming back to is three diamonds.
Why diamonds and why three
If you have seen the double-diamond model from design thinking, you already have the intuition. A diamond is an expansion followed by a contraction. You open up, explore widely, then you prune down to a decision. The classic version has two diamonds, one for the problem and one for the solution.
I think the AI era pushes this to three and I think the boundaries between them matter more than the diamonds themselves. Each point where a diamond closes is a clean handoff. Everything converges, produces one artefact and passes that artefact to the next stage. Strategy discovery, product discovery, product delivery. The first asks why. The second asks what and how. The third builds it.
The reason this is worth saying out loud is that the same AI tooling reshaping the third diamond is reshaping the first two just as hard and the changes are coupled. You cannot fix how you build without rethinking how you decide what to build, because the cost of being wrong has collapsed and that changes the whole economics of deciding.
Diamond one, strategy discovery
You start with an idea. It comes from the business, from a client or from somewhere out in the market. The expansion phase is market analysis in the broad sense. Who is competing, what business model could fit, whether there is real demand or just a story you have told yourself. You run several lines of investigation at once and you let them sprawl. Then you contract. You prune the branches until one strategic approach is left standing.
The output is not a roadmap. It is a product vision canvas, the one Roman Pichler describes. A single page, or a few if you need them, naming the vision, the target clients, the handful of features that actually move the business outcome and the outcome itself. Deliberately not a delivery plan. The point of the canvas is to carry intent forward without prematurely committing to execution.
Here is where AI already bites, quietly. The expansion phase of strategy discovery used to be slow and expensive, so people did less of it and committed earlier. With a capable agent doing competitive sweeps, pulling business-model comparisons and stress-testing demand signals, you can keep more branches open for longer before you prune. Every time a stronger model lands it is worth re-running the strategy questions you gave up on last quarter, because the market that was closed to you then may not be closed now. That is a real shift in how the first diamond behaves and it never comes up.
Diamond two, product discovery
This is the diamond AI changes most and it is the one the discourse skips almost entirely.
You take the vision canvas and you expand again. Most of the time, even when the vision is clear, how to reach it is not. So you prototype. Not one prototype but several. Not variations on a theme but fundamentally different bets. Different interfaces, different interaction models, different backend shapes, different data models. People are already doing the crude version of this and calling it vibe coding, though there are better tools for it than that name suggests. The principle is what counts.
None of this reaches production. I want to be blunt about that because it is the failure mode that ruins everything downstream. The code generated here is throwaway by design. It exists to validate, nothing more. Each prototype is measured against success criteria you set in advance, then run with real users so you collect feedback against a defined idea of what good looks like. You prune the bets that fail and you expand the ones that work into another round, until you have enough clarity to commit.
The value AI brings here is simple to state and large in effect. You can try several genuinely different approaches, fast and cheap. You collect feedback at a speed that was never available before. The old constraint was that building a prototype good enough to test cost real time, so you tested one or two ideas and called it discovery. Now you can test five. Three of them can be wrong and being wrong costs you almost nothing.
The output of this diamond is what currently lives in a product owner’s head and a backlog. A roadmap, a set of specs, a prioritised list sharp enough that both the PO and the developers know what to build and how. This is the artefact that finally earns the word spec.
I want to flag the trap, because I have watched it spring. A prototype that dazzled in the demo will fall over on launch if you let it through. The whole point of keeping diamond two sandboxed is that the thing validating the idea is not the thing shipping the idea. Confuse those two and you have shipped slop wearing a prototype’s clothes.
Diamond three, product delivery
This is the part everyone is already talking about, so I will keep it short.
You take the specs and the backlog and you build, item by item, with proper testing, quality assurance and evaluation at each step. You expand into the work, then you contract onto a polished, releasable increment. First time round that increment is your MVP. After that it is the next version. The harness work, the agent discipline, the guardrails against unreliable code, all of it lives here and all of it is worth doing well.
My only point is that delivery is the third diamond, not the first. A brilliant delivery engine pointed at the wrong thing just gets you to the wrong place faster.
The feedback loops are where it gets interesting
A framework that only flows forward is a slide deck. The real behaviour is in how feedback from a shipped increment routes back, because it does not all return to the start. It returns to a different point depending on what kind of feedback it is.
A bug goes straight to the specs point, just before the third diamond. An agent harness picks up the report, which by the way is often better written when an agent files it than when a human does, then fixes the code. No grand re-evaluation required.
A piece of product or user-experience feedback is checked against the vision canvas first. If the vision still holds, the feedback opens a new branch back in diamond two, spinning up fresh prototyping paths that eventually produce updated specs. You are not restarting. You are re-entering the chain at the discovery stage with a sharper question.
A genuinely new idea or a strategic pivot routes all the way back to diamond one for a fresh strategy pass. This is the expensive path and the framework’s job is to make sure you only take it when the feedback actually warrants it, rather than treating every complaint as an existential rethink.
Backlogs sit across all of this, which is the detail people get wrong. A Jira or Notion or Azure board item is not a diamond-three artefact. A product backlog item can be a bug late in the flow, a spike or investigation in diamonds one and two, or a feature in diamond three. The tool does not decide which stage you are in. The nature of the work item does.
What this means for the people doing the work
There is a quieter shift underneath all of this and it is the one I find most interesting. The product manager and the developer roles are merging. The old arrangement, where a PO handled stakeholders and discovery then handed a clean spec across a line to developers who built it, assumed those were separate jobs done by separate people. When one person can carry an idea through strategy, prototype three versions of it over a weekend and ship the increment with an agent doing the typing, the line stops being a line.
The skills that survive this are the ones the first two diamonds reward. Figuring out what to build. Figuring out whether it is any good. Figuring out which problem is worth solving at all. The building is increasingly done for you. Which is exactly why I think the obsession with the third diamond is misplaced. We have automated the part that was already the most mechanical and we are spending all our attention there, while the genuinely hard, genuinely human work has moved upstream to the two diamonds nobody is filming.
So when the next talk opens with how to get from PRD to clean code, it is worth asking the quiet question. Who decided that was the right PRD and how much cheaper is it now to find out they were wrong before a single line gets written.