What Is Growth Engineering? A Practical Guide for 2026

Most engineering teams build features. Growth engineering is different. You are not building for the sake of shipping. You are building to learn what moves the needle, and then doubling down on it.

I work in growth. A good chunk of my week is spent figuring out what experiment to run next, wiring up the instrumentation, shipping a variant, and reading the results. Sometimes the experiment wins. Sometimes it does not. Either way, we learned something, and that is the point.

This post is my attempt at explaining what growth engineering actually is, when you need it, and what it looks like in the day to day.

What is growth engineering?

Growth engineering is writing code that directly impacts business metrics. Acquisition, activation, conversion, retention. The work sits right at the intersection of product, engineering, and data.

A traditional product engineer might spend weeks building a well-architected feature that ships once. A growth engineer might ship three experiments in the same time, knowing two of them will get rolled back. The code does not need to last forever. It needs to teach you something.

The mental model I use: product engineering is building a house. Growth engineering is setting up tents, seeing which campsite gets the most visitors, and then building the house there.

Where did growth engineering come from?

Growth engineering as a discipline traces back to Facebook around 2007, when Chamath Palihapitiya put together a dedicated growth team. The idea was simple. Instead of treating user growth as a side effect of building a great product, treat it as a problem worth engineering for.

That team is the reason Facebook hit a billion users. The concept spread to companies like Uber, Airbnb, and LinkedIn. Today, almost every company past a certain scale has some version of a growth engineering function.

What do growth engineers do?

I think about growth engineering work in three buckets.

Running experiments that move metrics

This is the most visible stuff. Running A/B tests on onboarding flows, experimenting with pricing pages, optimizing conversion funnels. You are directly tied to a metric and your job is to move it.

A good example: say your signup-to-activation rate is 30%. You hypothesize that a guided onboarding flow could bump that up. You build the variant, split traffic, run it for a couple of weeks, and look at the data. If it works, you ship it. If not, you kill it and move on.

The key here is speed. You are not gold-plating the code. You are validating an idea as quickly as possible.

Building tools for non-engineers to experiment

This is building internal tools so that non-engineers can run experiments without filing a ticket. Maybe it is a landing page builder for the marketing team. Maybe it is a feature flag dashboard that lets PMs toggle experiments. Maybe it is a notification system where ops can set up campaigns without writing code.

This kind of work multiplies the team’s output. Instead of the growth engineer being the bottleneck for every test, you build the rails and let others run on them.

Building the experimentation platform

Someone needs to build the experimentation infrastructure. The A/B testing framework, the analytics pipeline, the feature flag system, the monitoring dashboards. This is the foundation everything else runs on.

It is less glamorous than shipping experiments, but without it, nothing scales. You end up with a mess of hardcoded tests and no way to measure anything reliably.

When do you need growth engineering?

Not every company needs a growth engineer. Here is how I think about it.

Too early: If you are pre-product-market fit, you do not need growth engineering. You need to figure out if anyone wants what you are building. Optimizing a funnel that nobody enters is a waste of time.

The sweet spot: You have a product that people use and pay for. You have enough traffic to run statistically significant experiments. You know your core metrics but they are not moving fast enough. This is when growth engineering becomes valuable.

At scale: Larger companies typically have dedicated growth teams. At this point, even a 2% improvement in conversion can mean millions in revenue. The ROI on experimentation is massive.

Growth engineering vs product engineering

The biggest difference is not the code. It is ownership.

In a traditional product team, a product manager owns the problem and an engineer owns the solution. The PM figures out what to build and why, the engineer figures out how. There is a handoff. The engineer’s job starts after the problem is defined.

A growth engineer owns both. You identify the problem, form the hypothesis, build the experiment, ship it, measure the results, and decide what to do next. There is no handoff. You are the PM and the engineer at the same time.

This changes how you think. A product engineer asks “how do I build this well?” A growth engineer asks “should we even build this, and how do I find out as fast as possible?”

Beyond ownership, the two roles solve fundamentally different problems.

Product engineers solve user problems. They build features that make the product more useful, more reliable, more delightful. A product engineer might spend a month building a great search experience because users cannot find what they need. The measure of success is whether users are happier and more productive.

Growth engineers drive business outcomes. They build experiments that move acquisition, activation, conversion, and retention. A growth engineer might spend a week testing three different onboarding flows to see which one gets more users to their first aha moment. The measure of success is whether a metric moved.

Both are equally important. Without product engineering, there is nothing worth growing. Without growth engineering, a great product might never reach the people who need it. The product engineer makes something people love. The growth engineer makes sure those people find it.

The code reflects this too. Product engineers optimize for durability. The code needs to be maintainable, well-tested, and built to last. Growth engineers optimize for velocity. One mental model I use: if we cannot ship it in a day or two, it is probably scoped wrong. The code needs to go out fast, measure accurately, and be easy to tear down.

This creates tension in teams, and that is okay. The trick is knowing when to write tent code and when to write house code. If an experiment wins and you are keeping it, take the time to rebuild it properly. But do not build a house before you know it is the right campsite.

How I do growth engineering at Valur

My current role at Valur is a mix of growth engineering and sales operations. The two bleed into each other more than you would expect.

Top of the funnel

On the growth side, my focus is mostly top of the funnel. How do you bring in more leads? How do you optimize conversion rates? How do you activate those leads once they show up? At least a part of my week goes into figuring out what experiments to run, looking at data from experiments already running, making sure the tracking and data pipelines actually work, and ensuring the user gets the right messaging at every touchpoint.

The other part ties into sales operations. I work with the ops team to make sure the user gets the right inputs and messages throughout the sales lifecycle. All of it feeds into converting users down the funnel, but the primary focus is still top of the funnel.

My growth engineering stack

I keep it simple. Three tools cover most of what I need.

Claude Code is where I push iterations and spin up quick experiments on our platform. If I want to test a new landing page variant or tweak an onboarding step, I can ship it in hours instead of days.

PostHog handles A/B testing and feature flags. The feature flag system is a nice-to-have that lets me toggle experiments without deploying new code. It also gives me the analytics layer to measure what is working.

Convert.com is for frontend-only experiments. When I want to test copy, layout, or CTA changes without touching the codebase, Convert lets me run those independently.

The data and ops layer

The rest of my week goes into making sure data flows into the right tools and out of the right tools for sales operations, customer support, and outreach. I mostly use Zapier and Python scripts to manage that flow.

This feeds into internal dashboards and external tools like Clay and Google Sheets, which double as my database and enrichment pipeline. Clay helps me do lead scoring, ICP analysis, and finding lookalike companies. This gives my team what they need to run targeted outreach and find customers that look like the ones already converting.

On the CRM side, we use HubSpot. Most of it runs as an engine on its own. There are systems that auto-capture and enrich customer data in HubSpot without anyone having to touch it. Once sales qualifies a lead, we record meetings and use tools like Granola to enrich the data back into HubSpot. This gives us a clear picture of what each user is going through and where they are in the journey.

Engineering effort from my end goes there too. It is not the typical growth engineering work you read about, but it directly impacts how efficiently we convert leads into customers.

One of my next goals is to bring OpenClaw into the growth engineering workflow so that a lot of these systems can run autonomously.

Why wearing multiple hats matters

One advantage I have found in my career is the mix of product, growth, and engineering skills. I can look at a funnel, figure out where it is leaking, design an experiment, and ship the code for it. Not having to hand things off at every step means I move faster.

Funnels vs flywheels: deciding what to test

Deciding what to test is one of the hardest parts of growth engineering. You have to constantly monitor all the different funnels you want to optimize.

I think about the user journey in two ways. Flywheels are the larger picture, where each stage drives the next. Acquisition feeds activation, activation feeds retention, retention feeds referral, and so on. Funnels are the tactics. They are the micro flows you monitor and improve so users make it through each step.

The flywheel tells you where to focus. The funnels tell you what to fix.

Building a growth function?

I spend most of my time thinking about growth engineering and experimentation. If you are figuring this out at your company, happy to chat.

Let's talk growth

How AI is changing growth engineering

AI is reshaping how growth engineering works, and I am seeing it firsthand.

The biggest shift is speed. What used to take a week of engineering time can now happen in a day. I use Claude Code to spin up experiment variants, write data transformation scripts, and build internal tools. The iteration cycle has compressed dramatically. You can test more ideas in less time, which is exactly what growth engineering is about.

But it goes beyond just writing code faster. AI is changing what is possible at each layer of the growth stack.

Experimentation. You can generate landing page variants, email copy, and onboarding flows with AI and test them at a pace that was not realistic before. Instead of running two variants, you can run ten. The bottleneck moves from building the experiment to analyzing the results.

Data and enrichment. Tools like Clay use AI to enrich lead data, score prospects, and find lookalike companies. What used to require a data team and weeks of work now runs as an automated pipeline. I use this daily for ICP analysis and targeted outreach.

Personalization. AI makes it practical to personalize messaging at scale. You can tailor onboarding flows, emails, and in-app messages based on user behavior without hardcoding every path. The user gets the right message at the right time, and you do not have to build a rule engine from scratch.

Autonomous workflows. This is where things are heading. Instead of a growth engineer manually checking dashboards and deciding what to do next, AI agents can monitor funnels, flag anomalies, and even suggest experiments. This is why I am looking at bringing OpenClaw into our workflow. The goal is to have systems that can run parts of the growth loop on their own.

The risk is obvious. If everyone has access to the same AI tools, the advantage shifts from who can build fastest to who has the best strategy and the deepest understanding of their users. The tools level the playing field. What you do with them is what matters.

Common growth engineering mistakes

I have seen a few patterns that trip teams up.

Testing without a hypothesis. If you do not know what you expect to happen, you are not running an experiment. You are just changing things and hoping for the best. Start with “We believe X will cause Y because Z.”

Peeking at results too early. Statistical significance takes time. Checking your dashboard every hour and calling winners after 200 visitors leads to false positives. Set a sample size, wait for it, and then make the call.

Optimizing vanity metrics. Click-through rates are easy to move. Revenue is harder. Make sure you are measuring what actually matters to the business, not just what looks good in a report.

Never cleaning up. Experiments that win should eventually be rebuilt as proper product code. Experiments that lose should be removed entirely. If you never clean up, you end up with a codebase full of dead branches and feature flags nobody remembers.

How to get started with growth engineering

If you are an engineer curious about growth work, here is what I would suggest.

Learn the basics of experimentation. Understand A/B testing, statistical significance, and common pitfalls. You do not need a stats degree, but you need to know enough to not fool yourself with bad data.

Get close to the metrics. Understand how your company makes money. Know the funnel. Know the conversion rates. When you see the numbers, you start seeing opportunities everywhere.

Ship small experiments. Start with low-risk tests. Change a CTA, try a different onboarding step, test a new email subject line. Get comfortable with the cycle of hypothesize, build, measure, learn.

Talk to the business side. Growth engineering does not happen in isolation. You need to understand what marketing cares about, what sales needs, what the data team is seeing. The best growth engineering experiments come from cross-functional conversations.

Growth engineering is not about hacking metrics or writing throwaway code. It is about applying engineering rigor to the question of how you grow. Build fast, measure everything, learn constantly, and double down on what works.