The Impact Loop

The short version

• The Impact Loop is how the AI-era product org runs: customer, spec, build, story, adoption, and back to customer.
• When agents can take a spec to working software in a day, speed inside any one stage stops being the constraint.
• The constraint is the handoffs between stages, and every handoff that crosses a reporting line is a wait.
• So the loop runs as one system with one owner, the CPO, and five seats working it: forward deployed engineering at the customer edge, product on the spec and the build, design on the behavior and the quality bar, and product marketing on the story and adoption.
• Each stage gets one measure, read weekly by the seat that owns it. The CPO reads all five together and answers for one number. This is the chapter the rest of The Product OS hangs on.

Five stages, one loop

Here's the loop, and what done looks like at each stage.

Customer. Field signal from deployments, support conversations, and usage, read daily. Agents do the reading. A person decides which signal matters this week. The richest source is the field itself: the forward deployed engineer who watched the workflow fail, and the support agent's conversations it couldn't resolve. Those are a spec backlog nobody had to write. Part 7 of the CPO Transition makes the case that this signal belongs inside the product org, because whoever owns the reporting line decides who reads it.

Spec. The problem, the behavior, the claim, and the eval that says it works, in one place next to the code. The Product Builder owns the problem and the definition of good. Design owns the behavior, the states around an answer nobody can predict. Product marketing owns the alternatives and the claim a skeptical buyer will believe. The PM and the PMM write one file, and the eval is the spec.

Build. Agents and Product Builders take the spec to working software. Hours, not sprints. The build is the cheapest stage now, which is the whole reason the loop changed. Instant Prototyping covers the technique. The job at this stage is holding the checkpoint, not typing the code.

Story. Positioning and proof that buyers, sellers, and AI assistants read. More and more, the first reader is a machine: a buyer's agent, an assistant answering a question about your category, your own sales agent. So the story ships with the build or it's wrong. Product marketing reports to the CPO for exactly this reason.

Adoption. The outcome number moves, or the loop runs again. Adoption is where the loop closes and where it restarts, because what customers do with the change is the next round of field signal.

Then it wraps. Adoption feeds customer. The loop doesn't stop for planning, and it doesn't wait for a quarter.

One measure per stage

A loop you can't measure at each stage turns back into a relay race, where everyone reports their own leg and nobody owns the finish. So each stage gets one number, owned by one seat and read weekly.

Each of these came out of a seat's own argument. The hop count is from the field reports to product: pull the last ten field requests that shipped, and write down the date heard, the date shipped, and how many reporting lines each one crossed. The pass rate is the Product Builder's scorecard in part 1 of the PM Transition. The repair rate is design's number from the Design Transition, read by surface with a sample of the real conversations. The story check is the simplest of the five, and the one most teams can't answer today.

Notice what's missing. Specs shipped, story points, launches run, and engagements closed. Those count activity in one seat. Agents made most of that activity cheap, so counting it tells you very little about the outcome.

One owner, or the loop waits

When building took months, handoffs were rounding error. Now a prototype costs a day, and the wait between two reporting lines can take longer than the build. That's the case part 6 of the CPO Transition makes, and the Impact Loop is where it gets practical.

Run the one-owner test. Pick the outcomes your board cares about most. For each, write the executive who owns each of the five stages. If a row has more than one name, the loop is split, and each extra name is a handoff the outcome sits in.

The fix isn't a bigger CPO for its own sake. It's that the only seat that can trade a day of build for a day of story, or pull a forward deployed engineer's finding into this week's spec, is the one that holds every stage. That's why product, design, product marketing, and forward deployed engineering run the loop together under the CPO, and why the CPO answers for one number instead of four reports.

How the week runs

The loop runs continuously, but people still need a rhythm. Here's the one I'd set.

Every morning. An agent reads the field: new support conversations it couldn't resolve, deployment notes, usage anomalies, and what changed in how assistants describe your category. It hands each seat a short brief. Each seat picks at most one signal worth acting on. Continuous Discovery on Autopilot covers the sensing setup.

The same day. The signal becomes a spec row: the problem, the behavior, the claim, and an eval case that fails today. The build starts against that row.

Within the week. The change ships with its story. The release note, the claim, and the agent-read docs go out in the same release. Then the stage measures update on their own.

Once a week. The four seats and the CPO read the five measures on one page. Not a status meeting. A review of which stage is slowest this week, and one decision about it. Kill the Status Meeting explains what to drop to make room.

Most turns of the loop end in a kill, and that's fine. A change that didn't move the number gets removed, and what you learned goes back into the spec as an eval case, so the next build doesn't repeat it. Killing fast is part of the loop. Keeping dead features costs every future build.

What I expect

These are my predictions, not facts.

By the end of 2027, the weekly product review at AI-native software companies reads one page of stage measures, and the slowest stage, not the loudest request, sets the week's priority.

Within two years, the measure boards ask CPOs about is a loop time: days from a field finding to the outcome number moving. Companies that can't produce it will find out their loop is split.

By 2028, the eval suite, the messaging file, and the field log live in the same repository, because agents read all three on every build and they go stale the moment they live apart.

One thing to try this week

Pick one outcome. Write the five stages down the side of a page. Next to each, write the owner, the measure, and the last time anyone read it. Any blank is your first fix. Then take one real field finding from this week and run it through the full loop, timing it from the day you heard it to the day the number moved. That single timing tells you more about your org than any reorg deck.

Part of The Product OS. The CPO's side of the argument runs in The CPO Transition, and each seat's page shows its own stage: Product, Design, Product marketing, and FDE.