Which Product-Led Growth Loop Should You Build First?

Do you need a growth loop, or just a better funnel?

Most B2B software companies asking about loops need a better funnel first. A loop only compounds if the thing feeding it already works, and bolting a referral mechanic onto a product people do not finish setting up produces a loop that faithfully circulates nothing.

I get asked about this from both directions. Founders who have read about product-led growth want to know which loop to build, and founders who are struggling want to know whether a loop will fix their numbers. The second group almost always has a retention problem wearing a growth costume.

So before choosing a loop, it is worth being precise about what a loop is and what has to be true for one to run at all.

What is a growth loop, and how is it different from a funnel?

A funnel is linear. Attention goes in at the top, some fraction comes out as customers, and you refill the top from outside. A loop is circular. The output of one cycle becomes the input of the next, which means growth comes from usage rather than from spend.

The practical difference shows up in what you do when you want more growth. With a funnel you buy more attention or work more channels. With a loop you improve the conversion of one step in the cycle, and the improvement compounds because it applies to every subsequent turn.

That compounding is why loops get so much attention, and it is also why people misapply them. A loop with a weak step does not compound slowly, it stops. One broken link in a cycle is the whole cycle, whereas a funnel with a weak stage still passes some volume through.

Which loops are actually available to B2B software?

Four shapes cover almost everything. A collaboration loop, where using the product pulls in colleagues or counterparties. A content loop, where usage produces artefacts that attract new users. A data loop, where usage improves the product for everyone. And an economic loop, where revenue funds acquisition that produces more revenue.

Only two of those are genuinely product-led. The economic loop is a funnel with good unit economics, which is a fine thing to have and not what anyone means by a growth loop. The data loop is real but slow, and it usually improves retention long before it produces any new users.

The examples people reach for when arguing for loops are almost always the same handful of companies, with Slack, Figma, Notion, Dropbox, Calendly and Loom appearing in nearly every version of the argument. It is worth noticing how few B2B products share whatever property made those particular cases work. That leaves collaboration and content as the loops most B2B products can actually build. Both depend on something specific about your product, and if that thing is not true, no amount of design will manufacture it.

Which one should you build first?

Whichever one your product already does accidentally. Look for the behaviour users perform without being asked, such as inviting a colleague, exporting something, or sharing a link. That behaviour is a loop trying to form, and strengthening it is far cheaper than creating a motion from nothing.

This is the part most teams skip. They choose a loop from a framework rather than from their own usage data, and then spend a quarter engineering a behaviour their users have shown no inclination towards. The evidence you need is already in your product analytics, whether that is Amplitude, Mixpanel or something you built yourself, and usually nobody has gone looking for it.

If nothing is happening accidentally, that is information too. It usually means the product is single-player and the output is private, which rules out both of the real loops and points you back towards a funnel. That is not a failure, it is just a different growth model with different economics.

Why does the collaboration loop fail for most products?

Because inviting someone has to make the inviter's life better immediately, and in most products it does not. If bringing in a colleague only helps the company in the abstract, or worse, creates work for the person doing the inviting, the loop has a cost at exactly the step it needs to be free.

The successful versions of this share one property. The product is worse alone than together, in a way the user feels within their first session. Where that is true, invitations happen without prompting. Where it is not true, you get an invite button nobody clicks and a quarterly meeting about why.

The second failure is friction on the receiving end. An invited colleague who hits a signup wall, a plan limit, or a permissions screen before seeing anything useful will not complete the loop. If you are building this, the invited person's first sixty seconds matters more than the inviter's flow, and it is usually the part nobody designed.

What has to be true before a content loop works?

The artefact users create has to be worth seeing by someone who is not a user, and it has to carry an obvious route back to you. Both halves are required. A beautiful output nobody outside the company sees is not a loop, and a widely seen output with no attribution is a gift.

Where this works well, the output is something the user wants to share for their own reasons. A report they send a client, a page they publish, a document they hand to a colleague. The sharing is not a marketing ask, it is the job, and your product happens to be attached to the thing they were going to send anyway.

Where it fails is when the attribution is intrusive enough that users remove it. There is a real line here, and crossing it turns your loop into a reason to upgrade specifically to make you invisible. That can be a legitimate pricing lever, and if you use it that way, be honest that you are selling removal rather than building a loop.

How long before you know whether a loop is working?

Long enough that you should instrument it before you build it. A loop is measured by how many new users each existing user produces over a period, and by how long one turn of the cycle takes. Without both numbers you cannot tell a slow loop from a dead one.

Cycle time is the neglected half. A loop that produces a healthy number of new users per user is still irrelevant to this year if one turn takes eight months. Conversely a modest-looking loop with a two week cycle compounds surprisingly fast. Teams usually measure the ratio and ignore the clock.

Give it at least three full cycles before drawing conclusions, and be honest that early loop numbers are contaminated by your existing audience. The first wave of invitations comes from people who already liked you, which tells you very little about whether the mechanic works for anyone else.

When is product-led growth the wrong answer entirely?

When the buyer is not the user, when the product cannot be evaluated without configuration, and when the deal requires a procurement process regardless. In those cases a loop can still help awareness, but it will not shorten the path to revenue, and treating it as your primary motion will cost you a year.

A lot of good B2B software falls here. If the value only appears after data is connected and a workflow is designed, self-service is a poor evaluation environment, and the honest choice is a sales-assisted motion with the product as proof rather than as the whole funnel. This is the same tension as choosing between a self-serve trial and a demo request.

The mixed model is usually the right answer and the hardest to run. Self-service for small accounts, sales for large ones, and a clear rule for which is which. The failure mode is a pricing page that cannot decide, which is closely tied to how many tiers your software should have.

What should you do next?

Go and find the behaviour your users already perform without being asked. Invitations, exports, shared links, published outputs. Count them. That number, however small, is the only honest starting point for choosing a loop, and it beats any framework including this one.

Then pick the single step in that cycle with the worst conversion and fix only that. Loops are chains, so the return on improving the weakest link is disproportionate, and the return on adding a second loop while the first one leaks is close to zero.

While you are there, look at what happens immediately after someone arrives through that loop, because an invited user who gets a generic onboarding is a wasted turn of the cycle. An onboarding sequence built for trial users should treat an invited colleague differently from a cold signup. If you want a second opinion on whether your product can support a loop at all, reach out and I will tell you honestly.