At an online coffee shop in Almaty, the unfinished-order reminder was left in the personal account of Miras, the marketer. Miras moved to another project, and buyers started getting emails after they had already paid. The owner writes in the shared chat: "Who can stop this?" The analyst has the report and the developer has the code, but the whole chat is hunting for access to the flow itself.
By this point the reminder has already been tested, and the shop decided to keep it. The numbers in this example are illustrative; the shop keeps 6,000 ₸ from a 15,000 ₸ order, as in the customer-base calculation. This story shows that a growth team delivers two things: the test's conclusion and a working process with a person responsible for it.
Build the team around the work
A growth team is a group of people who together understand the business, study customer behaviour, ship changes and evaluate the results. In a small project, one person covers several roles. But if you call the marketer head of growth while the developer and the analyst help only in their spare time, the new title changes nothing.
In his essay on building a growth team, Brian Balfour draws on a conversation with Andrew Chen to look at teams of different sizes. For the coffee shop, it is easier to start from the amount of work: who will find out why purchases were left unfinished, who will fix the website and who will connect the data to the CRM?
Before the start, the owner gives people time and authority. The team knows which copy and settings it changes itself and which questions go to the product owner or to sales. Prices, payment terms and customer data do not become a playground for experiments just because the team has "growth" in its name.
One change has several areas of responsibility
One person is responsible for getting the test all the way to a decision. They keep track of agreements, clear delays and pull the result together. That does not give them the right to declare faulty data correct or to ship a change around the agreed constraints.
The shop split the reminder work like this:
| 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 take two rows, but every row needs time and access. If there is no CRM specialist on staff, the owner appoints someone else and counts this work in their workload. Otherwise it falls to whoever notices the problem first.
Acceptance has three items: owner, monitoring and rollback. Each one needs a result you can check.
Agree who can stop a launch
The reminder has rules that touch several teams at once. A placed order cancels the send, even when a manager took the order on WhatsApp. Unsubscribes reach the sender. Support knows who handles buyers' replies to the email. And if an order status arrives late, the system must not quietly decide there was no order.
The marketer describes these cases, the developer builds them, and someone from sales places an order on their side and watches what happens. The trigger flow is accepted along its whole path, not just inside the email service's interface.
Agree in advance which problems block release. Say acceptance finds an email sent after an order was placed, or a send to someone who unsubscribed. The flow goes back for repair, and there is no need to wait for a statistical conclusion about sales: a process rule is already broken.
If the analyst and the lead disagree, it must be clear who decides and where the reasoning is written down. "We need to ship by Friday" will not bring back a lost denominator. What you can do is narrow the change, move the launch or ship only a technical check and call it exactly that.
A working week and a test window are different schedules
Once a week the team can go over decisions that are ready, current blockers, upcoming work and upkeep of what has already shipped. But an experiment does not have to fit that weekly rhythm.
Set the recruitment period, outcome window and stopping rule before launch. For example, the repeat-purchase reminder test plan depends on buyer volume and the time to a repeat order. The unfinished-order reminder has its own scenario and its own timing, so do not carry that plan over. A meeting can uncover a data error, but you cannot end recruitment just because today's chart looks good.
Tie the number of open tasks to the hours available. If the developer has twelve hours and one chosen integration eats all twelve, four more cards in "In progress" add no capacity. The lead picks the order, frees up time or cuts the scope.
A failed test can still end in a conclusion. The team writes down the question, data, limitations and decision: drop the idea, fix the measurement or prepare a new test. If there was not enough data, they say so, and the test does not move to the "success" column.
The work costs money before it produces a result
The shop values an hour of work at 5,000 ₸, as in the growth tools comparison. This is an internal estimate for the budget and has nothing to do with any profession's rate.
| 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 of upkeep after rollout, or 20,000 ₸. Preparation and the first three months of upkeep cost 150,000 + 3 × 20,000 = 210,000 ₸. At 6,000 ₸ contribution per order, that is the price of 35 additional orders. Service and sending costs are not included.
Thirty-five orders that came after the emails will not cover this calculation on their own: some buyers would have ordered without a reminder. How many orders the reminder added is for the planned comparison to show. The budget names the cost of the work and the bar for paying it back; it does not promise an effect.
Name the hours freed up for an employee in the report too. If they can go to other tasks, that is a good result. But the payroll does not shrink because automation saved a few hours.
Handover to ongoing operation needs acceptance
Once the flow is kept, Zhanel, the CRM specialist, gets access through the company's work account. Miras's personal passwords are not pasted into a chat. Settings, connection owners and instructions live where whoever covers for Zhanel during her holiday can find them.
The handover includes the audience, the trigger condition, exclusions, schedule, copy and the source of every status. Next to them sit the metric definitions, a change log and contacts for the people who fix data and code.
Zhanel runs the test herself: places an order, sees that the send was cancelled for it and finds the reason in the log. Then she stops the flow and checks what happened to messages already in the queue: the stop has to apply to them as well. An off switch without a queue check can leave some emails running.
Accepting the handover to ongoing operation
Owner access
Company working account
Check the exclusion
Place an order and see it excluded from sending
Find the reason in the log
Stopping
Stop the flow
Check messages already queued
If a feature flag was used, the team decides whether the switch is still needed. For a temporary code branch, they assign who will remove it and by when. Test contacts are excluded, temporary access is reviewed, and support is told about the change.
Gradual rollout and monitoring after release help catch operational faults. The experiment's conclusion is not mixed up with them: if someone wants to switch the reminder on for another audience, they first assess how that audience differs.
Assess the team's work
In a report on the team, look at tests started and finished, time spent waiting for data, decisions made and changes that got a permanent owner. If you count only the number of tests launched, you reward the team for opening new work and abandoning the old.
Do not add up percentage gains from different tests. They may concern different metrics, periods or the same buyers. For the financial result, each change keeps its calculation method, uncertainty and upkeep cost.
Complaints and post-release errors stay in the report next to sales. Otherwise the order growth shows on the chart, and you learn about the extra support work and emails to people who already paid from the client chat.
Exercise: hand a change to someone else
Choose an automation you are watching over yourself right now. Prepare the handover so a colleague can accept it without your spoken explanations.
0 of 6 done
Back to the shop. Zhanel received the instructions, but she was given two hours a month instead of the four in the budget. The handover is not finished: the estimated work does not fit the time allocated. The lead frees up the missing hours, cuts the upkeep and watches whether the result suffers, or appoints another owner. A shared task called "keep an eye on the emails" will not close that gap.
And if Zhanel cannot stop the queue, a document with her name on it does not complete acceptance either. The handover is done when the person has time, access and a tested way to step in.
Video: building the team
The conversation with Lauren Isford will help you match team composition to the work. After watching, note which role in your project rests on someone who has no time set aside for it.