What is Growth Engineering?
Anna Danyi
1 May 20245 min read
Growth engineering is not "marketing with a GitHub account." It is a discipline that combines data, experimentation, and product development to move acquisition, activation, retention, and revenue — on purpose, on a schedule, with a stack you can defend. If marketing owns the promise and product owns the experience, growth engineering owns the wiring that lets you test the promise inside the experience without waiting a quarter.
At Exp(G) we treat growth as a system: every important touchpoint, from landing page to paywall, should be instrumented, testable, and optimisable. That requires engineers who can think like marketers (audience, message, conversion) and marketers who respect systems (events, APIs, pipelines). The overlap is the job.
A working definition
We define a growth engineer as someone who ships product and platform changes whose primary success metric is a growth KPI — not uptime, not pure feature adoption, though those still matter as constraints. They are fluent in experiment design, analytics, and the ugly details of attribution. They care whether revenue and retention moved, not whether traffic spiked.
This definition sits in a lineage most operators already know. Brian Balfour's writing on building growth machines and the curriculum-style thinking at Reforge both stress loops over campaigns. Elena Verna's public talks on growth and PLG (widely summarised across operator communities, including Lenny's Newsletter) push the same point: durable growth is product work with a commercial brain.
What growth engineering is not: a rebranded performance marketing pod, a data science team that never ships UI, or a backlog of "growth ideas" with no owner. If nobody can change the onboarding string without a six-week release, you do not have growth engineering yet — you have a request ticket.
What growth engineers actually ship
- 01
Instrumentation
event taxonomies, identity stitches, exposure logging for experiments, and the boring dictionaries that make retention benchmarks usable on your app rather than as Twitter screenshots.
- 02
Experiment surfaces
flags, remote config, landing stacks, paywall variants, referral surfaces — the pipes that let a marketer's hypothesis become a measured treatment.
- 03
Funnel product work
onboarding steps, empty states, permission prompts, web-to-app bridges — see our web-to-app funnel guide for why this is often higher leverage than another ad set.
- 04
Automation
budget rules, creative QA checks, alerting when a kill line is breached, pipelines that feed AI creatives without turning the brand into sludge.
They also say no. A growth engineer who cannot reject an unmeasured test is just a fast pair of hands. The craft includes pushing back when the proposed KPI is vanity, when the sample size will never clear noise, or when SKAN delay makes the readout date a fantasy. Apple's SKAdNetwork docs are part of the job description whether or not the engineer enjoys reading them.
How the discipline connects to marketing and product
Marketing without growth engineering tends to buy traffic into a funnel it cannot change. Product without growth engineering tends to ship polished features that never meet a paid cohort. Growth engineering is the joint: it translates a campaign insight into a product test, and a product constraint into a brief the creative team can use.
Shared language is the unlock. Agree on payback and early ROAS definitions before the brainstorm — our payback guide and ROAS targets piece exist for that argument. Agree on creative kill criteria before the shoot — see the D7 ROAS kill line. Agree on store conversion work before you scale CPIs — ASO in 2026 and Custom Product Pages.
Externally, experiment platforms and CDPs document pieces of the stack: Optimizely's A/B testing primer for exposure discipline, Segment's documentation for event pipelines, Amplitude for product analytics patterns. Steal the mental models; keep your north-star boring and singular.
Standing up the function without drowning in process
Start smaller than the org chart suggests. One clear metric, one primary funnel, one source of truth for data. Then layer experiments. Then automation. Teams that begin with a six-committee growth council invent process to hide the fact that nobody can ship a paywall variant in under a month.
Staffing can be a dedicated hire, a rotated product engineer with growth KPIs, or an embedded partner while you hire — that last option is exactly why Scale Partners and agency engagements exist. What matters is ownership of the interfaces: who can change the event, who can ship the flag, who can stop the spend.
Use lightweight rituals over heavy frameworks. A weekly readout with pre-committed thresholds beats a monthly "growth summit." A public tools shelf — we publish the Payback Engine and benchmarks for this reason — beats a private spreadsheet only one person understands. Document decisions in the pull request or the experiment brief so the system survives vacation.
What good looks like after ninety days
You will know the function is real when three things are true. First, a non-engineer can propose a test and see it live inside a sprint without a heroic escalate. Second, finance and growth argue from the same table. Third, losers die on schedule. That is the same spine we install on Growth Engine engagements — systems over heroics.
If you are building the function now and want a ruthless audit of metric, funnel, and stack, book a discovery call. Bring your event dictionary and the last three experiments that "felt inconclusive." Inconclusive usually means the engineering was missing, not the idea.
Sources & further reading
Anna Danyi
Founder at Exp(G) — building and scaling mobile apps with AI-powered growth systems. About the team