Organizational design: growth and PM teams need one metric tree and one decider per screen

An onboarding test lifts activation from 22% to 25%. The growth team calls it a win and ships it. Two months later the product team asks what happened to 30-day retention on that cohort, and nobody owns the answer.

Plenty of companies have a growth team and a product team. The ones that perform get the two to run as a single system. The hard part is rarely strategy. It is the everyday mechanics. Who decides what? Which numbers do both sides trust? How do tests move fast without turning the product into a patchwork?

The stakes rise as products rely more on data, AI features and short release cycles. Each of these means more changes every quarter. And each change lands on a screen both teams think they own.

Growth and product collide on the same four surfaces

The two functions come from different traditions. Growth teams grew out of performance marketing and experimentation culture. Product teams grew out of strategy, UX and engineering collaboration. Those traditions carry different instincts about speed, evidence and risk, and most companies now need both.

When the pairing fails, the cause is usually simple: nobody agreed how the two teams work together. Back in 1968 Melvin Conway noticed that a product copies the way the people who build it talk to each other. If growth and product have no clear way of working together, users see it as an onboarding flow with two owners and no author.

Four tensions appear the day growth becomes its own team.

1. Ownership. Who owns activation, onboarding or retention experiments? Without a written answer, teams work against each other on the same screen.
2. Time horizon. PMs optimize long-term value; growth optimizes this quarter's funnel. Both are right, and they end up solving different problems.
3. Speed versus predictability. Growth needs fast, iterative tests. Product manages architectural dependencies and UX consistency. Misalignment slows everyone.
4. Metric interpretation. Growth reads CAC, activation, A/B lifts and retention curves. PMs read product-market fit and the north-star metric. Without one system, analysis fragments.

The time-horizon tension is built in. A growth test shows a result in two weeks. But users keep learning and changing their habits after they see the change. So the damage to the product may show up two months later, when nobody links it to the test anymore. The onboarding test in the opening is exactly that case.

One metric tree and one decision matrix settle most fights

The two-track model splits the work on the core product from the work on the funnel, but keeps the two closely linked. The product team owns core UX, feature strategy, long-term value and the roadmap. The growth team owns experimentation, funnel efficiency and activation and retention improvements.

The split holds because clear boundaries cut coordination cost as headcount grows. Shared metrics keep those boundaries from turning into walls.

A workable hierarchy has four levels:

1. a single north-star metric, the primary value indicator (for example, weekly active users completing the key action);
2. the growth levers: acquisition, activation, retention and monetization;
3. product metrics: feature adoption, task success, friction points;
4. experiment metrics: A/B lifts and local optimizations.

Both teams work inside the same tree but lean on different levels. The tree also protects against a familiar failure. A level-four metric promoted to a quarterly goal gets optimized for its own sake: the button gets clicked more, and the levels above it stop moving.

On top of the metrics sits a shared way to run tests. It includes a hypothesis template, a scoring method for choosing tests (such as PIE, ICE or RICE), agreed rules for reading results, QA and release steps, regular reviews, written decisions and one shared library of what was learned. Growth runs the experiments; product checks that they fit strategy and technical constraints.

Dedicated analysis tools help teams gauge A/B significance and confidence, and a shared reference on reading statistical significance in A/B tests keeps interpretation disputes from resurfacing every cycle.

The repository earns its place through arithmetic. Most experiments do not produce a win. At 120 tests a year and, say, a 15% win rate, a company gets 18 winners and 102 tests that did not work. If those 102 are not logged with hypothesis, segment and result, someone reruns a third of them next year under a new name.

The last piece of shared vocabulary is a decision rights matrix that names who decides, who consults and who implements in each domain:

The matrix works only if it names a final decision-maker and says what happens when product and growth disagree. A good tie-breaker is the metric tree itself: when two options are close, the one that protects the north-star metric wins.

Each role owns a stretch of the funnel

The product manager owns strategy, the value proposition and long-term vision. The PM defines the user problems and how the experience fits together. They keep features consistent and work with engineering so the product can grow. They also stop the team from polishing small details while the bigger picture suffers, a common side effect of narrow tests.

The growth product manager owns funnel performance and the experiment roadmap. This person works with design, analytics, engineering and marketing. They focus on removing friction and on onboarding and messaging changes. They run fast test cycles and check what each change does to CAC payback, LTV and retention.

Three supporting roles make the pair work:

• Growth engineers build the test setup, the variants, the tracking and the on/off switches for features. How good this setup is limits how many tests the team can run.
• Data scientists and analysts check what really caused a change, split users into groups, measure lifts and build models that predict buying and churn. They also make sure both sides read the data the same way.
• Design and lifecycle keep the experience consistent across rapid changes, while marketing and lifecycle ops build acquisition funnels and CRM journeys around activation and retention loops.

Structured capability evaluations help when building or assessing growth-PM skill sets in a scaling organization.

The loops show why neither role can work alone. In acquisition, the PM owns the value proposition and growth owns distribution mechanics. In activation, growth optimizes the flows and the PM ensures they fit the product's architecture. In retention, the PM leads feature-level engagement while growth tests triggers, messaging and timing. In monetization, the PM owns pricing strategy and growth validates willingness to pay and ARPU gains.

Reforge's 2018 essay "Growth Loops are the New Funnels", written with Andrew Chen, gives the reason: in a loop, the output of one cycle becomes the input of the next, so a weak link owned by either team breaks the whole cycle. Scenario-modeling tools help leadership weigh the financial implications of different loops and experiment portfolios.

Pick the org shape for your stage, then write the decision rights

No single arrangement fits every company. Four shapes have held up in practice:

1. Growth embedded in squads. A shared growth PM or engineer sits inside each product squad. It suits mid-sized companies and spreads growth thinking everywhere, but needs central coordination to avoid duplicated tests.
2. Central growth team beside product squads. A full-stack growth unit owns funnel optimization while PMs own product strategy. It scales experimentation rigor, but demands explicit decision rights so growth does not step on feature teams.
3. A product-led growth structure with hybrid ownership. Growth specialists sit inside squads while a central PLG function sets experimentation standards. It works well for SaaS companies pushing self-serve motions.
4. Mission squads. Teams form around one outcome (activation, retention or monetization) with joint PM and growth ownership.

Matthew Skelton and Manuel Pais offer useful words for shapes 2 and 3 in "Team Topologies" (2019). Squads are stream-aligned teams, each owning one part of the product. A central growth team works best as an enabling or platform team that takes work off the squads, not as a rival.

A caution about copying any shape wholesale. The most imitated one, Spotify's squads, tribes, chapters and guilds, comes from a 2012 white paper by Henrik Kniberg and Anders Ivarsson. Kniberg later stressed that it described how the company happened to work at that moment, and that Spotify kept changing it. Copy the decision rights you need and leave the vocabulary behind.

Headcount sets a rough guide. Treat it as a starting point:

• Around 20 people in product: one hybrid PM/growth role is enough. Focus it on onboarding, activation and the core loops, and keep metrics simple.
• Around 5 to 15 squads: build a dedicated growth team, introduce experimentation governance, separate discovery from growth execution and use capability assessments when hiring.
• Around 200 people and several product lines: formalize decision rights, run a cross-squad growth council, feed growth insights into portfolio strategy and plan multi-quarter bets with scenario models.

If a company runs fewer than one test per squad per month, structure is not yet the bottleneck. Experiment infrastructure is.

The weekly rhythm decides whether a test ships, iterates or dies

Coordination lives in a few rituals: a weekly funnel review, joint planning of the experiment roadmap, a monthly strategy sync, a quarterly reset of metrics and goals, and post-test retrospectives. A lean version costs each PM about three hours a month: 30 minutes a week on the funnel and an hour on strategy.

A typical experiment passes through both functions in order:

1. the PM spots a user pain point in onboarding;
2. the growth PM designs variants to remove the friction;
3. a growth engineer builds the variant under the PM's UX guidance;
4. an analyst sets up instrumentation and metrics;
5. the PM reviews UX, compliance and engineering constraints;
6. the growth PM launches and monitors;
7. the two make a joint call to scale, iterate or kill.

That sequence stops strategic thinking and tactical optimization from pulling in opposite directions. One more ritual is worth adding: every test that ships to 100% returns to the agenda 60 days later with retention for the affected cohort.

Worked example: the scale-iterate-kill call (illustrative)

An onboarding activation experiment runs for two weeks:

• Control: 4,000 users, 22% reach the activation event (about 880 users).
• Variant: 4,000 users, 25% reach it (about 1,000 users).
• Absolute lift: 3 points; relative lift: about 14%.

First, is the result real? A standard test for comparing two shares (a two-proportion z-test) gives z of about 3.2 and a p-value near 0.002. That easily clears the usual 5% bar, as long as the sample size was fixed in advance. A test stopped on its first good day after daily checks proves little. Every look gives random noise another chance to cross the line.

Then the growth-versus-product call. Activation rose, but does retention hold? Say 40% of activated control users are still active at day 30 (352 users), against 37% on the variant (370 users). The retention rate fell 3 points, yet the variant still retains 18 more people per 4,000 sign-ups, about 5% more.

The decision rule is to judge the variant on retained users per sign-up, the number closest to the north-star metric. Here it says scale, with a watch on the cohort. If retained users had fallen, the variant would have bought a vanity number: iterate or kill.

Only a lift that survives that check belongs in the CAC math. On the same acquisition spend, 1,000 activations instead of 880 lower effective CAC per activated user by about 12%. Per retained user, the gain shrinks to about 5%. That smaller figure is the one for the payback model.

Where the structure breaks, and what fixes it

Most failures trace back to the same few gaps, and each has a symptom you can check:

• Conflicting KPIs. Symptom: test count rises while the north-star metric stays flat for two quarters. Fix: one metric hierarchy.
• Growth running apart from product strategy. Symptom: two open tickets from different teams on the same screen. Fix: shared quarterly planning and the decision matrix.
• A PM blocking test velocity. Symptom: more than three weeks from idea to launch. Fix: predefined guardrails, experiment templates and UX-consistency rules.
• Growth chasing local maxima. Symptom: activation up, 60-day retention down. Fix: PM stewardship over long-term value and journey coherence.
• Weak experiment governance. Symptom: the same hypothesis tested twice in a year. Fix: dedicated analysis tooling and a searchable repository.

Rules have a real cost, and growth people say so. Their strength is testing without asking permission. Kitemaker's 2023 essay "More product, fewer PMs", written after Airbnb restructured its product management organization, captured that mood, and its title states the thesis.

In a single-squad startup in its first year they are right, because coordination costs more than the mistakes it prevents. The argument weakens once a bad test touches thousands of users, or once the flow carries regulatory or financial risk such as identity checks or payments. From then on, written rules are what let a team test fast without asking each time.

Two recurring questions have short answers. Growth usually reports into product, which keeps it tied to core UX and long-term strategy. Test velocity should climb steadily, but governance and quality matter more than raw volume.

Settle the decision rights before redrawing the org chart: any row in the matrix without a single decider is where the next fight starts.