Growth Origin Model

The challenge, the pattern, how we tried to fix it

Startups faced two challenges. One was an organizational challenge between product and the go-to-market function, and the other was the actual marketing execution.

The fix always was to get the product and growth teams aligned, and then hiring enough people on the execution layer. Outside of some very successful startups, the fix posed implementation challenges that kept repeating across different orgs.

The cost of pouring more money into marketing, more channels, more managers, created a problem of its own. So, in 2019-2021, we attempted to solve the growth problem with the product itself. That's when PLG (product-led growth) went mainstream. PLG was the right call, but not for every company. Back in 2004, when I was working on a new idea in affiliate marketing, which wasn't an instant success, PLG is what brought us to scale and essentially a successful exit in 2010. The difference? The marketing guy was the product guy, me.

The lesson I kept was not about affiliates. The best growth started with product and features. Ideas first. Then execution and testing on those ideas. The challenge I've seen many times is that PLG is not always the answer for reaching scale, depending on the industry, market and the business model. And the marketing team needs the product team to execute on pretty much every digital campaign.

As I moved into different orgs and growth roles, I've seen the same common pattern: the product team was busy building and launching new features, while the growth team needed to add requests to the product team's roadmap (which we had to defend). Not a bad construct. The issue was the time it took to deploy new campaigns, and iterate, which pushed out the execution timeline.

In contrast to my successful runs, where I was leading the growth product (to be clear, not the product itself), this time around I realized that product thinking was maybe 10% of a growth leader's job, squeezed in around managing execution, managing expectations, and reporting to the board.

Now, in the new AI era, we are starting to see a comeback to the days where growth leaders are shifting towards product. I don't think it's an exaggeration when I say that all the growth leaders I talk to are now fully immersed in building new products: new workflows, data enrichment, data pipelines, new automation. What's fascinating is that most of the work is now done by AI agents, built once and deployed at scale.

All this sounds great, until we realize that the JD and the organizational layer hasn't caught up yet. We've just added AI automation to the Head of Growth JD and called it a day.

In order to solve this at scale, we can't just add more responsibilities to the Head of Growth. We need a transformation, structurally and operationally.

Let's look at the current structure of how product ships, and most importantly the handoffs between different teams and functions. In most cases, the growth team is the last touch in the flow. Nothing wrong with that. The main issue is the velocity of experiments, testing and iteration. Let's dissect the current structure, and then we can look at a proposed solution.

Growth sent requests. Defended them. Never originated.

The most frequently used process looks something like this: the product team scopes and makes a decision, design draws, the engineering team builds, and everything runs through security checks. Each team hands the work to the next. The growth team gets pulled in at the end to market the new product or feature.

Now you could say that this is part of the core product, and not the product needed to execute on campaigns. And that's the actual core problem. More often than not, there is no product team to execute on growth product initiatives. And this was the main tension. Growth owned the outcomes, but wasn't able to design and execute on the solution, even as an experiment layer before something rolled out more broadly. Every surface it needed was owned and managed by another team.

For the core product, this flow still makes sense. For everything else supporting the marketing org, it's nonexistent.

Origination changes hands

As the AI models, tools and MCPs (model context protocols) get better, the Head of Growth can finally originate the ideas and deploy the surfaces needed to drive execution and gather learnings for the next initiative. Unless those initiatives touch the blast-radius gate, the Head of Growth can execute and test. Most of what is acceptable here are the growth and GTM surfaces: the pages, flows, signup forms, lead magnets, data enrichment, CRM APIs, booking a meeting for the sales team, email nurtures, and updating tracking and events for bidding optimization.

The Head of Growth will originate the idea, whereas AI agents will build and deploy. The results will feed back into the next decision. That's the Growth Origin Model, and the loop is its mechanism.

Growth loops are at the core of user growth. The Growth Origin Loop describes how the growth and product teams should operate.

The loop only works if these laws hold

At this stage, the Head of Growth will need to run the entire Growth Origin Loop. Signal will come from founder-led initiatives and sales.

Advance when → surface volume outgrows the judgment capacity of one person.

Once the company is past Series A, with the new funding, it will need to increase the output. The goal now turns from proper execution one loop at a time, to sound execution across multiple loops running in parallel. Velocity without proper rails creates a high risk at this stage. The first dedicated hire within the loop is the Growth AI Ops Manager, not another marketer, which is what allows for higher output velocity within the pod.

Advance when → one loop can't hold both acquisition and activation.

You don't grow the pod. You clone it. Two loops on shared rails, and one of the two growth leads steps up as the main Head of Growth, owning all the pods and managing initiatives across the board. Attempting to grow within an existing pod or team will stress out the system, and that's where things start to break down.

In addition to the additional pods and increased velocity, we will need to add the Credibility Lead for the brand layer. If instrumented correctly from the beginning, by now we will have enough data and traction to amplify the message. This creates a moat. By Series B, competitors can replicate any page you ship in a day. What they can't copy is your actual positioning with your customer, and how they feel about you.

Advance when → a third loop earns its own P&L. Past that, you're a different company.

The Head of Growth will evolve

This title, and even the JD, made sense back when growth meant managing a layer of pure executors: designers, marketers, developers, or agencies. That layer will change dramatically, and the team will run much faster with embedded AI agents.

The role doesn't disappear. It evolves. The Head of Growth as a pure leader of the growth team, with a product partner alongside, is no longer sufficient. Product skills used to be maybe 10% of their purview, and now they're most of the job. Recently we've seen mentions from BCG, Google and others referring to the growth leader as the new growth architect. That accurately describes the new responsibilities the Head of Growth carries, but it is yet another responsibility added on top of what they already had. That will not drive better outcomes, unless the organization restructures the function entirely and empowers the team to run campaigns end to end, owning the surfaces that make it all work. Some could argue product should take the role. I think it's far more natural for a growth person to bring in product expertise, because this role originates from the growth mindset and ways of doing things. The role will evolve, the same way it has every few years since 1995. This is a transformative period, and the companies that adopt this structure earlier will move faster and capitalize on it.