Growth Is a System. Start There.

Today’s newsletter is adapted from a workshop I recently led for Long Journey Ventures at their Reverie founder retreat. Want to bring this kind of conversation to your company? Reply and let me know.

At the end of the newsletter I’ve created a way for you to get an artifact that helps you walk through creation and mapping of this system. Exciting!? YEP.

I talk to A LOT of founders. Many of them reach out about Growth, Product Management and increasingly AI Transformation. There is one commonality in all of the outreach around Growth though:

All of the conversations start one level too low.

Founders ask me:

• Which channel should we use?

• Should we build a referral program?

• Do we need a Head of Growth?

• Can AI generate enough creative to make paid acquisition work?

• Who is the best person to do X, Y or Z?

• …and dozens more

There’s nothing inherently wrong with these questions. They’re all reasonable things to want answers to. But they’re also very hard to answer correctly until you understand how the company actually grows. I hate the “it depends” response and that’s not what you came here to read so in today’s newsletter I’m going to tell you how to get started so that you can answer these questions properly.

First, let’s remember what Growth is:

Acquisition, activation, retention, monetization, sales, pricing, partnerships and products are all components that make up that system. A tactic changes one of those components. A team owns some of the work. Neither of those tell you how the full thing operates.

So start with writing down your system. It’s simple and it’s okay if you’re wrong (more on that later). Answer these two questions:

1. What is the mechanism that brings the right customer into your company, gets them to meaningful value and creates the next cycle of growth (i.e. closing the loop)?

2. Which part of that mechanism is currently constrained?

Once you have a decent answer to those two questions you can then decide what to test, what processes to change, or whom to hire (and more importantly: not hire).

I learned this painful lesson while building the original Growth team at Lyft.

Facebook (remember when they were called that?) had recently launched Mobil App Install ads back in 2014. Inventory was dirt cheap because very few companies had adopted the product. As a result, though I didn’t know it at the time, it looked like Facebook could become one of the most important parts of our paid passenger growth loop. Based on that belief I hired a specialist who was brilliant at this work. One of the absolute best in the industry at mobile installs.

Then I got punched in the mouth. More advertisers flooded into the market, channel costs ballooned and it brought down the assumption that MAI ads would be our savior. I had just hired an MAI expert. Now fortunately, he could pivot to other parts of our Growth model and work on other aspects of paid acquisition. The flexibility kept me from having to let him go, but I made a poor assumption in hiring a surgeon when I needed an architect.

There was nothing wrong with testing out FB ads. You need to test and exploit early. The mistake was treating early favorability as proof that the larger system was working and scalable. It wouldn’t be for a long time.

A cheapo install was evidence of a moment in time in a market and I got that wrong.

This same error shows up in lots of different forms. You’ve got viral features that produce invitations but an invited user never reaches any meaningful value. A sales team closes several large deals but each implementation requires an act of heroics on the product team. A marketplace adds supply at a breakneck pace but it can’t create useful demand. A company builds a content engine without learning whether that content changes customer behavior.

A local metric moves. Everyone celebrates. Then the constraint pops out from the closet and scares you.

A growth system does not require an elaborate spreadsheet in the beginning. Even the simplified growth model might be overkill when you’re starting out. What you need is something that is explicit enough that a team can test its assumptions. The system is a qualitative description of what happens in reality. The Growth model is your current explanation of that system.

Start with a single page and answer five questions:

1. What repeatedly brings the right customer or partner into your product?

2. What gets that customer or partner to meaningful value?

3. What creates the next cycle: a return visit, referral, expansion, proof point or another partner?

4. How does the business capture enough value to keep the motion going?

5. Where is the system constrained today?

Your answer to these questions is going to look a lot different from business to business.

For example, a consumer product might grow when one user creates something useful, shares it and that share brings another user into the product. An enterprise company probably grows very differently: sales to implementation, proof and expansion. A highly regulated product may move from a design partnership to evidence, regulatory progress and then broader adoption. And still a physical technology or hardware company might move from an integration to a valuable use case then to recurring data consumption that makes the next integration more valuable.

Your growth system can be viral, but it can also be a sequential motion rather than a tidy loop (at the start). What is eventually required is a repeatable path from value creation now to the opportunity to create more value next.

When you’re just starting out many parts of that path will be a hypothesis or sometimes even a wild guess. That’s fine. Gotta start somewhere. Write down what it is that you believe, label what you know (and don’t) and instrument the places where evidence is missing. You don’t need certainty to get started; think of your initial system and model as a conversation starter.

The key hurdle to overcome: if you cannot describe the system then adding more tactics to it will just generate more noise.

So now you’ve got a system that’s written down on paper. Good job. Now ask where it breaks. Take one unit of value alllllll the way from entry to the value realization moment, the next cycle and subsequent value capture. At each step you’re asking whether an improvement would increase completed cycles end to end. Choose your most plausible limiting step from this exercise, write down the downstream change you expect to deliver and then run the smallest possible test that could provide your diagnosis right or wrong (mostly wrong).

A few outcomes you might observe from this exercise:

1. The right customers retain but too few discover the product. Acquisition is your constraint.

2. Plenty of people show up at the front door but few reach value. Activation is your constraint.

3. Customers love the product but every implementation is bespoke. Delivery is your constraint.

4. Usage is healthy but the economics can’t fund another cycle. Pricing, monetization or cost structure is your constraint.

Sounds obvious when you’re reading it here but inside the company these examples are usually split across different teams, dashboards and/or planning processes – and each group will see the metric it owns. Your marketing team sees the volume; product sees activation; sales sees pipeline; finance sees payback; operations sees the custom work holding everything together.

A system view forces those observations into one argument (er… discussion!) about how the company grows.

It will also change your prioritization because the best-performing part of the system is not automatically the place that needs more resources. Toiling away to improve a non-constraint may give you a local maxima (hooray performance review!) but the company’s growth rate won’t change. It actually could get worse because you’re sending more customers, transactions or work into a step that can’t handle it.

Remember too that constraints move. The whole thing becomes a game of whack-a-mole.

Once you fix activation then acquisition may become the next limit. If you fix implementation then customer success becomes the bottleneck. New channel opened up? New retention challenges emerge.

Growth strategy definition becomes its own form of a loop: map the system → identify the current constraint → intervene → learn → map it again.

Longtime readers of this newsletter will have heard me say more than once, “even a broken clock is right twice a day!”

It’s true in performance reviews and leveling guides and it’s also true in deals, campaigns or partnerships. A single success is evidence but you have a system when you can trace a repeatable path from that win to the next one (and the next one).

Early wins come in fits and starts and they are messy. You’ve got founders selling with personal credibility, product teams building “specials,” an ops team who holds the whole thing together by sheer force of will. The work is right while the company is learning BUT the danger comes from confusing the effort around that win with the mechanism that caused it.

Document the following with each successful deal or growth cycle:

1. Who was the customer?

2. Why did they act at that moment?

3. What offer or experience prompted their decision?

4. Which parts of delivery were custom?

5. What created a return, referral, proof point, or follow-on expansion?

If you’re starting to stack up the wins then pay attention to what recurs or is common within all of them. You can turn those pieces into qualification criteria, case studies, implementation playbooks, product capabilities and a clear next-step motion. Be clear about what still requires judgment and modification over forcing premature standardization.

The goal with all of this is to move from “yay! It worked.” to “we understand why it worked and can make it happen again.” You’re avoiding the broken clock phenomena.

A HUGE mistake that so many companies make is that they immediately harden the work into an org chart. I get it, it’s human nature. We like structure. We looooove org charts… even if they are flattening before our eyes. An untold number of founders approach me asking about org structure immediately. But it’s a mistake. Let the system shape the work before you turn it into an org chart. Roles need to remain fluid for a while and your teammates won’t care if you’re clear while it’s happening.

Don’t get me wrong here: I love focused teams. Can’t get enough of them. But early on in the journey they can fragment a product because each team is optimizing to their feature boundary or local maxima without any sense of shared responsibility for the entire customer journey. Bad! Do not want.

It’s fine to have small teams with fairly narrow mandates but the mandate needs to describe outcomes within the larger system. Things like:

• Get more new customers to first value

• Deepen repeat usage and engagement

• Expand eligible purchasing

• Shorten reliable implementation

If you just assign ownership to a collection of screens you’re missing the point.

Thank you random internet denizen, I’m so glad you asked:

• Use a shared definition of the customer and anchor on the meaningful value the company is trying to create.

• Give teams outcome-based missions tied to the system’s current constraints.

• Make decision rights explicit and then review the e2e journey often enough to catch the problems between teams.

As your company expands across products, markets, customer groups, or delivery models you’ll see specialization starting to follow. Those disparate groups will need to agree on shared customer promises, reliability standards, product principles, and clear interfaces. Without them you’ll have individual teams hitting their goals as the overall experience slowly and steadily degrades into a pile of garbage.

Let’s start with one premise before answering this question: hiring is one of the most expensive ways to express an unproven theory of growth.

I’ve often told people that the fastest way to kill a bad product is with a good growth team. Building on that: the fastest way to kill a bad growth system is overhiring.

Early on, before you’ve proven your hypotheses, you want to favor people who can reason across product, data, engineering, operations and go-to-market. Maybe not all of those things can be contained within one human, but most of them. These people need enough range to diagnose the system and follow the evidence when an assumption fails. If you’re working in a highly regulated or deeply technical environment you may need specialist expertise earlier, but I’d err on the side of non-permanent labor to help with that. Your core growth problem still needs an explicit, generalist owner and a hypothesis.

Specialization starts to become useful after a bottleneck or constraint is (1) persistent and (2) well understood. I’m not talking about one good quarter in a channel. You want to see a durable opportunity via one or more of the following: acceptable unit economics, reliable activation / retention, credible LTV, and ample evidence that deeper expertise can improve performance further.

If many of those are true. Go hire your specialist. Otherwise: do not pass GO, do not collect $200.

This also changes how you interview and hire. You can skip the tour of famous growth playbooks and move right to giving candidates a messy customer or funnel problem instead. Then sit back and watch. You can also follow the Depth Method if you’re wondering how best to run this interview and here’s a full guide to hiring for growth.

• Do they define the outcome before they propose a tactic?

• Do they ask for the denominator?

• Do they separate correlation from causal evidence?

• Do they want to talk to customers or ask to do it?

• Can they design the cheapest useful test?

• Do they understand the downstream product and operational consequences?

The strongest growth operators will search for some evidence before picking a lever. So if they don’t do that as part of their first answer I’d send them right to the rejection bin.

I’ll have a fairly lengthy post on creating a GrowthOS in a future newsletter (yep, this is real). For now, here’s what you should know about the AI Hype Machine:

AI can shorten parts of the growth cycle, specifically observation to hypothesis, creation, launch and measurement. But that speed is only useful when the work remains tied to a model of the system. AI on top of a crap system is still crab (garbage in / garbage out ya know?)

Some areas where you can immediately use AI to help you:

1. Summarization and synthesis of customer signals and research.

2. Surfacing candidate segments for human validation from data.

3. Generating variants against a clear hypothesis.

4. Summarizing feedback quickly enough to improve the next cycle.

5. Jumpstarting that next cycle.

I don’t really need to see you using AI to produce more content or more experiments. A better use is a stronger, testable explanation of what may have worked, for whom, and why.

If you lack that discipline you’ll use AI to fill every channel with activity while learning almost nothing and it’ll drive you towards the wrong conclusion faster.

Also, for the love of GOD please don’t let AI become a substitute for human validation, data governance, taste, trust and ethics. Want to know what AI fluency looks like? Start here.

When I rebranded Patreon, I talked about the idea of a positioning statement that is essentially a madlibs construct that answers a set of questions around target audience, value prop, competitive positioning, etc.

Guess what?!?!? You can do the same thing with your growth system. I present to you, the Growth System Positioning Statement:

Our company grows when [the right customer] enters through [the recurring mechanism], reaches [meaningful value], and then [returns, refers, expands, produces proof, or creates another cycle]. The business captures value through [monetization or strategic benefit]. Today, this system is constrained by [the current bottleneck].

Behold! A thing of beauty. Bask in its glory.

Leave a comment

Done basking? Great.

Choose your next move:

• Run a test when the model contains an important uncertainty.

• Change the process when a known motion is inconsistent or too dependent on team or individual heroics.

• Hire when the work and the persistent constraint are clear enough to name in that paragraph.

Yes, your tactics still matter. Yes, your channels still matter. And yes yes yes, great specialists matter. But they all become much easier to choose once you know what job they need to do inside your growth system.

Start with the system.

You can thank me later.

Thanks for reading; see you in your inbox again soon.

-Adam