Where product ends and growth begins: closing the loop between features, funnels and feedback

Product and growth are one loop, not a relay race

In most small software companies I meet, growth works like a relay. Marketing runs the first leg and hands over a signup. Product runs the second leg and hands back a feature. Nobody owns the gap in the middle, which is where most people go missing.

Brian Balfour, Casey Winters, Kevin Kwok and Andrew Chen put the problem precisely in their 2018 essay on growth loops. Planning around a funnel, they wrote, treats product strategy and acquisition strategy in silos: marketing owns acquisition, product owns retention.¹

The arithmetic of loops, the gain and the multiplier, is already worked through in the growth flywheel, and the funnel itself in the pirate metrics framework. This article is about the product side of the same loop. Two questions. Which features create a loop, rather than just sitting in the product? And how does what users do decide what gets built next?

Throughout I use one invented business. Rotabird is a rota and shift planning app for independent cafés and bakeries, run from Cork by a developer called Eoin, at rotabird.example. It costs €29 a month per venue after a 14 day free trial. Nobody real, and every number is made up so I can show every step.

Worked example: Eoin's relay in numbers

In September, Eoin spends €9,000 on ads. They bring 600 trial signups, so a signup costs $\frac{€9{,}000}{600} = €15$. Of the 600 trials, 60 become paying venues, a trial to paid rate of $\frac{60}{600} = 10\%$, and a paying venue costs $\frac{€9{,}000}{60} = €150$.

The marketing report says 600 signups at €15, which looks grand. The product report says three features shipped, which also looks grand. Neither report mentions the 540 venues that tried Rotabird and left. That gap is where the rest of this article lives.

A feature creates a loop when its output reaches someone new

Most features serve the person who uses them. A few do something more: what they produce lands in front of a person who has never heard of the product. That is the moment a feature becomes a loop.

Balfour makes the general point in his essay on product channel fit: products are built to fit with channels, not the other way around, and channels do not bend to fit products.² For a product that wants to spread through its users, he lists what the product needs: a quick time to value, a broad value proposition, and ideally a network that makes the product better.²

Kevin Kwok's analysis of the design tool Figma shows what this looks like as a feature. Sharing a design is as easy as sending a link, anyone can open it in their browser, and so, as more designers use it, they pull in the non designers they work with.³ The feature is a link. The loop is everyone who opens it.

The gain of such a loop has the same three parts as any other loop. The full derivation is in the growth flywheel, so here is only the short form:

$$g = s \times i \times c$$

Here $g$ is the gain of the loop, the new customers one new customer produces per cycle. $s$ is the share of customers who use the feature in a way that reaches someone new. $i$ is the number of new people each of them reaches. $c$ is the share of those people who become customers. Each is a plain rate, events over opportunities, as in Foundations: ratios and rates.

For the product side, each letter is a design decision: whether the feature is used, how many people see its output, and what they can do next.

Worked example: the published rota

Every Rotabird venue can publish its weekly rota as a link that staff open on their phones. At the foot of each rota page sits a line: rotas by Rotabird, make one for your venue.

Of the 60 venues that became paying in September, 45 published a rota link, so $s = \frac{45}{60} = 0.75$. Each published rota is opened by eight members of staff on average, so $i = 8$. That is $45 \times 8 = 360$ staff who saw the footer. A good few of them run or supervise a second café, and over the following month 3.6 new paying venues came from that footer on average, so $c = \frac{3.6}{360} = 0.01$.

The gain is $g = 0.75 \times 8 \times 0.01 = 0.06$. Every 100 paying venues bring in six more.

Eoin then changes one thing. The footer becomes a button, "use this rota for your venue", which opens a trial with the same layout already filled in. The share who become customers doubles to $c = 0.02$, and the gain doubles to $g = 0.75 \times 8 \times 0.02 = 0.12$.

The flywheel article shows that a loop below one multiplies the paid customers by $\frac{1}{1-g}$, the sum of a shrinking series explained in Foundations: compounding. For Eoin's 60 paid venues a month, that is $\frac{60}{0.94} = 63.8$ a month before the change and $\frac{60}{0.88} = 68.2$ after. Four extra venues a month, for a button. Nothing dramatic, but it pays every month the product exists.

The best loops reach the people who decide for many

Not everyone who sees a feature's output is equally useful. A waiter who sees the rota footer decides for no one. A person who advises 40 businesses decides, or at least influences, for 40. When I look for loops in a product, I follow the output of every feature and ask who receives it, and how many others that person speaks for.

Worked example: the payroll export

Rotabird has a payroll export, a monthly file of hours worked. Eoin notices where it goes: most venues email it to their accountant, and hospitality accountants tend to look after many venues.

Of the 60 new paying venues, 30 send the export to an accountant, so $s = 0.5$. Each sends it to one accountant, so $i = 1$. Eoin adds a short line to the export file, with a link to a free accountant view that shows the hours for all of an accountant's Rotabird clients in one place. Over the following months, one accountant in five who receives an export brings one more venue, recommending Rotabird to a client still on spreadsheets, so $c = 0.2$.

The gain of this second loop is $g = 0.5 \times 1 \times 0.2 = 0.10$. One accountant reached is worth far more than eight members of staff: the staff loop needs 360 people to produce what the accountant loop gets from 30.

Because the two loops reach different people, their gains add, to about $0.12 + 0.10 = 0.22$ for the same 60 venues. That is a rough sum, since a venue found by both loops counts once. A feature that already lands on an accountant's desk is the least expensive loop Eoin will ever build.

Not every feature should be a loop

This idea goes wrong when every feature gets a share button, every screen a "tell a friend", and the product starts to feel like a leaflet. Balfour's own list explains why this rarely works: the channel needs a quick time to value and a broad value proposition, and a share button adds neither.²

Most features should do one quiet job: make the product worth keeping. A feature that keeps a venue for another year earns its place without ever reaching anyone new. The question for each feature is simple. Does its output naturally reach someone new, as a rota reaches staff and an export reaches an accountant? Then design for the loop. If not, design for the person using it, and leave the share button out.

An example: Eoin's holiday allowance tracker shows each member of staff how many days they have left. Its output stays inside the venue. So Eoin judges the tracker by one number only, whether venues that use it stay longer, and leaves the growth job to the rota and the export.

Activation is the moment the loop can start

A loop only turns for customers who reach the point where the product does its job. Before that point, nothing is produced, so nothing reaches anyone. That point is called activation: the first time a new user gets the value the product promises. For Rotabird it is a published rota, because only then do staff see it and only then does the footer do anything.

Activation has to be defined in advance, as one countable event. Eoin's definition: a venue has published a rota with at least three members of staff on it within three days of signing up. The activation rate is then a plain rate, as in Foundations: ratios and rates:

$$a = \frac{n_{\text{activated}}}{n_{\text{trials}}}$$

Here $a$ is the activation rate, $n_{\text{activated}}$ is the number of trials that reached the activation event in the time allowed, and $n_{\text{trials}}$ is the number of trials that started in the same period.

Worked example: where September's 600 trials went

Eoin follows the 600 September trials through the steps to a published rota:

• 600 started a trial.
• 390 added at least three members of staff.
• 270 built a first rota.
• 150 published it within three days. These are the activated venues.
• 60 became paying venues.

The activation rate is $a = \frac{150}{600} = 25\%$. Three quarters of the trials never reached the point where Rotabird does anything.

Across the bottom are the steps of the trial in order. Up the side is the number of venues that reached each step. The biggest single drop is the first one, 210 venues lost between starting a trial and adding their staff. The takeaway: the most valuable product work is usually at the first step that loses people, not at the last screen before payment.

Silent churn is the customer who never leaves on paper

Not all churn shows up as a cancellation. On a trial, most people who leave never press anything. They signed up, looked around, did not reach the moment of value and simply stopped coming back. I call this silent churn. It never appears in a cancellations report, because nothing was cancelled.

In September, Eoin had 450 trials that never activated, and not one told him why. A dashboard of signups and cancellations would show a healthy product.

The signals are usually visible in the product's own events, if anyone looks:

Signal	What it suggests	What I try first
Setup started but not finished	Lost before any value	Make the first success smaller
One session only	Nothing pulled them back	Give them a reason to return tomorrow
Key feature never opened	Its value is unclear	Put it where they already are
Trial ends with no action	A passive trial	One helpful message mid trial

All of these come from simple, consented product events: a step completed, a screen opened. I do not use session recordings or heatmaps for this. A question that cannot be answered by a counted event or by asking a person does not need a recording of their screen.

An example: of Eoin's 210 trials lost at the first step, 160 had opened the staff screen and left without adding anyone. That is not a mystery. Typing eight names, phone numbers and contract hours into a form is a chore. The next section shows how Eoin finds out whether that is really the reason.

Trial to paid: compare activated venues with the rest

The old instinct is to fight for conversion at the payment screen. In my experience the decision was made days earlier, at activation. You can see it in Eoin's numbers by splitting the trials in two and asking a conditional question: of those who activated, what share paid, and of those who did not, what share paid? The rule behind it is conditional probability, explained in Foundations: probability:

$$P(\text{paid} \mid \text{activated}) = \frac{P(\text{paid} \cap \text{activated})}{P(\text{activated})}$$

Here $P(\text{paid} \mid \text{activated})$ is the probability that a trial pays, given that it activated. $P(\text{paid} \cap \text{activated})$ is the probability that a trial both activated and paid, and $P(\text{activated})$ is the probability that a trial activated, which is the activation rate $a$ from above.

Worked example: two very different trials

Of the 60 paying venues, 51 had activated and nine had not. So:

$$P(\text{paid} \mid \text{activated}) = \frac{51 / 600}{150 / 600} = \frac{51}{150} = 34\%$$

Here $51 / 600$ is $P(\text{paid} \cap \text{activated})$, the share of all trials that both activated and paid, and $150 / 600$ is $P(\text{activated})$, the activation rate. The same rule for the 450 trials that never published a rota gives $P(\text{paid} \mid \text{not activated}) = \frac{9}{450} = 2\%$. Both follow Foundations: probability. A venue that activated was 17 times as likely to pay.

Now the honest caution. This does not prove that activation causes payment. A café owner who is already keen will both publish a rota and pay, and would have paid anyway. Correlation is not causation, as Foundations: correlation explains. The split tells Eoin where to look. Only a test, later in this article, tells him whether pushing more venues to activate actually produces more paying ones.

Shared definitions, so everyone counts the same thing

The relay from the first section survives on vague words. Marketing says "lead", product says "active user", and the two numbers never meet. The fix is dull and it works: write down a short list of definitions, agree them once, and make every report use them.

These are the three I start with, written for Rotabird:

Term	Eoin's definition
Activated venue	Published a rota with at least three staff within three days
Product qualified lead (PQL)	Activated, and has published a second weekly rota
Upgrade ready	Two or more sites added, or the multi site pricing page viewed

A product qualified lead (PQL) is simply a trial whose behaviour in the product says it is likely to buy, as opposed to a lead who only filled in a form.

Worked example: the bargain campaign that cost more

In October, Eoin runs two campaigns, €3,000 each. Campaign A, a broad social ad, brings 300 trials at €10 each. Campaign B, a search ad on "staff rota for cafés", brings 120 trials at €25 each. Judged by cost per signup, A wins easily.

Judged by the shared definition, it does not. Of A's 300 trials, 15% activate, 45 venues, at $\frac{€3{,}000}{45} = €66.67$ per activated venue. Of B's 120 trials, 45% activate, 54 venues, at $\frac{€3{,}000}{54} = €55.56$ per activated venue. B is the less expensive campaign once everyone counts the thing that matters, and since activated venues are the ones that pay and the ones that publish rotas, B also feeds the loop more.

Feedback decides what to build, because most ideas fail

So far the loop has run from product to growth: features that spread, activation that starts the spreading. The other half runs back: what users do and say deciding what gets built. This half matters because teams are poor judges of their own ideas.

The best evidence I know comes from people who could measure it. In a peer reviewed paper from 2013, Ron Kohavi and colleagues at Microsoft report that only one third of the ideas tested at Microsoft improved the metric or metrics they were designed to improve, and that success is even harder to find in well optimised products such as their search engine, Bing.⁴ The same paper recommends an ideas funnel: many ideas at the top, narrowed by low cost methods such as pitching and reviewing mock ups, with full controlled experiments kept for the few that survive, because building each idea well enough to test is expensive.⁴

A rate of one in three turns every feature into a bet, and a bet has an expected value, as in Foundations: expected value:

$$E[X] = \sum_i p_i\, x_i$$

Here $E[X]$ is the expected value of the bet, $p_i$ is the probability of outcome $i$, and $x_i$ is what outcome $i$ is worth. The sum runs over every possible outcome.

Worked example: the shift swap feature

Eoin wants to build shift swapping: staff swap shifts in the app, and the manager approves with one tap. It would take six weeks of his time, which he values at €1,000 a week, so €6,000. If it works, he estimates it is worth €12,000 in the next year, from venues that activate and stay. If it does not, it is worth nothing.

Eoin has no hit rate of his own yet, so he borrows Microsoft's one in three as a starting point. That is a borrowed base rate, not a law, and he should replace it with his own as soon as he has counted a few features.

$$E[X] = \tfrac{1}{3} \times €12{,}000 + \tfrac{2}{3} \times €0 = €4{,}000$$

Here $\tfrac{1}{3}$ and $\tfrac{2}{3}$ are the probabilities $p_i$ of success and failure, and €12,000 and €0 are the values $x_i$ of each, exactly as in Foundations: expected value. An expected €4,000 against a certain €6,000 of build time is an expected loss of €2,000.

So Eoin makes the bet smaller instead of hoping for better odds. For one week, €1,000 of his time, he adds a button that says "ask to swap this shift", which sends him the request, and he does the swap by hand. If venues use it, he builds the real thing. The expected cost is now $€1{,}000 + \tfrac{1}{3} \times €6{,}000 = €3{,}000$, against the same expected €4,000, a gain of about €1,000. The idea is the same. The way of finding out costs less.

Ask the leavers, and let their answers rank the backlog

Events tell you where people stopped. They do not tell you why. For the why, the least expensive instrument in software is a question, asked at the right moment, to the people who left.

Eoin adds one optional question to the trial expiry email and to the cancel screen: what stopped you? It is a single choice with a free text box.

An example: in October 40 leavers answer. 17 say setup took too long. Nine say their staff would not use another app. Six say the price. Five say a missing holiday tracker. Three give other reasons. Together with the 160 trials that abandoned the staff screen, the first answer points at the same place twice. Eoin's backlog had shift swapping at the top. The leavers put staff import at the top instead: paste a list from a spreadsheet, and the staff screen fills itself in. That moves up. Shift swapping, already shrunk to its one week version, waits.

Test the change before you believe it

Eoin builds staff import in a week. Now he needs to know whether it works, and the honest way is a controlled test: half the new trials get the import, half do not, chosen at random, and the activation rates are compared. The detailed method is in statistical testing, sample size and lift. The question for a small product is first whether the test can be run at all.

The number of trials needed in each half depends on how big a change you want to be able to see, as in Foundations: sample size:

$$n = \frac{(z_{\alpha/2} + z_{\beta})^2 \left[p_1(1-p_1) + p_2(1-p_2)\right]}{(p_1 - p_2)^2}$$

Here $n$ is the number of trials needed in each half, $z_{\alpha/2}$ is 1.96 for 5% significance, $z_{\beta}$ is 0.84 for 80% power, $p_1$ is the activation rate without the change and $p_2$ is the activation rate you want to be able to detect with it.

Worked example: can Eoin even test this?

To detect a rise in activation from 25% to 35%:

$$n = \frac{(1.96 + 0.84)^2 \left[0.25 \times 0.75 + 0.35 \times 0.65\right]}{(0.35 - 0.25)^2} = \frac{7.84 \times 0.415}{0.01} = 325.4$$

Here $1.96$ and $0.84$ are $z_{\alpha/2}$ and $z_{\beta}$, $0.25$ is $p_1$, the activation rate today, $0.35$ is $p_2$, the rate he wants to detect, and $325.4$ is $n$, the trials needed in each half, as in Foundations: sample size.

That is 326 trials in each half, 652 in all, a little over a month at 600 trials a month. Possible.

To detect a rise from 25% to 28%, the same formula gives about 3,390 trials in each half, 6,780 in all, more than 11 months of trials. Not possible, not for a change he wants to decide on this quarter.

This is the quiet rule for small products: test big changes, not small ones. A product with 600 trials a month cannot learn anything from a new button colour, but it can learn a great deal from removing a whole step of setup. How much data each kind of question needs is worked through in how much data do you actually need.

After five weeks, 82 of the 326 trials without import activated, 25.2%, and 117 of the 326 with import, 35.9%. The two proportion test from Foundations: hypothesis tests uses the pooled rate $\frac{82 + 117}{652} = 30.5\%$, a standard error of $\sqrt{0.305 \times 0.695 \times \left(\frac{1}{326} + \frac{1}{326}\right)} = 0.036$, and a difference of $0.359 - 0.252 = 0.107$, so $z = \frac{0.107}{0.036} = 2.98$, with a two sided p value of about 0.003. The import stays, for everyone.

And because activation is what starts the rota loop, the feature that won on activation also raises $s$ in the gain of the loop. That is the whole article in one change: feedback chose the feature, the test confirmed it, and the loop turns a little faster.

What a shop borrows from this

The same logic runs in eCommerce, where the product is the parcel, the page and the account. Which part of what a shop produces reaches someone new?

A gift message is the clearest case. It is a checkout feature, and its output lands in the hands of someone who did not choose the shop.

An example: a gift shop in Galway ships 2,000 orders a month, and 600 of them carry a gift message. The recipient's card has a line, "exchange this, or choose your own", with a link. If 5% of recipients follow it and one in four of those places an order, that is $600 \times 0.05 \times 0.25 = 7.5$ new customers a month, from a feature the shop already had. Referral cards, reviews and the Irish rules around them are covered in the growth flywheel, and repeat purchase in loyalty, the three Rs and earn and burn.

The weekly rhythm that closes the loop

Tools do not close the loop. A habit does: a short weekly meeting with fixed questions, so that the decision is about the answer and not about who argues best.

Read from the top: the week starts with counting, using the shared definitions, then listening to the leavers, then the tests. The one decision in the middle is the one people skip. A test that has not reached the sample size it was planned for is not finished, however good it looks on a Tuesday.

An example: Eoin's review takes 30 minutes on a Monday. This week it says: 148 trials, 49 activated (33%), import holding steady. Five leavers, three of them about price for venues with more than one site. No test is due. The decision is to sketch a two site price and show it to five of the venues that said so, before building anything.

The line between product and growth was never a handover. It is a loop, and it runs both ways. Features that put their output in front of someone new carry the product outward. What users do and say carries the decisions back in. Count both, test the big changes, and keep the bets small. The loop will not make anyone famous. It will make each week a little less guesswork than the last.

Footnotes

1. Brian Balfour, Casey Winters, Kevin Kwok and Andrew Chen, Growth loops are the new funnels, Reforge, 31 July 2018, https://www.reforge.com/blog/growth-loops

2. Brian Balfour, Product channel fit will make or break your growth strategy, brianbalfour.com, 12 July 2017, https://brianbalfour.com/essays/product-channel-fit-for-growth

3. Kevin Kwok, Why Figma wins, kwokchain.com, 19 June 2020, https://kwokchain.com/2020/06/19/why-figma-wins/

4. Ron Kohavi, Alex Deng, Brian Frasca, Toby Walker, Ya Xu and Nils Pohlmann, Online controlled experiments at large scale, Proceedings of the 19th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD 2013), pages 1168 to 1176, https://exp-platform.com/Documents/2013%20controlledExperimentsAtScale.pdf