The owner of an online coffee store wants a customer account area with a "Repeat order" button. Some regular customers reorder through WhatsApp: a manager finds the previous order, confirms the grind and address, and sends the amount due. A button seems likely to remove that work and add sales. The developer asks for a specification, but the marketer still does not know why customers message the manager: is ordering difficult, or do they want to ask about different beans?
Use the store from the retention architecture lesson: an order is 15,000 ₸, with a contribution of 6,000 ₸ after goods and delivery. The store and pilot figures below are made up. The account-area decision depends on how much of the conversation can be removed while preserving what the customer came for.
What a growth team does
Growth hacking means working on growth through hypotheses and tests across marketing, product and analytics. The marketer sees where buyers come from and what they were promised. The product team owns checkout, and the analyst connects actions to payments. If customers ask about coffee flavour, someone who understands the beans needs to join the conversation too.
Every test has a decision at the end. For the account area, that might be to build it, change the idea or drop it. The number of tests launched shows how busy the team is; their value depends on the decisions the team made and the evidence behind them.
The image shows a person studying a small mockup before a larger project. In our case, they are finding out what buyers need from a repeat order before commissioning the account area.
Break the idea into assumptions
"Make reordering a single click" contains several questions. Has the customer run out of coffee? Do they want the same beans? Were they happy with the previous order and delivery? What stops them ordering now? Each answer leads to different work.
If a customer wants a new flavour, an account area that copies the last order will solve only part of the problem. If delivery was late, that needs attention first. If the product and address are unchanged and the manager is simply copying fields between records, automation looks more useful. The repeat-order count alone cannot distinguish these causes.
The marketer reviews repeat-order conversations and notes what customers asked about. They then ask people about their last purchase: when they decided to order, where they found the store, why they sent a message and what they needed to clarify. "Would you like a convenient account area?" invites approval of the idea; an account of the last order reveals the actions the account area would need to replace.
Start with assumptions that would make development pointless if they were wrong. Before discussing the button colour, establish whether buyers need to repeat the same order and can get it without talking to a manager.
Match the test to the question
| Team's question | What to do | How to use the result |
|---|---|---|
| Why do buyers message the store before their second order? | Review conversations and ask about recent purchases | Choose which part of ordering to simplify |
| Can buyers find their previous order in the account area? | Set a task on a mockup and observe without prompting | Fix navigation before development |
| Can the store fulfil a simplified order? | Run a limited manual pilot, logging costs and errors | Decide which operations to automate |
| Does the new checkout add paid orders? | Plan a comparison with the usual checkout | Estimate the effect on purchases and costs |
A mockup works for navigation: people show where they would click and what they understood. Testing payment requires a working path through payment. A manual pilot reveals customer requests and workload, but part of its result may depend on the manager's attention. That attention will disappear during automation, so its role matters.
A reproducible payment failure may not need a separate growth experiment. If an error blocks payment, fix it and accept the work against the payment scenario. When changing an offer or customer journey to increase purchases, define the comparison and decision rules in advance.
A manual repeat-order pilot
In the pilot, the manager offers repeat-order help to 40 suitable buyers who have agreed to receive messages. They show the previous order, ask what needs changing and place it through the usual process. Eight buyers pay. The entire pilot takes four hours, including conversations with the others.
8 / 40 = 20% of invitees placed an order. That is useful for describing the pilot. To find out how many orders the help added, you also need to know how many comparable buyers would have ordered without it. Some of the eight may have intended to message the store that day anyway.
For each conversation, the manager records the step required: repeat everything, change the grind, choose different beans or clarify delivery. Nonresponders stay in the list of invitees. Counting only people who joined the conversation selects a more interested audience and hides the cost of contacting everyone else.
After the pilot, the team decides what to put into the product. If buyers keep changing beans, offering a choice before confirmation may be more useful than copying the order exactly. If address checks take most of the time, the task has a different scope. These observations go into the development brief, instead of a promise that "the account area will add 20%".
What the manager's help costs
Eight orders brought in 8 × 15,000 = 120,000 ₸ in revenue. After goods and delivery, 8 × 6,000 = 48,000 ₸ remained. For labour, assume an internal estimate of 5,000 ₸ per hour: four hours cost 20,000 ₸. The amount left after these costs is 28,000 ₸.
The hourly estimate makes manual work visible. Even if the manager receives a fixed salary, those four hours are spent on the pilot rather than other tasks. Hiring or overtime decisions would require the actual cost of working time.
The 28,000 ₸ describes the eight orders after the listed costs. The pilot's incremental contribution is still unknown. If all eight orders would have happened anyway, the help would add only 20,000 ₸ in costs. If it added some orders, compare their contribution with that amount and with future development costs.
That gives the next test a question: will the extra orders cover the service cost? At 6,000 ₸ contribution per order, four extra orders would cover the 20,000 ₸ of manual work: 24,000 - 20,000 = 4,000 ₸. This is a threshold calculation for our pilot; a real plan would also include refunds, support and the cost of the change.
Move from a pilot to an effect estimate
To measure purchases, choose one audience and one change. Assign eligible buyers to groups before showing the offer, preserve that assignment and measure all assigned buyers. The plan includes a primary metric, schedule, group sizes and reasons to stop for harm or data errors. Use HADI to write the full card.
A reminder and a simpler checkout are different changes for the store. The reminder test asks whether a message helps buyers return at the right time. An account area would test whether it helps them place the order they have chosen. The results can inform each other, but a negative or inconclusive reminder result leaves the checkout question open.
A weekly meeting is a useful place to discuss what the team learned, where data broke and which decision is waiting. The experiment plan sets the measurement end date. The store counts a second order within 60 days, so a weekly meeting cannot shorten that window. Brian Balfour's article discusses the relationship between process, team and tactics.
Exercise: a decision before development
Choose one idea for a product or store. Write down the pending decision, three assumptions and a test for the most expensive assumption to get wrong. Add what you would do for each result and which costs you would include. For the account area, the deliverable might be a mockup and a list of actions it should replace.
Now a calculation: suppose a separate, completed evaluation estimates that the help adds three orders for the same amount of work. Can the manual service be justified by the 28,000 ₸ left in the pilot?
Three extra orders contribute 3 × 6,000 = 18,000 ₸. Four hours cost 20,000 ₸, so the estimated effect after labour is minus 2,000 ₸, before development. The 28,000 ₸ applied to all eight orders. The team needs to reduce the cost of the help, find a more useful change or drop this version of the service; the precision of the effect estimate remains part of that decision too.
Video: an introduction to the approach
A talk by Alexander Onikienko. For your chosen tactic, write down which assumption about your buyers it needs to test.