I’ve lost count of how many times people have asked me to define growth. Is it marketing? Is it product? Is it a repackaging of what we’ve always done? Is it even a thing at all?
It took until I went into ML to truly wrap my head around what growth is. And I think I have an answer I’m happy with -- growth is a search problem.
All growth teams start with a similar problem. You have a product or service, an outcome you want to improve, and what you’ve done to date is not sufficient to hit that goal. The objective function is how you score yourself. Common choices: users, dollars, retention, etc. You literally start, like in a dungeon in Zelda, in a tiny square in a dark map. And while you can move around, you can’t know in advance which direction will work.
This starting dilemma is what has given rise to the craft of growth. That process had many different names, but they all rhyme. Whether it’s Boyd’s OODA loop, Meta’s Understand, Identify, Execute, or Hacking Growth’s growth loop, all include forming hypotheses, making moves, observing what happens, and using what you learn to decide where to move next. All with urgency.
Part of the loop is hill climbing: a local search method for optimizing an objective. As I used to joke with my growth team, to be in growth is to be Sisyphus and embrace all that comes with it.
Understand. Hypothesize. Prioritize. Test. Learn. Repeat. Never, ever stop. This is the Hacking Growth loop. Hill climbing is one part of that loop. Probing unfamiliar levers, revisiting assumptions, or trying a different starting point can take us beyond the next local improvement.
It’s why experimentation velocity mattered so much: every experiment gave us another piece of information about the hills. More swings meant more opportunities to learn where “uphill” was. And the faster you did that the lower opportunity cost you paid for the search and the climb, and the more you reaped the compounding benefits of maximum exploit time.
We’re now at a point where AI changes the economics of that search dramatically.
Because today an agent can take on much of the execution the “growth master” coordinates in Hacking Growth. It’s no longer a person. Your agent can run analyses, suggest experiments, prioritize them for you and ship the code to run them. They can then interpret the learnings and propose where to go next. Work that used to take weeks happens in near real time. The long pole is now collecting reliable evidence to turn another spin through the loop into learning and impact.
You can climb the wrong hill much faster
Every growth team starts in a fog. It’s no coincidence that the growth loop looks like Boyd’s OODA loop— which was all about reducing the fog of war. Growth teams are mandated to reduce the fog surrounding business growth.
And the analogy is quite strong -- you start, standing somewhere in a mountain range in dense fog. You can’t see the terrain, but with a few tests you can tell whether the ground immediately around you slopes up or down. With this information the reasonable strategy is to take steps that lead uphill, check again, and repeat.
Keep doing this and you can reach a local maximum: a point where none of the nearby changes you are considering improves the outcome. But you have no idea whether you’ve climbed Everest or the hill behind your house. A higher peak may exist out there beyond a valley, or along a lever you haven’t considered. That is the limitation of hill climbing. To make matters worse, in reality noisy results and market dynamics make recognizing your position relative to the top even harder.
There are two different ways to climb the wrong hill.
You can choose a useful objective and get stuck at a local peak. This is the local maxima.
The other way? Choose a bad proxy metric for the thing you actually care about. For example, if you choose acquisition but really retention is the core aspect of your business, you’re speeding up your own demise (This is the central growth takeaway of MySpace v. Facebook btw. MySpace worried about registered user growth, Facebook about monthly active users.) The proxy problem is the Goodhart trap of optimizing a measure until it stops serving the objective.
Broader search helps with the first. Better judgment about what we choose to measure is needed for the second. AI can accelerate either mistake.
What does this look like in practice?
I’ve been playing with this problem in a small experiment I call The Allocator. The premise is simple: imagine a business with multiple growth levers. As in real life, some levers matter a lot and others barely. Also as in real life, the growth team doesn’t know which is which. So we’ve created three teams with three different strategic approaches to hill climbing: build and follow a roadmap, leverage bandit testing to probe and find winners, and then use Autoresearch to probe and find sensitivity in the business.
We then hold everything else constant. The teams have the same levers, same traffic and operate in the same market conditions. The objective is cumulative conversions.
Strategy 1: Follow the roadmap
The first behaves like a traditional experimentation program. Pick the next item on the roadmap. Run an A/B test. Wait for the result. Ship the winner. Move to the next item. It’s disciplined. It’s measurable. And it looks a lot like what most would consider ‘standard’ for growth organizations today.
But we all know the assumption that hides here - the order of the roadmap is properly aligned with the size of the opportunities to unlock growth. This is often not true. The fourth item on your roadmap might matter 20 times more than the first. Because you don’t understand the sensitivity of each lever a priori, you just don’t know it yet.
Strategy 2: Get better at allocation
We can do better, and in fact, many do. Instead of sticking to a rigid roadmap and waiting for each test to finish, companies like Booking use bandit allocation strategies in their testing to continually push as much traffic to promising arms ahead of test conclusion. When a test arm or variant performs poorly, it sends less, which minimizes the opportunity cost of learning.
In The Allocator, the bandit already adapts across all levers like one would do in this type of scheme. However, different from strategy 3, there is no upfront lever ranking by sensitivity to start with.
Strategy 3: Map before concentrating
The third strategy makes the lever discovery/search map step explicit. The idea is not new (this is effectively much smarter/speedier “opportunity sizing” that teams should be doing today), but what makes this different and interesting to me is how an autoresaerch approach can make this behavior cheaper and more continuous.
The Allocator models an autoresearch run: before trying to optimize anything, spend a small portion of the budget testing the lever sensitivity -- poke around the map, as it were. It samples the available growth levers to estimate where sensitivity exists and where changing something barely matters.
The best growth teams do this just in slow and imprecise human time and space - I remember my boss at Meta imploring us to run “boundary condition” tests to maximize the sensitivity we could get out of our exploration. I use a similar saying with my team: spend time making a difference where it makes a difference.
A fun note here, for those interested in “how much” time is spend up front. In this model, the initial mapping pass uses about 2.7% of its total traffic budget. That is the upfront cost, not a total exploration budget. Because it will keep while it optimizes and can re-test when performance warrants.
When observed performance deteriorates, autoresearch can reopen the lever it previously ranked highest. It doesn’t need to resurvey everything, but it shows the value of revisiting a prior instead of treating a previous belief as permanent.
The fastest optimizer isn’t necessarily the fastest learner
This one is me changing one of my priors.
Imagine that yesterday your team could run 10 meaningful experiments a quarter. Tomorrow agents let you run 1,000. What should you do? The obvious answer is: Run 1,000 experiments.
I’m increasingly convinced that’s the wrong framing. If your search process is bad, 100x experimentation capacity mostly gives you the ability to search badly 100x faster.
How should I allocate those 1,000 experiments?
- Some should maximize immediate performance (e.g. take the low hanging fruit).
- Some should explore uncertain territory (e.g. how might this channel work for us?).
- Some should deliberately teach us about the system and reduce uncertainty about future investments (e.g. boundary tests).
- Some should revisit parts of the business or competitive environment that may have changed (e.g. challenge “we tried that already”).
- And occasionally, some should take you somewhere that doesn’t appear to be uphill at all (e.g. the big bet).
The trap is that exploration looks inefficient because its return isn’t usually a step forward in growth. If you try to measure exploration in terms of performance, you’re trying to measure the wrong thing, and will make the wrong decision.
What you really are attempting to measure is your information gain. You are spending to acquire knowledge about the landscape. You should design your exploration tests with exactly this in mind. You need tests that yield maximum learning. The worst tests aren’t the losing tests - the worst tests are the ones that leave you knowing exactly what you knew ahead of time.
Most teams tend to prioritize their testing strategy using some heuristic, like a variation of ICE, from Hacking Growth.
Impact × Confidence × Ease.
The problem with ICE though is, its designed for local hill climbing. Specifically, its weakness is ideas with high uncertainty score poorly.
But uncertainty can sometimes be exactly why we should run the experiment. Go back to the boundary tests concept at Meta. These tests are not delivering maximum performance value. In fact, many of them crater core business metrics like revenue/user and time on site. But they teach us the most about the landscape. With that information in hand, we can now take a better shot at the right peak to climb.
The experiment that produces the most immediate growth != the experiment that teaches us the most about the terrain.
Performance experiments optimize the business and should be run. Drive what matters today forward. But don’t neglect the learning experiments needed to improve our understanding of the search space.
Great growth systems need both.
When experimentation becomes cheap, search quality becomes scarce
Agents can make the entire growth loop cheaper. What they can’t be trusted with or can’t deliver is accurate evidence. We still need enough traffic, time for outcomes to mature, and sound measurement to know whether our hypothesis was valid or invalid. As shipping code becomes cheaper, more of the constraint moves upstream: the aim, the search space and the hypotheses.
Do we have the right outcome? Which levers are actually worth changing? How much time or money should be spent exploring versus exploiting? When should we stop doubling down somewhere? When is our map of the terrain no longer true?
The growth practitioner is the architect of the search
The higher-value skill today is designing the environment in which the agent searches and executes effectively. Agents are incredibly productive at whatever you point them at. So the job now is to define the objective. Expose the right levers. Determine which evidence to trust. Decide how much exploration we’re willing to fund. And build visibility to see when we’ve reached the top of the wrong hill.
Maybe we’re optimizing landing-page conversion when the real opportunity is pricing. Maybe we’re optimizing pricing when the problem is language-market fit. There are a thousand maybes. No algorithm solves that automatically. At some point you have to ask how you want to attack the unknown parts of the map. You have to choose.
As an aside, the product discourse on X lately contains a lot of talk about taste as a differentiator and a moat for products. I think taste is really short-hand for a magic wand of skipping over all the sub-optimal end states to the one that matters.
How “taste” translates to growth is really how good is your search quality?
Optimization focuses on: How do I improve my current approach?
Search design asks: Which directions should I test, and what is worth learning?
Growth strategy asks: Which mountain would be worth summiting in the first place?
Agents are going to play a bigger part in all of these questions. But the needs of the system will move up the stack. It’s our job to deliver what the system needs to unlock future growth.
Growth teams have alway started with the principle that we don’t know the answer. That objective data will help us figure out where to go. It has always been search. It was just slow and manual and if you didn’t have the endurance of Sisyphus it was easy to give up on at times.
Now with agents willing to hill climb without fatigue, as shipping another variant becomes cheaper, the advantage won’t simply belong to whoever ships the most. It will depend on how well we use the scarce resources of time, traffic and trustworthy evidence we have.
Winning will go to whoever builds the best system for giving the machine a clear aim.
In good news for many of us, the future of growth isn't just faster hill climbing. It's better search.
Originally published on X on September 8, 2026.