Escalation Loops

For a long time I thought building products was mostly about making better decisions.

Do enough research. Understand your users. Design the best system you can with what you know. Build thoughtfully. Observe the results. Repeat.

I still believe all of those things.

Planning matters. Product discovery matters. The work that Marty Cagan and many others have done to establish discovery as a discipline fundamentally changed the way I think about building products. Learning before building, validating assumptions, observing behavior instead of relying on opinions—those ideas have become foundational to modern product development, and for good reason.

The observation that eventually became Escalation Loops came much later. It wasn't something I saw as an alternative to discovery or planning. If anything, it grew out of trying to practice both as thoughtfully as I could. Over time I found myself noticing something that I didn't have a good explanation for. Discovery wasn't simply helping me understand the product. It also seemed to be changing the product itself. Once that happened, many of the questions that had originally shaped the work no longer felt like the most interesting questions to ask.

It took me years to realize that this wasn't unique to one project.

The pattern kept repeating.

At first I assumed it was simply part of software development. Different products have different users, different constraints, and different goals. Of course they evolve over time. That explanation felt sufficient for a while.

The more products I worked on, though, the less satisfying it became.

Whether I was working in mobile games, creator platforms, digital collectibles, advertising, loyalty, or independent projects, I found myself experiencing the same thing. We would spend weeks or months trying to understand a problem, carefully think through the system we wanted to build, and then discover that the act of introducing that system into the world had fundamentally changed the context we were trying to understand.

I don't mean that we had been wrong.

In many ways I still think about product experience design as a science. Human behavior isn't random. People respond to incentives, constraints, identity, social dynamics, anticipation, uncertainty, progress, and countless other forces in surprisingly consistent ways. Given enough understanding of the people you're designing for, the environment they're operating within, and the outcomes you're trying to create, I believe it's possible to intentionally design experiences that reliably influence behavior.

That belief hasn't really changed.

What has changed is my understanding of what happens after those systems begin interacting with reality.

The moment a thoughtfully designed system exists, it stops being something you're simply studying. It becomes part of the environment you're trying to understand. People respond to it. Their behavior changes. Those changes create new conditions, expose constraints you couldn't previously see, and reveal opportunities that literally didn't exist before the intervention.

The science hasn't broken down.

The experiment has simply entered its next phase.

Looking back, I think I kept trying to explain this as iteration because iteration was the closest language I had available.

I still think iteration is a useful idea, but eventually it stopped feeling like a complete description of what I was observing.

Iteration suggests improving an existing solution. What I kept experiencing felt different. Often the solution wasn't simply becoming better. The problem itself was changing because the system had changed, and the system had changed because we had intervened in it.

That distinction matters.

If an onboarding problem eventually becomes a motivation problem, it doesn't necessarily mean the original onboarding work was misguided. It may simply mean that solving the onboarding problem created the conditions for a deeper question to become visible. Later, motivation might give way to anticipation. Anticipation might eventually become identity. None of those questions invalidate the ones before them. Each represents a progressively deeper understanding of the same system.

At some point I stopped thinking of this as iteration and started thinking of it as escalation.

Not because the work was becoming bigger, but because the questions themselves seemed to be moving toward increasingly fundamental causes. Every meaningful answer revealed a better question hiding underneath it.

Eventually I started referring to this pattern as Escalation Loops. Not because I thought I had discovered a new product methodology, but because I needed language for something I kept observing. Once I had a name for it, I started recognizing the same pattern in places that initially seemed unrelated.

Looking back, I don't think that's an accident.

Long before I worked in product, I became interested in Daoism. That eventually led me to study Eastern philosophy before I shifted my focus toward anthropology because it felt like a more complete discipline. Philosophy asks profound questions, but anthropology grounded those questions in observation. It cared deeply about what people actually did before trying to explain why they did it.

Years later I found something similar in improvisation.

A good improviser doesn't simply execute an idea they arrived with before the scene began. Every offer changes the reality of the scene. Once that happens, the next meaningful choice has to emerge from the new reality that everyone has created together. Trying to force the original idea often makes the scene feel less believable, not more.

The more I reflected on these different experiences, the more they started to feel like different expressions of the same underlying pattern.

Products weren't unique.

Improvisation wasn't unique.

Anthropology wasn't unique.

None of them were examples of the theory.

They were independent places where the same pattern seemed to emerge.

That realization also changed how I began thinking about some of the products I'd worked on.

At Lucky Day, solving one engagement problem often revealed that the more interesting question was somewhere else entirely. Mechanics that initially appeared to improve retention gradually became opportunities to rethink progression, anticipation, and long-term player identity.

While working on NHL Breakaway, some of the most meaningful product decisions weren't simply the result of following a roadmap more effectively. They emerged because player behavior continually reshaped our understanding of what collecting, progression, and participation actually meant within that ecosystem.

Developing ClownJewels compressed these loops enough that they became difficult to ignore. Questions that might have taken months to emerge on larger products appeared over the course of days. Watching the product evolve so quickly made it obvious that I wasn't simply refining mechanics. I was continually discovering that the questions worth asking had changed because the product itself had changed.

Different products.

Different domains.

The same pattern.

This has also changed the way I think about AI.

Much of the conversation understandably focuses on productivity and automation. Those things matter, but they aren't what interests me most.

What interests me is that AI dramatically reduces the cost of intervention.

If every meaningful intervention changes the system, and every changed system creates new opportunities to learn, then reducing the time between interventions fundamentally changes the pace at which understanding develops. The opportunity isn't simply building faster. It's completing more loops. It's creating more opportunities for reality to reshape your understanding while the problem is still fresh in your mind.

While writing Compounding Theory, I gradually realized that these ideas were describing different parts of the same process.

Compounding Theory asks what happens after you've found something worth reinforcing. It describes how small advantages accumulate into disproportionately meaningful outcomes over time.

Escalation Loops asks the question that comes before that.

How do those advantages become visible in the first place?

The more I thought about it, the more they began to feel less like separate ideas and more like two perspectives on the same practice. One is about how understanding emerges. The other is about how understanding compounds.

At this point, I think of Escalation Loops first as an observation.

It's a pattern I've found increasingly difficult to ignore across product development, anthropology, improvisation, and other complex systems. Over time, though, that observation has begun changing how I work. It has influenced how I prototype, how I think about discovery, how I evaluate user behavior, how I structure experiments, and even how I think about AI.

In that sense, it has gradually become more than a philosophical observation.

It has become a methodology.

Not because I set out to invent one, but because repeatedly observing the same pattern eventually changes the way you choose to act.

I still believe in planning.

I still believe in discovery.

I still believe product experience design can become increasingly scientific.

If anything, Escalation Loops has strengthened those beliefs.

The better we become at observing how reality changes in response to our interventions, the better our models become. Those better models lead to better interventions, which reveal deeper questions, which in turn produce better models again.

Maybe that's all an Escalation Loop really is.

A disciplined practice of allowing reality to continually refine our understanding of the systems we're trying to shape.

Influences and Lineage

Escalation Loops grew out of years of working across product development, games, improvisation, and independent projects, but the way I understand it is also shaped by ideas and disciplines that influenced me long before I had language for the pattern.

Marty Cagan's writing on product discovery was foundational to how I learned to approach product work: understand the problem before committing to the solution, test assumptions, observe behavior, and treat discovery as an ongoing discipline rather than a preliminary phase.

Daoism and my early study of Eastern philosophy shaped my sensitivity to systems that resist being understood through force alone. Anthropology later gave me a more grounded way to pursue many of the same questions through observation, participation, and attention to what people actually do.

Improvisation reinforced the pattern in practice. Every offer changes the scene, and every meaningful choice alters the context in which the next choice must be made.

Escalation Loops is not an attempt to replace any of these traditions. It is the name I've given to a pattern I kept recognizing across them: intervention changes the system, and the changed system reveals a deeper question.