पाठशाला Pathshala · वृद्धि Vṛddhi, Growth · Lesson 20 · Build

The growth team and its first fifty experiments

A growth team is four or five people from different functions who own one metric, one backlog and one number of their own: experiments shipped a week. How to set it up, and its first fifty tests.

Pathshala, The Founder Library · 11 October 2026 · 7 min read

Rowers in a boat seen from above near a sandy shore and deep blue water. — Photograph: Red Zeppelin · Pexels

Most founders who say they want a growth team want a growth person: one hire who will find the channel that the founders could not. What works is different and less romantic. A small team from several functions owns one number, keeps one list of ideas, and runs more tests a week than feels comfortable, knowing most of them will fail.

This lesson sets up that team. It draws on Andrew Chen’s How to build a growth team, fifty slides from his years running rider growth at Uber, and on the experimentation research of Ron Kohavi and Stefan Thomke at Microsoft and Harvard. Chen’s definition is the one to keep: growth is the scientific method applied to the company’s key metric. Analyse the data, form a hypothesis, prioritise, run the experiment, read it, repeat. Better features alone, he warns, do not guarantee growth.

When a growth team is worth setting up

A growth team optimises something that already works. Before [product-market fit](/library/what-product-market-fit-looks-like-in-the-numbers) there is nothing to optimise, and the founders are the growth team. The signals that it is time are three. Retention cohorts have flattened, so a user who arrives has a reason to stay. There is enough traffic or enough sign-ups to read an experiment in two to four weeks; the [landing page lesson](/library/landing-page-and-first-conversion-test) shows how to compute the sample a test needs. And there is a visible leak: a step in the funnel where most people drop and nobody owns the fix.

If the product sells through a field sales team at ₹20 lakh a contract, a growth team in this sense is premature; the levers are in the sales process, and the [sales playbook lesson](/library/sales-playbook-from-heroics-to-repeatability) is the right next step. Growth teams earn their keep in products with self-serve sign-up, a free tier or trial, a consumer app, or a marketplace, where thousands of people make small decisions inside the product every week.

Who sits on it

Chen lists the roles. A growth product manager owns the experiment roadmap. One or two growth engineers build the tests and make the technical calls. A growth designer leads the interface with an emphasis on speed. A growth marketer specialises in one or more channels, paid, search or email. A growth analyst reads the lifecycle and each experiment. Finance, pricing and operations are pulled in when a test touches them. At a startup of thirty people that is four or five people, some of them part time, and the founder who cares most about the metric acting as the product manager until a hire is made.

There are two ways to place the team. In the pod model each member reports to their home function, engineering to engineering, design to design, and the pod is a standing cross-functional unit. In the business-unit model the team reports to a single growth head and has its own engineers. Chen notes that the second gives more independence and can split the organisation; Facebook and early Uber growth used it, and Uber’s growth team, created in 2013, grew to more than five hundred people at its peak. For a startup the pod model is almost always right. Decide early what the team owns: the new-user flow and onboarding, notifications, the pricing page. A growth team that must ask another team to ship every test will run two a month.

One backlog, one scoring method

Every idea from anyone in the company goes into one sheet, written as a hypothesis: because we saw this, we believe changing that will move this metric by roughly this much, and we will know in this many days. Each idea gets four scores from one to ten: reach, the share of users who will see the change in a test period; impact, the likely lift for each of them; confidence, how much evidence stands behind the hypothesis; and effort, the person-days to build and read. Rank on reach times impact times confidence, divided by effort. Chen’s own scoring weighs effort, likelihood of success and upside, with upside being reach times impact; the formula above is the same idea in four columns.

Two of Chen’s observations change what rises to the top. Reach is usually the biggest lever. A beautiful change to a feature that 3 per cent of users touch will lose to a plain change on a screen everyone sees. And most roadmaps ignore the largest audiences: users who are inactive, churned or never signed up. He cites an exercise at Airbnb that found only six of thirty-three roadmap items aimed at non-users. Score honestly, re-score every fortnight as results arrive, and keep the scoring visible so anyone can see why their idea is fifteenth.

Velocity is the number the team owns

The team does not control whether a test wins. It controls how many tests it runs. That is why the number to manage is velocity: experiments shipped and read a week. The reason is the base rate of failure. Ron Kohavi, Thomas Crook and Roger Longbotham reported in Online Experimentation at Microsoft that of the ideas Microsoft tested, only about one-third were successful at improving the key metric they were designed to improve. If two in three ideas fail even at a company with Microsoft’s data, a team that tests one idea a month will learn almost nothing in a year.

Test tubes holding coloured samples stand in a laboratory rack. — Most samples in a rack show nothing. The lab that runs more of them is the one that finds the sample that does. Photograph: Thirdman · Pexels

The winners that do arrive can be large and unexpected. Kohavi and Thomke describe in The Surprising Power of Online Experiments a small change to how Bing displayed ad headlines which raised revenue by 12 per cent, worth more than $100 million a year in the United States alone. Companies that take this seriously run tests at a scale that sounds absurd: Thomke’s Building a Culture of Experimentation reports that Booking.com runs some 25,000 tests a year. A startup will not. It can run two or three a week from month two, and the figure below shows why that matters more than any single idea.

A growth team cannot choose which ideas will work. It can choose how many it tries. Manage the number it controls.

The first fifty experiments

At two a week the first fifty take about six months. Spend them in roughly this order. Experiments one to five are not experiments: they are instrumentation. Confirm that sign-up, activation, the first paid action and retention are each tracked as one clean event, that an A/A test with identical arms shows no difference, and that the [twelve events](/library/instrumenting-product-twelve-events) are firing on low-end Android as well as on the team’s phones. A test read on broken tracking is worse than no test.

Six to twenty go to activation, the first session: the number of steps to first value, the default settings, the empty state, the first message on WhatsApp, the language of the onboarding. This is where reach is highest, because every new user passes through it. Twenty-one to thirty-five go to the biggest leak in the funnel the team was formed to fix, whichever stage it is. Thirty-six to fifty go to reactivation and referral: the inactive and never-converted users Chen points to, and the moment of ask from the [referral lesson](/library/referral-and-word-of-mouth-by-design). Keep about one test in five deliberately bold, a new pricing page or a different onboarding altogether, because small changes find small wins and the large ones come from ideas the team was unsure about.

Write every result down in the same sheet as the backlog: hypothesis, start and end dates, sample, result, decision and what the team learnt. Losing tests are not waste; each one is a hypothesis the company no longer has to argue about. After fifty, the team should be able to say which kinds of change move its metric and which do not, and its confidence scores should be getting better at predicting results.

The weekly growth meeting

One hour, the same day each week, the whole team. Fifteen minutes on the metric: where it is against last week and last month. Twenty minutes on the tests that finished: result, decision, lesson, each in one line, read aloud. Fifteen minutes on what ships next week: the top of the backlog, re-scored, with an owner and a date for each. Ten minutes on velocity: tests shipped this week against the target, and the one thing that slowed the team down. Set the velocity target at what the team managed last month plus one, and raise it each quarter. Once a month, add the win rate and the average lift of winners, and check them against the figure; if the win rate is above half, the team is testing ideas it already knew would work, and the backlog needs bolder entries.

The numbers in the figure are illustrations; the research cited is from large companies and the sources are below. Ship one test this week.