At an online coffee shop in Almaty, an unfinished-order reminder was left in a marketer's personal account. The marketer moved to another project, and buyers started receiving emails after paying. The owner asks in the shared chat who can stop the sends. The analyst has the report and the developer has the code, but someone still has to find access to the flow itself.
Suppose this happens after a test led the shop to keep the reminder. The example is illustrative; the shop keeps 6,000 ₸ from a 15,000 ₸ order, as in the customer-base calculation. The growth team must hand over both the test conclusion and an operational process with someone to maintain it.
Build the team around the work
A growth team brings together people who understand the business, investigate behaviour, implement a change and evaluate its outcome. One person can cover several functions in a small project. Calling a marketer the growth lead does little if the developer and analyst are available only in their spare time.
In his essay on building a growth team, Brian Balfour draws on a conversation with Andrew Chen to consider different team sizes. For this shop, begin with the work: who will investigate unfinished purchases, change the website and connect the data to the CRM?
Before work begins, the owner allocates specialist time and authority. The team knows which copy and settings it can change and which questions need a product or sales owner's decision. Prices, payment terms and customer data do not become unrestricted experimental territory because the team has "growth" in its name.
One change has several areas of responsibility
One person is responsible for taking the whole test through to a decision. They track agreements, remove delays and bring the result together. That does not give them authority to declare faulty data valid or release a change outside agreed constraints.
The shop divides the reminder work as follows:
| Area | Owner in this example | What they hand to the next participant |
|---|---|---|
| Business question | Shop owner | Expected result, constraints and spending limit |
| Customer journey | Marketer and designer | Reason for contact, copy and the path back to ordering |
| Measurement | Analyst | Groups, metric, observation window and reading plan |
| Implementation | Developer | Configured flow, event log and a way to stop it |
| Ongoing operation | CRM specialist | Monitoring of sends, errors and complaints |
One employee can fill two rows, but every row needs time and access. If there is no CRM specialist, the owner chooses someone else and adds the work to their allocated workload.
The illustration shows a folder and an acceptance checklist being handed over. Its three items are owner, monitoring and rollback. In the project, each item needs a testable result.
Agree who can stop a launch
The reminder has rules spanning several teams. A placed order prevents sending, including one entered by a manager. Unsubscribes reach the sender. Support knows who answers a buyer's reply. A delayed status cannot silently be treated as no order.
The marketer describes these cases, the developer implements them, and someone from sales reproduces an order from their side. The trigger flow is accepted across its whole path, including what happens outside the messaging interface.
Agree beforehand which failures block release. An acceptance test might find an email sent after an order or to someone who unsubscribed. The flow goes back for repair. There is no need to wait for a statistical sales conclusion: a process requirement has already failed.
If the analyst and lead disagree, it must be clear who decides and where the reasoning is recorded. "We need to ship by Friday" cannot repair a lost denominator. The team can narrow the change, delay launch or run only a technical test, keeping its status clear.
A working week and a test window are different schedules
A weekly meeting can cover decisions ready to make, current blockers, upcoming work and upkeep of released changes. That cadence does not require every experiment to produce an answer within a week.
Set recruitment duration, outcome window and stopping rule before launch. For example, a repeat-purchase reminder test plan depends on buyer volume and time to a repeat order. This is a different scenario with its own timing; do not transfer its plan to an unfinished-order reminder. A meeting can uncover a data error, but recruitment cannot end simply because today's chart looks favourable.
Tie the number of open tasks to available hours. If the developer has twelve hours and one selected integration uses all twelve, four more cards in "In progress" add no capacity. The lead chooses an order, frees up time or changes the scope.
An unsuccessful test can still end with a useful conclusion. Keep the question, data, limitations and decision: drop the idea, repair measurement or prepare a new test. Insufficient data remains insufficient data; it need not move into the "success" column.
The work costs money before it produces a result
For this example, the shop values an hour at 5,000 ₸, as in the tool comparison. This is an internal budgeting assumption, not a rate for a particular profession.
| Preparing the change | Hours | Cost |
|---|---|---|
| Scenario and copy | 8 | 40,000 ₸ |
| Layout and customer path | 4 | 20,000 ₸ |
| Implementation and failure tests | 12 | 60,000 ₸ |
| Measurement plan and analysis | 6 | 30,000 ₸ |
| Total | 30 | 150,000 ₸ |
The shop budgets another four hours a month for maintenance after rollout, or 20,000 ₸. Preparation and the first three months of maintenance cost 150,000 + 3 × 20,000 = 210,000 ₸. At 6,000 ₸ contribution per order, that equals 35 additional orders. Service subscriptions and message costs are excluded.
Thirty-five orders placed after emails do not automatically cover that calculation: some customers would have ordered anyway. Estimating added orders needs the planned comparison's results. The budget describes the cost of the work and the requirement for recovering it, without promising an effect.
Name hours freed for an employee separately too. Being able to use them for other tasks is valuable. Payroll costs do not disappear merely because automation saves a few hours.
Handover to ongoing operation needs acceptance
After the decision to keep the flow, the CRM specialist receives access through the company's working account. An employee's personal passwords are not pasted into a chat. Settings, connection owners and instructions live somewhere a holiday replacement can find them.
The handover includes the audience, trigger, exclusions, schedule, copy and source for every status. Metric definitions, a change log and contacts for data and code repairs sit alongside them.
The new owner runs the test: places an order, sees it excluded from sending and finds the reason in the log. They then stop the flow and establish that messages already queued follow the stopping rule too. An off switch that leaves the queue unchecked may leave emails running.
If a feature flag was used, decide whether the switch is still needed. Assign an owner and removal date to temporary code. Exclude test contacts, review temporary access and explain the change to support.
Gradual rollout and observation afterwards help detect operational faults. Keep the experiment conclusion separately: expansion to a different audience needs an assessment of the differences.
Assess the team's work
A useful report shows tests started and completed, time spent waiting for data, decisions made and changes accepted by an ongoing owner. Counting launches without these connections rewards starting more work and abandoning the old work.
Do not add percentage improvements across tests. They may concern different metrics, periods or the same buyers. Keep each change's calculation method, uncertainty and maintenance costs with its financial result.
Complaints and post-release failures stay in the report alongside sales. Otherwise, orders are visible while support work and emails to customers who already paid are discovered through the client chat.
Exercise: hand a change to someone else
Choose an automation you currently monitor. Prepare a handover a colleague can accept without relying on your spoken explanation.
In our example, the CRM specialist receives the instructions but only two monthly hours instead of the four budgeted. The handover is incomplete: the estimated work takes more time than allocated. The lead must free the missing hours, reduce maintenance and verify the result, or choose another owner. A shared task called "watch the emails" cannot close that gap.
If the new owner cannot stop the queue, a document bearing their name does not complete acceptance either. Handover works when the person has time, access and a tested way to intervene.
Video: building the team
The conversation with Lauren Isford helps relate team composition to its work. After watching, identify a function in your project that currently relies on someone with no time allocated to it.