Integrated Growth: The Operating Model
This piece turns the Integrated Growth Manifesto’s “why” into a working “how.” It introduces four terms (data, signal, surface, and action) and builds them around an intelligence hub that reads each signal against what’s already known and gets it to whoever can act on it. The source team interprets its own data; the destination team decides what to do with it; someone has to own the handoff in between. Real cases, including HBO Max’s personalized CRM push and Audacy’s commute-timed creative, show the loop compounding in practice. Growth stops compounding channel by channel and starts compounding as the hub learns.
The point at which the Manifesto ended
A few months ago, our CEO, Andy Carvell, published the Integrated Growth Manifesto and described it as a stake in the ground. To briefly summarize, the Manifesto argues that growth works as one connected system rather than a set of separate channels. It argues that user journeys are rarely linear, and the best teams embrace this reality. Every stage of the journey generates insights, and those insights should move freely between stages rather than getting stuck. Lastly, first-party data connects everything, and with a solid foundation, AI can move those insights through the system faster and at a scale no human team could match.
The best growth teams in the business already operate this way, and the response to the Manifesto suggested plenty of others see where things are heading. But the Manifesto explains the why, not what to do next. It ended with a promise to show what connected growth loops look like in practice, from user acquisition to the store, product, CRM, and paywalls, and that’s exactly what this piece is here to do.
Why Now, Again
The Manifesto explained what’s changed in growth marketing. We think it’s worth repeating, because the operating model is designed to answer these changes:
- Privacy regulations and signal loss are degrading traditional targeting.
- Automation has flattened execution advantages.
- Creative has become the new targeting.
- Incremental optimization no longer compounds so readily.
- Some long-standing growth challenges have been “solved” by ad-tech and mar-tech, taking old edges off the table.
- AI is accelerating all of the above.
The argument here is that these six trends resolve into two chains, and both end in the same place.
The first chain is data-side. Privacy regulation and signal loss degraded the targeting toolkit of lookalikes, identifiers, and deterministic signals, so differentiation moved into the message itself. Once the message carries more of the targeting job, what you learn about messaging on one surface becomes targeting intelligence for every other. A hook that converts in paid tells you something about your store listing, your paywall, your onboarding. Teams that move those learnings between surfaces end up better targeted than teams that don’t.
The second chain is execution-side. Automation flattened execution advantages, while ad-tech and mar-tech solved entire categories of once-hard problems, and AI is accelerating both. When every good team can execute well, excellence stops being a differentiator, and incremental optimization stops compounding too. Even though the work is as good as ever, there is less operational advantage left to compound. What’s left is judgment: how well you interpret your data, and how far what you learn travels before it stops.
The Problem, Precisely: Learnings Die Where They’re Found
Growth teams are always learning about their users, but too often, those insights stay within one team. For example, an ASO team might discover that people install the app mainly to edit documents rather than only read them. This insight could be valuable for paid creative, the paywall, and CRM messaging, but in most companies, it never makes it beyond the ASO team. In this case, UA keeps bidding on the weaker message, and the paywall keeps selling the wrong benefit. Nobody did anything wrong. The ASO person knows their data, and the UA person knows their channel. The problem is that the learning never reaches the teams who could actually use it.
That kind of “waste” is what we call a silo. Reorganizing teams, merging roles, or hiring generalists doesn’t fix that. It weakens the specialization that makes these teams strong. What’s actually missing is the handoff, so Integrated Growth shifts the focus from “which team owns this?” to “what did we learn, and where should it go?”
The Anatomy: Four Words
When two teams use the same word differently, the handoff breaks down. To avoid that, the model uses four terms you probably already use in your day-to-day work (data, signal, surface, and action) and gives each one a clear meaning.
Surfaces are places where you collect data and take action. These can be app stores, paid channels, web funnels, paywalls, your product, or CRM. Surfaces are swappable. Not every team has the same ones; maybe you run web funnels, maybe you don’t. So swap surfaces in or out, and the model still works because it’s about what moves between them, not any single place.
Data is your raw material. It includes things like searches, churn events, NPS scores, reviews, and test results. First-party data is collected and interpreted on its own surfaces. External data, like benchmarks or competitor research, goes straight to the hub, where it’s used as context. In both cases, data only becomes a signal when someone decides it’s worth acting on.
A Note on External Data: The Manifesto was emphatic: first-party data is the new gold, and third-party data as a targeting tool is dying. External data plays a different role here. It is context: benchmarks, market studies, competitor research, not a targeting substrate. It sharpens interpretation and can start loops, but first-party data settles them.
A signal is data interpreted as worth acting on, sometimes a single observation, often several read together. Not every interpretation becomes a signal. Data only counts as a signal if it would change how another surface operates.
The goal is to get each learning to the surfaces where it can change a decision.
An action is what’s done at that surface once the signal lands, whether that’s a new creative, a reordered paywall, or a CRM campaign. Actions happen where the signal arrives rather than traveling onward, and each one produces fresh data.
These four terms describe the flow, but the intelligence hub is the real engine. Its job is to read each signal against what’s already known, get what matters to whoever can act on it, and learn from every result.
The point of the hub is that a good insight shouldn’t be a one-off. What you learn about your users is a valuable first-party asset you can use again and again. If you treat each such learning as disposable, used once and forgotten, you throw that value away. The hub is what keeps it and puts it to work more than once.
First, the hub is a capability. It doesn’t need its own team or place on the org chart. It can be run by a person, an agent, or a mix, and the model takes no position on which. An agent reads across more data than a person can hold at once, without getting tired or falling into habits that narrow where a person looks, and it will sometimes flag a candidate signal that no one thought to check. A person brings judgment and context an agent can’t.
Second, the model doesn’t care who owns the hub, only that someone does. A hub without an owner isn’t flexible or distributed. It’s a silo with extra steps. Whether it’s two surfaces or twenty, it’s the same hub sitting underneath.
Inside the Hub: How Data Becomes a Signal
Interpretation is the hardest idea in the model, so a picture helps. Think of a crime scene. It is full of data such as fingerprints, a dropped receipt, the weather that day, and scuff marks on the floor. The detective’s work is telling which of those details point somewhere and which are only scenery. That same discrimination is what the hub performs on searches, clicks, churn events, reviews, experiments, and usage patterns.
Concretely, interpretation asks four questions of one or more pieces of data, whether it’s a source reading its own surface or the hub reading across all of them:
- Intent: what do they want?
- Driver: what converts them?
- Engagement: what do they do?
- Value: what are they worth?
These are the essential questions you ask of your data, but not necessarily the labels you sort them into. There’s no fixed ratio here. Sometimes several data points together answer only two or three of these questions, and sometimes a single one answers all four. Take an example in action: a language-learning app notices that users who search the App Store for “learn Spanish” convert to installs at 2x the rate of users searching broader terms like “language app.” The raw data is the search behavior, the conversion difference, and how those users behave once inside the app.
Ask the four questions:
- Intent: users searching “learn Spanish” are not exploring language learning generally; they have a specific goal.
- Driver: the Spanish-learning use case is likely a stronger reason to install than the broader category message.
- Engagement: once installed, these users complete onboarding and reach their first lesson faster than users from broad searches.
- Value: users with a specific learning goal may have higher subscription potential.
The signal, then, is that specific language-learning intent looks like a stronger conversion driver than the generic category message. At this stage, that is a hypothesis, something worth acting on, and what happens next settles whether it holds.
This is why the hub is more than a router. The signal reaches the destination as a candidate, and the destination decides whether it is worth validating. If it is, the destination tests the hypothesis, and the result comes back to the hub. A validated signal carries more weight; a failed one less or none. This is how the hub compounds: every result comes back and becomes a part of what the hub knows. It reads each new signal against every result before it, so what reaches the destination is “enriched” with the source’s read plus everything the hub has learned.
The framework doesn’t dictate how teams validate a signal. You might run an experiment or act on judgment, depending on your stage and risk appetite. What matters is that the signal travels and someone decides what to do with it.
The Handoff: What Travels, When, and Who Owns It
Once signals start moving between surfaces, a practical question comes up: who’s actually in charge? A read from one team lands on another team’s desk, and it’s not obvious who decides what happens next. So it helps to be precise about how the work splits.
Two roles stay fixed: the source interprets, and the destination decides. And in between, someone has to own the handoff itself.
The source interprets, by default. Whoever is closest to the data reads it best. The ASO team knows its search patterns; the CRM team knows its engagement curves. The source team explains what the data means, but doesn’t tell other teams what to do with it. This works in two ways: the source team goes deep on its own surface, and the hub, whether a person or an agent, looks across all surfaces to spot patterns no single team could see. Both are important, and neither overrules the other.
The destination team always decides what to do. The expertise for action sits with the team responsible for that area. For example, ASO doesn’t tell UA what creative to run, but it does hand over what it learned; UA takes the insight and decides how to use it. This role never changes, and it’s the answer to the objection every specialist rightly raises about integration: nobody is overruling you on your own surface. They’re handing you more context to work with.
The destination might also decide not to act, and that’s a result too. A “no” is worth capturing: the fact that a surface tried something and it didn’t work, or looked at it and passed, goes back to the hub just like a success does. Next time a similar signal comes up, the hub already knows it’s been tried, and doesn’t route it again. So a rejection still saves time, because nobody has to test the same idea twice.
Someone needs to own the handoff. This is often missing in organizations: making sure the signal actually gets from one team to another. But before assigning ownership, check if the learning is worth moving.
Discipline matters here: route everything, and you turn shared docs into archives, growth leads into forwarding services, until the signals that matter are buried in the ones that don’t. A few strong signals are worth more than a record of everything everyone learned. When source and destination disagree, the destination decides. The source owns the interpretation; the destination owns the action. A framework where the source can overrule the destination is not Integrated Growth. The destination operator often holds context the source can’t see, enough to act on a signal, hold it, or send it somewhere it fits better.
There are three main ways to manage the handoff, and these work for any company size. The simplest is a shared space everyone watches. That includes data and signals living in one visible place, allowing people to pull what’s relevant when they act. ASO writes the interpretation, “users search edit, not read,” into a shared doc, and UA reads it there when building creative. This is quick and easy, but the weakness is that signals only travel if someone looks.
Another option is to assign someone to watch across surfaces and route relevant signals. For example, a growth lead spots a store-intent signal in the ASO review and shares it with paid, CRM, and product teams during the weekly sync. This ensures signals travel, but relies on one person’s attention.
The most automated approach uses an agent to watch all data across surfaces, flag what’s relevant, and highlight signals people might miss. People still interpret and decide what to do.
We’ve run a version of this. At HBO Max, the CRM team sent a weekly “Movie Night” push, but they picked the title by hand. Everyone in a market got the same one, even though the app’s own “For You” engine already knew what each individual user was most likely to watch. That engine sat on the product surface, which CRM couldn’t reach. Exposing it through an API let the CRM platform pull each user’s own recommendation into the weekly send, and open rates rose 40%. See the case study here.
No new insights were needed; instead, the improvement came from acting on a signal that had been trapped. The product team already knew what users wanted to watch, but CRM couldn’t use that information until the handoff was in place.
Any of these works at any scale. While a solo developer can run an agent as their hub from day one, a large organization might run happily on a shared doc. The choice follows how you work, not how big you are, and most teams end up mixing them. One caveat from the Manifesto bears repeating here, because the automated path makes it acute. As Andy put it, AI will not fix broken or nonexistent foundations. Rather, it will amplify and extrapolate errors while obfuscating their origin. The agent inherits exactly as much data discipline as you have.
The Loop: Why the Hub Compounds
Together, the process forms a loop: data comes in, is interpreted, becomes a signal, leads to action, and the results generate new data. Then, the cycle repeats. Signals get used up once someone acts on them. Their results don’t: they go back to the hub and inform the next read, so each turn of the loop starts sharper than the last.
Channel-level optimization no longer compounds because everyone is good at it. The hub compounds by connecting all surfaces and accumulating judgment from all of them at once, whether from your own data or external observations that become first-party data.
Our work with Audacy shows the full turn. Their first-party data had usage spiking around commute windows, down to Monday-morning peaks, with state-by-state differences that tracked local drive times. Audience research and in-app surveys feeding the hub directly confirmed why. Read as intent, the signal was clear: people wanted a drive-time product. The action it produced was a creative concept built around the commute, pushed up the funnel until the story held from ad to store, and the best-performing variant lifted App Store conversion 7%. That result re-entered the hub as data, so the next turn started from what this one proved.
And the benefit isn’t only internal. Because that commute insight traveled, the whole journey lined up: the ad spoke to drive time, the store page carried the same story, and the experience held together from tap to install. When insights stay siloed, the user gets a disjointed version instead: one message in the ad, a different one on the store, a third inside the app. Integrated Growth makes the journey cohesive, because every surface works from the same understanding of the user.
As Andy Carvell put it in the Manifesto that we mentioned in the beginning, compounding a series of small, connected wins across the funnel is usually worth more than chasing a single but siloed “big” win. That is also the true cost of a silo: a learning trapped on one surface never enters the loop, so the hub never gets to compound on it.
Start Monday
Starting doesn’t take new tooling, a reorg, or an AI budget. Instead, pick two surfaces and have the source team write down what their data means and why it might matter elsewhere, then hand that interpretation to the team that could act on it and let them decide what to do. That’s the whole mechanism, just at a small scale.
The old playbook optimized channels one at a time. The new one moves what each surface learns to the others. In a way, that’s what this piece has been. We’re the source, and you’re the destination. We’ve interpreted what we’ve learned. Now you decide what to do with it. Isolated wins stay isolated, and connected wins compound.
Next in the series: the Integrated Growth playbook: how to run your first pilot, from metric to green light.
FAQ:
What is the Integrated Growth operating model?
It’s the practical follow-up to the Integrated Growth Manifesto. Where the Manifesto argued that growth should work as one connected system instead of separate channels, this piece lays out how to actually run that system: four terms (data, signal, surface, action) and an intelligence hub that reads each signal against what’s already known and gets it to whoever can act on it.
How is this different from the Manifesto?
The Manifesto explains why the old channel-by-channel playbook is breaking down: privacy regulation, signal loss, and automation have all flattened the old advantages. This piece picks up where that argument left off and shows what connected growth loops look like day to day, from user acquisition through the store, product, CRM, and paywalls.
What are the four core terms: data, signal, surface, and action?
A surface is any place you collect data and take action, like an app store, a paid channel, or a paywall. Data is the raw material collected there: searches, reviews, churn events, test results. A signal is data that’s been interpreted as worth acting on, and worth acting on beyond the surface that found it. An action is what a team does at a surface once a signal lands, and it produces new data, restarting the loop.
What’s “the hub,” and who’s supposed to own it?
The hub is the capability that reviews each signal, compares it to what’s already known, and routes what matters. It can be a person, an agent, or a mix of both, and the model takes no position. What it’s strict about is ownership: a hub without an owner quickly becomes another silo.
How do you know when data has actually become a signal?
Not every observation counts. The test is simple: would the destination operate differently because of this? If the answer is no, it stays a local learning and doesn’t need to travel. If yes, it’s a signal worth moving.
Who decides what to do with a signal, the source team or the destination team?
The destination decides. The source team, whoever is closest to the data, owns the interpretation of what it means. The destination team owns the action. If the two disagree, the destination decides, since they usually have context the source can’t see.
What are the three ways companies actually manage this handoff?
A shared space everyone watches, like a doc where teams post interpretations and others pull from it when relevant. A person who watches across surfaces and routes signals manually, often a growth lead. Or an agent that watches all the data and flags what’s relevant, while people still decide what to do with it. All three work at any company size, and most teams end up mixing them.
Can you give a real example of this working?
At HBO Max, the CRM team manually picked one “Movie Night” title for everyone in a market, even though the app’s recommendation engine already knew what each user was most likely to watch. Once that engine was exposed through an API, CRM could pull each user’s own recommendation into the weekly send, and open rates rose 40%. No new insight was needed, just a handoff that hadn’t existed before.
Why doesn’t optimizing a single channel compound the way it used to?
Because everyone’s execution has gotten good at roughly the same rate, thanks to automation and mature ad-tech and mar-tech. When every team can execute well, doing your own channel slightly better stops being a real edge. What compounds now is the hub: every signal it processes informs the next one, building an advantage no single channel can match on its own.
Does adopting this require new tools, a reorg, or an AI budget?
No. The suggested starting point is to pick two surfaces, have the source team write down what its data means and why it might matter elsewhere, and hand that interpretation to the team that can act on it. That’s the entire mechanism at its smallest scale.
What comes next in this series?
A follow-up piece on running a first Integrated Growth pilot, from picking a metric through to getting a green light.
