.png)
"Growth" has become one of the most overloaded words in SaaS. Every company claims to be focused on it. Most either skip building a dedicated growth team entirely or build one wrong — hiring a few people, calling them a growth team, and wondering why nothing changes six months later.
The core tension is real: growth is too important to leave to chance, yet too cross-functional to belong cleanly to any single department. Marketing can't own it alone. Product can't own it alone. And handing it to sales creates a different set of problems entirely.
This guide is the only resource you'll need on the topic. It covers what a growth team actually is, how to structure one for your company's stage, which roles to hire, how to run experiments that compound over time, and how to measure whether any of it is working. Whether you're building your first growth team or trying to fix one that isn't performing, start here.
A growth team is a cross-functional unit focused on identifying and accelerating the levers that drive sustainable business growth. It typically spans the full funnel — acquisition, activation, retention, revenue, and referral — rather than owning just one slice of it.
That scope is what makes it different from traditional marketing, product, or sales functions. Marketing tends to own top-of-funnel awareness and demand generation. Product owns the roadmap and feature delivery. Sales owns revenue conversations. None of them, by design, own the connective tissue between all of those stages.
Growth teams emerged as a distinct discipline precisely because siloed departments create gaps. When no one owns the full funnel, users fall through the cracks between teams. Activation suffers because marketing considers its job done once someone signs up, and product is focused on building features rather than ensuring new users reach their "aha moment."
The other defining characteristic of a growth team is its orientation toward rapid experimentation. Rather than running quarterly campaigns or annual roadmap cycles, growth teams operate in short loops — forming hypotheses, running tests, analyzing results, and iterating. That cadence is structurally incompatible with how most marketing and product teams are built to operate.
The mental model to hold: a growth team is not a rebranded marketing team, and it's not a product team with a different name. It's a distinct function with a distinct operating model, built to find and exploit the highest-leverage growth opportunities across the entire user journey.
Before you hire anyone or draw an org chart, you need a charter. This is the single most skipped step in building a growth team — and the single most common reason growth teams fail.
A growth team charter is a short, explicit document that defines four things:
The charter needs to be aligned with company strategy, which means it requires executive buy-in before the team is operational. Without that alignment, the growth team will spend half its energy defending its existence and negotiating access to resources rather than running experiments.
Ambiguity in the charter is the fastest path to dysfunction. If the charter doesn't clearly define what the growth team owns, every initiative becomes a political negotiation. Product will push back when growth touches the product. Marketing will push back when growth runs acquisition experiments. Clear scope prevents those conflicts before they start.
A strong charter is short — one page, not ten. It answers the question "what does this team exist to do and how will we know if it's working?" If it can't answer that clearly, it needs more work before the team is built around it.
Not every company is ready for a dedicated growth team, and building one too early is a common and costly mistake. The clearest signal that you're ready: you have product-market fit.
Without PMF, a growth team will accelerate the wrong things. You'll get better at acquiring users who churn, or retaining users who don't actually find value in the product. Growth infrastructure built on a leaky foundation doesn't compound — it just burns money faster.
Beyond PMF, you need a baseline of user data and enough traffic or users to run meaningful experiments. If your sample sizes are too small, you can't reach statistical significance on tests, which means you're making decisions based on noise rather than signal.
The right growth team model varies significantly by company stage. Applying a one-size-fits-all structure is a mistake.
Early-stage startups (post-PMF, pre-scale): One strong generalist growth hire may be all you need. This person should be comfortable across data, experimentation, and cross-functional coordination. Building a full squad before you have the data infrastructure and user volume to support it is premature.
Growth-stage companies: This is where a full growth squad makes sense — a dedicated team with a growth lead, growth PM, engineer, and analyst working in a structured sprint cadence. The company has enough scale to run meaningful experiments and enough complexity to justify dedicated ownership.
Enterprises: Large organizations often run multiple growth pods, each focused on a specific product line, user segment, or funnel stage. Coordination between pods becomes a significant operational challenge at this stage.
The honest question to ask before building: does our current stage and data infrastructure actually support the kind of experimentation a growth team needs to run? If the answer is no, fix that first.
In the centralized model, a standalone growth team operates independently from product and marketing, reporting directly to a C-suite leader — typically the CEO, CPO, or a dedicated Chief Growth Officer.
The advantages are real: speed, focus, and clear ownership. The team isn't competing with other priorities for engineering time or design resources. It can move fast because it controls its own execution capacity.
The tradeoffs are also real. A centralized growth team risks misalignment with the core product roadmap. If growth is building experiments that conflict with where product is taking the product, you get confusion and duplicated effort. There's also a risk of siloing — the growth team becomes its own island, disconnected from the institutional knowledge that lives in product and marketing.
In the embedded model, growth specialists sit within existing product or marketing squads rather than forming a separate team. A growth PM might sit within a product squad. A growth marketer might sit within the demand generation team.
This model works best when the company isn't ready for a fully independent growth function but wants to inject a growth mindset and experimentation capability into existing teams. It requires those existing teams to genuinely prioritize growth work — which is where it often breaks down. When embedded within a larger team, growth work tends to get deprioritized in favor of the team's primary objectives.
The hybrid model combines a small centralized growth function with embedded growth resources across product lines or business units. A central growth team sets strategy, owns the metrics framework, and runs cross-cutting experiments. Embedded growth resources execute within their specific domains.
Many scaling companies land here because it balances the speed of centralization with the contextual knowledge of embedded resources. The coordination challenge is real — you need clear mechanisms for sharing learnings across the central and embedded functions, and clear ownership rules to prevent confusion about who's running what.
The best structure is the one that minimizes friction and maximizes experimentation velocity for your specific context. To choose:
There's no universally correct answer. The wrong answer is picking a structure based on what sounds impressive rather than what fits your actual context.
The head of growth sets strategy, owns the team's KPIs, manages prioritization, and serves as the bridge between growth work and executive stakeholders. This person is accountable for the team's outcomes — not just its activities.
What separates a strong growth lead from a generalist marketer or PM is their ability to operate across the full funnel, design and interpret experiments, and make prioritization decisions under uncertainty. They're comfortable with data, comfortable with ambiguity, and capable of earning trust from both technical and non-technical stakeholders.
The growth product manager differs from a traditional PM in a fundamental way: their focus is on funnel metrics, experiment design, and cross-functional coordination rather than feature delivery alone. A traditional PM ships features. A growth PM runs tests.
This role is often the operational backbone of the team — managing the experiment backlog, coordinating execution across engineering and design, and ensuring that learnings are documented and applied. Without a strong growth PM, experiment velocity tends to collapse.
Engineering capacity is non-negotiable for a high-functioning growth team. Without it, the team can generate ideas but can't execute them — which means it's not actually a growth team, it's a growth advisory committee.
Growth engineers differ from product engineers in their orientation. They prioritize speed of iteration over code elegance. They're comfortable building scrappy tests that might be thrown away. They're willing to work in ambiguity and ship things that aren't perfect in service of learning faster.
The analyst builds the measurement infrastructure, interprets experiment results, and surfaces insights that drive prioritization. Without strong analytics, a growth team is flying blind — running tests it can't properly evaluate and making decisions based on intuition rather than evidence.
This role is often underinvested in early-stage growth teams. The consequence is a team that runs a lot of experiments but can't confidently say what's working or why.
Design and copy contribute directly to growth experiments — from onboarding flows to landing page tests to in-product messaging. These roles are frequently undervalued on growth teams, treated as execution resources rather than strategic contributors.
Some teams use contractors or shared resources for design and copy, which can work when the team's experiment volume is low and the work is well-scoped. It breaks down when experiment velocity increases and the team needs fast, iterative design support that shared resources can't provide.
One of the most politically charged aspects of building a growth team is ownership. Who decides which experiments to run? Who has final say on prioritization? When growth wants to change an onboarding flow that product built, who wins?
These questions need explicit answers before the team is operational — not after the first conflict surfaces.
A RACI framework (Responsible, Accountable, Consulted, Informed) applied to growth work gives the team a clear map of who owns what. For each type of decision — experiment prioritization, experiment design, execution, analysis, and shipping — define who is responsible for doing the work, who is accountable for the outcome, who needs to be consulted, and who just needs to be informed.
Ambiguous ownership is the fastest path to a dysfunctional growth team. When it's unclear who can approve an experiment or who has authority to ship a change, every decision becomes a negotiation. That kills velocity, which is the one thing a growth team cannot afford to lose.
Draw clear boundaries with product, marketing, and engineering. The growth team should be able to move fast within its defined scope without creating conflict — and when it needs to operate outside that scope, the escalation path should be clear and fast.
Before a growth team can run experiments, it needs to know where to focus. Running experiments on the wrong channels — channels that are too expensive, too saturated, or too small to move the needle at scale — is one of the most common ways growth teams waste their first six months.
A channel viability analysis evaluates potential acquisition and retention channels based on several factors: market size, cost economics, competitive saturation, and scalability. The goal is to identify channels that are financially viable and can scale without hitting diminishing returns too quickly.
This analysis should directly inform the growth team's initial roadmap. It prevents the team from defaulting to the channels that feel familiar or that worked at a previous company, and forces a rigorous evaluation of what will actually work for this product, at this stage, in this market.
The output of a channel viability analysis isn't a final answer — it's a prioritized starting point. As the team runs experiments and gathers data, the channel mix should evolve.
The North Star Metric is the single number that best captures the value the product delivers to users — and that the entire growth team rallies around. It's not a revenue metric (that's a lagging indicator). It's a leading metric that predicts long-term retention and revenue.
A good North Star Metric is actionable (the team can run experiments that move it), leading (it predicts downstream outcomes rather than reflecting past ones), and aligned with genuine user value rather than vanity. If your North Star Metric can go up while users are churning, it's the wrong metric.
Beneath the North Star, you need a tiered metrics framework that covers the full funnel — acquisition, activation, retention, revenue, and referral. Each layer should have clear owners and measurable targets. Each metric should connect back to the team's charter and, ultimately, to the North Star.
This framework prevents the team from over-indexing on one part of the funnel while neglecting others. It also creates a shared language across the team and with executive stakeholders — everyone knows which metrics matter and what "good" looks like. For a deeper look at how these metrics connect to product-led growth, product-led growth metrics is worth reading alongside this framework.
Before running any experiment, define what success looks like. That means setting statistical significance thresholds, minimum detectable effects, and a clear decision rule for when to call the test.
The most common trap is calling tests early — seeing a promising result after a few days and shipping the winner before the test has reached significance. This produces false positives that send the team in the wrong direction.
Experiment velocity — the number of quality tests run per unit of time — is itself a key performance indicator for a growth team. A team that runs two rigorous experiments per week will outlearn a team that runs one sloppy experiment per month, regardless of individual test outcomes.
The weekly growth meeting is the heartbeat of the team. It's where experiment results get shared, decisions get made, and the team stays aligned on priorities. Without it — or with inconsistent execution of it — the team drifts.
A well-run weekly growth meeting reviews active experiments, discusses results from completed tests, makes prioritization decisions for the upcoming sprint, and surfaces blockers. It should be tight, structured, and decision-oriented — not a status update.
Growth teams should manage their work in sprints, typically one or two weeks. The experiment backlog is the team's primary planning artifact — a prioritized list of hypotheses waiting to be tested.
Prioritization frameworks like ICE (Impact, Confidence, Ease) or PIE (Potential, Importance, Ease) give the team a structured way to rank experiments without defaulting to whoever argues loudest. The backlog should be a living document, continuously updated as new ideas surface and old ones are validated or invalidated.
The balance between quick wins and longer-horizon bets matters. A team that only runs quick, easy experiments will optimize local maxima. A team that only swings for big bets will have long dry spells with nothing to show. Both types of experiments belong in the backlog.
Weekly meetings keep the team moving. Monthly and quarterly reviews keep it pointed in the right direction.
Monthly metric reviews zoom out from individual experiments to assess whether the team's overall approach is working. Are the supporting metrics trending in the right direction? Is the North Star moving? If not, why not?
Quarterly strategy recalibrations give the team a chance to reassess its charter, its channel mix, and its prioritization criteria in light of what it's learned. Growth strategy should evolve as the team accumulates evidence — quarterly reviews create the forcing function for that evolution.
A repeatable experiment process — not individual brilliance — is what separates high-performing growth teams from chaotic ones. The end-to-end process looks like this:
Every experiment should go through this process. Skipping steps — especially instrumentation and documentation — is how teams end up with results they can't trust and learnings they can't build on.
Experiment ideas should come from multiple sources: quantitative data (where are users dropping off?), user research (why are they dropping off?), competitive analysis (what are others testing?), and team brainstorms. Relying on any single source creates blind spots.
Once ideas are in the backlog, score and rank them using a consistent framework. The goal is to run the highest-expected-value experiments first — not the most interesting ones, not the ones the loudest person in the room suggested.
Avoid the failure mode of running too many low-quality tests simultaneously. Spreading execution capacity across ten mediocre experiments produces ten inconclusive results. Concentrating it on two or three rigorous experiments produces actual learning.
A failed experiment with a clear learning is more valuable than a "winning" test that can't be explained or replicated. This is a cultural point as much as an operational one.
Growth teams need to create psychological safety around failure — not to celebrate failure for its own sake, but to ensure that negative results are documented, shared, and used to sharpen the next hypothesis. Teams that hide or ignore failed experiments repeat the same mistakes. Teams that learn from them compound their knowledge over time.
The documentation habit is what makes this possible. If failed experiments aren't written up and shared, the learning dies with the person who ran the test.
One of the biggest bottlenecks for growth teams working on activation and onboarding is engineering dependency. Every time the team wants to test a new onboarding flow, add a tooltip, or change an in-product message, it needs to get into the engineering queue. That queue is almost always long. Experiment velocity collapses.
Appcues removes that bottleneck. It gives growth teams a no-code layer to build, test, and iterate on in-product experiences — onboarding checklists, tooltips, modals, feature announcements — without waiting on engineering. The team can go from hypothesis to live experiment in hours rather than weeks.
Specific capabilities that matter for growth teams:
Appcues isn't a marketing tool. It's growth infrastructure — the layer that lets growth teams run more experiments, faster, on the part of the funnel that most directly impacts revenue. Activation and retention are where growth teams can have the highest leverage, and they're also the stages most dependent on in-product experiences. That's exactly where Appcues operates.
Starting without a clear charter. The team gets hired, gets excited, and starts running experiments before anyone has defined what the team actually owns. Six months later, there's conflict with product and marketing, and no one can point to a clear win. Fix: write the charter before you hire.
Optimizing for vanity metrics. Signups, page views, and MQLs feel like progress but don't predict retention or revenue. A growth team that optimizes for metrics that don't connect to real user value will produce impressive-looking dashboards and disappointing business outcomes. Fix: anchor everything to the North Star and supporting metrics that connect to retention.
Running too many experiments at once. More experiments sounds like more learning, but spreading execution capacity too thin produces inconclusive results across the board. Fix: concentrate resources on fewer, higher-quality tests.
Neglecting activation and retention in favor of acquisition. Acquisition is visible and feels like growth. But if users aren't activating and retaining, acquisition spend is just filling a leaky bucket. Fix: ensure the metrics framework covers the full funnel and that experiment prioritization reflects the highest-leverage opportunities — which are often in activation, not acquisition. The 5-step growth framework is a useful reference for thinking about funnel balance.
Failing to document and share learnings. Teams that don't write up experiment results — especially failures — repeat the same mistakes and lose institutional knowledge when people leave. Fix: make documentation a non-negotiable part of the experiment process, not an optional afterthought.
Building before product-market fit. A growth team can't fix a product that users don't want. Investing in growth infrastructure before PMF accelerates churn, not growth. Fix: confirm PMF before building the team.
A great growth team doesn't happen by accident. It starts with a clear mission and charter, is structured to match the company's stage and context, and operates with disciplined rituals and a rigorous metrics framework. Most importantly, it treats experimentation as a repeatable system — not a series of one-off bets.
The teams that win over time are the ones that build compounding learning loops. Each experiment makes the next one smarter. Each failed test eliminates a wrong hypothesis. Each documented learning becomes institutional knowledge that survives personnel changes and strategy pivots.
As competition for user attention intensifies, the companies with the most disciplined growth teams — the ones that can run more experiments, learn faster, and iterate without friction — will have a structural advantage that's very hard to replicate.
The activation and onboarding stage is where many of those experiments need to happen. And that's exactly where engineering dependency kills velocity.
See how growth teams use Appcues to run onboarding experiments. Start your tour or book a demo today.
.png)