The product loop

When building was expensive, it made sense to treat discovery and delivery as sequential phases: figure out what to build, build it, measure it. AI collapsed the "build it" phase, and now the other two run continuously. The teams winning today are the ones with the tightest loops.

#What was the old model, and why did it work?

For most of the history of software product development, teams organized around a roughly linear process. Discovery came first: research users, identify problems, generate ideas, prioritize a roadmap. Delivery came second: build the features, test them, ship them, measure the results.

This worked because delivery was the bottleneck. Building took long enough that discovery had to happen in advance. You couldn't afford to build something, discover it was wrong, and start over. So teams invested heavily in upfront research, planning, and alignment to increase the odds that what they built would work.

The linear model had a second, less appreciated benefit: it created time for reflection. The handoff between discovery and delivery was a natural point to reconsider assumptions, check whether the market had shifted, gut-check whether the thing you were about to spend weeks building was still the right bet.

#What changed?

AI compressed the delivery phase. Features that took weeks now take days. Prototypes that required an engineering sprint now come together in an afternoon. The cost of building dropped enough that the economic logic of the linear model stopped holding.

When building is cheap, you don't need to get discovery right before you start building. You can build a prototype, expose it to users, learn from their behavior, and iterate, all within the time a single discovery phase used to take. The "build, then measure" part of the process becomes fast enough to run inside what used to be the "discover" phase.

At the same time, the "measure" phase doesn't end when you ship. A feature that went live yesterday is generating behavioral data today. Users are adapting, finding workarounds, using the feature in ways you didn't predict. That behavioral signal is discovery material: it tells you what to build next, what to fix, what to remove.

Discovery and delivery stop being phases and start being a loop.

#What is the product loop?

The product loop is a mental model for how product development works when building is cheap. It has four turns:

Generate. Form ideas grounded in what you already know: prior experiment results, user behavior data, qualitative feedback, strategic context. The quality of ideas entering the loop depends on the quality of learning from prior cycles.

Shape. Turn ideas into testable hypotheses with explicit predictions. What do you expect to happen? What metric would change? What would prove you wrong? Then build the minimum implementation needed to test it. This is where AI-assisted development has its biggest impact: hypothesis to testable prototype in hours, not weeks.

Validate. Expose the hypothesis to reality. This could be a full A/B test with statistical rigor, a limited rollout with monitoring, or a lightweight user study. The level of rigor should match the risk and reversibility of the decision.

Learn. Interpret the results, update your understanding of users and product, feed that learning back into generation. This is the step most teams skip or rush. If the learning from this cycle doesn't meaningfully inform the next cycle's hypotheses, the loop is spinning without compounding.

Good product teams have always iterated. What's new is that AI compressed the "shape" phase enough to make the loop the default mode rather than something only fast teams could sustain. And that shift moved the constraint: from "how fast can we build" to "how well does each turn inform the next."

#Why does loop quality matter more than loop speed?

Two teams can build at identical speeds and produce radically different product outcomes, because what matters isn't how fast the loop turns but how much learning transfers between turns.

We've seen this at Spotify. The Search team's experimentation maturity arc (documented on the engineering blog) showed that moving from "run individual experiments well" to "connect experiments to each other and measure cumulative impact" changed not just the quality of their experiments but the quality of the ideas entering the pipeline. The learning compounded.

The metric that matters is learning per cycle, multiplied by cycles per unit of time. Build speed only affects the second term. Experimentation infrastructure, learning culture, and the quality of the team's interpretive processes affect the first.

Investing in experimentation methodology (variance reduction, sequential testing, guardrail metrics, structured decision frameworks) produces outsized returns. These investments don't make the loop turn faster. They make each turn produce more reliable learning, which compounds across every subsequent cycle.

#How does this change how teams work?

The linear model organized teams around handoffs. Discovery happened in one context (research, design, product), delivery in another (engineering, QA, release), measurement in a third (analytics, data science). Each handoff was a point where context was lost, assumptions were translated imperfectly, and cycle time accumulated.

The product loop demands a different structure. The same people, or the same tightly integrated team, need to be involved across all four turns. The person generating the hypothesis needs to understand the prior experiment results. The person interpreting the experiment needs to understand the hypothesis well enough to judge whether the result is meaningful. The person deciding what to build next needs access to the learning from what was built before.

That doesn't mean everyone does everything. It means the boundaries between roles become more fluid, and the information that flows between stages needs to be structured, accessible, and honest. A team running a tight product loop can't afford a two-week handoff between "experiment completed" and "results interpreted." The learning needs to feed back within the same cycle, or the compounding breaks down.

#The hardest part is the learn step

Most teams know how to generate ideas. AI has made shaping them into testable prototypes fast. Validation infrastructure is better than it's ever been.

The learn step is where most loops break. Results come in, someone skims the dashboard, the team ships or kills, and moves on. The question "what did this teach us that should change what we do next?" doesn't get asked, or doesn't get asked with enough rigor to change behavior.

Map your current loop. How long does it take for the learning from one experiment to influence the hypothesis of the next experiment? That's your cycle time. If it's measured in months, you're running a linear model regardless of what your team structure chart says.

Compress the shape phase, not the learn phase. AI tools make it easy to compress building time. The temptation is to compress everything. Resist compressing the interpretive step: the time spent understanding what an experiment actually showed and what it means for your product. The compounding happens there.

And match rigor to risk. Not every turn of the loop requires a fully powered A/B test. Some hypotheses can be validated with a lightweight rollout and monitoring. Others require rigorous statistical evidence because the decision is high-stakes or hard to reverse. The loop runs faster when you match the validation method to the question.

#FAQ

Is the product loop just agile with a new name? No. Agile organizes delivery into iterative sprints but typically treats discovery as a separate, sometimes ad hoc, activity. The product loop integrates discovery and delivery into a single continuous cycle where each turn's output feeds the next turn's input. The emphasis is on learning compounding across cycles, not on delivering working software in time-boxed increments.

Can the loop run too fast? Yes, if speed comes at the expense of learning quality. A loop that turns weekly but produces unreliable experiment results (underpowered tests, no guardrails, post-hoc rationalization) is worse than a loop that turns monthly with trustworthy evidence. Speed without learning is just churn.

How does this apply to teams that don't run A/B tests? The validation step doesn't require A/B tests specifically. It requires some mechanism for exposing hypotheses to reality and generating honest feedback. That could be a statistical experiment, a limited rollout with monitoring, a structured user study, or even a support ticket analysis. The important thing is that each cycle generates evidence that updates the team's understanding.

What role does AI play in the loop beyond faster building? AI can assist in every phase: generating hypotheses from data, drafting experiment designs, summarizing results, surfacing patterns across past experiments. But the judgment, which hypotheses to pursue, how to interpret ambiguous results, when to pivot or persist, remains human. AI accelerates the loop. It doesn't replace the judgment that makes the loop valuable.