Network effects: You may just have collaboration features

Grammarly works perfectly for one person. Slack, alone, is a notes app you talk to yourself in. Only one of those has a network effect, and most B2B software claiming one is on the Grammarly side: a product that works fine solo and also happens to support teams. That is a collaboration feature. It is a good thing to have and it is not a moat, because a competitor can ship the same thing and nothing stops your customer leaving.

A one-day test settles it, and it is worth running before you build a strategy on the answer.

The test: use your own product alone for a day

Work normally, with no teammates in the account. At the end of the day, ask what you could not do.

If the answer is “nothing much,” you do not have network effects. You have a solo tool with sharing, which is a perfectly good product and a different growth pattern, closer to embedded virality than to a moat. Stop describing it as a moat. The word quietly sets a roadmap.

If the answer is “almost everything,” you do. The product was incomplete without other people, which means every user has a reason to recruit the next one that has nothing to do with your marketing.

Adding “invite your team” to Grammarly creates no network effect, just a second person using a solo tool. Slack’s emptiness alone is not a flaw in the product, it is the mechanism. A messaging product with no recipients has nothing to do, which is why getting teammates in is not an onboarding step but the product itself.¹

What are the four types of network effects?

A network effect exists when each additional user makes the product more valuable to the users already there. Not more popular, not better funded, and not cheaper to run at scale: economies of scale lower your costs, while a network effect improves their product. Confusing the two is the most common version of this mistake. The test above is the practical form of that definition, and passing it is rarer than the pitch decks suggest.

Assuming you pass the test, the type determines how defensible you actually are, and they are not equally strong.

The categories where products routinely pass the test are narrower than the claims suggest: team messaging, collaborative design, shared documentation and project tracking where the whole team lives in the tool (Linear, ClickUp). B2B products that pass usually have the first kind, and the first kind is more local than people assume. A hundred teams using your product does not make it better for the hundred-and-first. It makes it better within each team. That distinction decides whether you have a company-level moat or a set of individually sticky accounts.

There is a design move that turns a weak direct effect into a stronger one, and Figma is the clearest example: access is open and participation is gated. Viewing spreads the artifact; commenting converts the viewer. Gating the participation rather than the access means every design review recruits, and nobody is ever blocked from seeing the thing they were sent. None of which works if the viewer has to install something first: running in the browser is what lets the people around the specialist (managers, engineers, executives) participate at all, and those people are most of the account.

The other move is to make the work persist. A whiteboard that is thrown away after the meeting leaves nothing behind; one that becomes a document the team keeps returning to turns every session into accumulated context that would have to be rebuilt somewhere else. Artifacts that outlive the interaction that created them are how a weak effect becomes a switching cost.

Protocol effects are the ones worth aiming for over time. When a file format, a document, or a workflow becomes how an organization does the thing, replacing you means replacing a process rather than a tool.

Where real network effects still lose

A genuine network effect is not a guarantee, and this is the part most treatments skip.

An adjacent network can walk into your category. If your effect is anchored to a use case rather than a unique capability, a company that already owns a neighboring network can add your use case and arrive with its network intact. Their users are already there; yours have to be persuaded to stay. This is how whiteboarding, documents and messaging keep getting absorbed by whoever already has the larger account footprint: FigJam arriving next to Figma is the pattern in one move.²

The network can be local and therefore cheap to leave. If value lives inside each workspace rather than across them, then a team switching loses only its own history, not access to everyone else. That is a switching cost, not a network moat, and it is survivable for a customer who is annoyed enough.

Density can stall while user counts rise. Ten more two-person teams is not the same as your existing teams growing from two people to ten. The first looks like growth and produces no defensibility at all.

Density, not headcount

There is no published figure for what your numbers should be, and the useful signals are all internal comparisons.

1. Is users-per-account rising over time? Not total users, users per account. Flat density with rising signups means you are acquiring solo users who happen to collaborate occasionally, and the network story is not true.
2. What share of invitations are accepted and still active a month later? Sent invitations measure enthusiasm. Accepted-and-retained measures whether the invitee found the value your user promised them.
3. Is there a usage threshold past which accounts almost never leave? Look for it instead of assuming a number: sort accounts by activity, find where retention steps up, and you have both a target for onboarding and a definition of an activated account that means something.
4. Do accounts above a certain size churn less than small ones? They should. If churn is flat across account sizes, adding people is not making the product harder to leave, which means the effect you think you have is not showing up where it would have to.

The expansion-revenue view of this, and where net revenue retention fits, is covered on the PLG metrics page, not repeated here.

Acting on the test result

1. Run the one-day test this week and write down the honest answer. Everything else on this list depends on it, and the answer is more often “no” than teams expect.
2. If it is no, stop investing in invitation flows and put the effort into the pattern that fits a solo-value product: make the product itself reach non-users, or make your users’ output travel.
3. If it is yes, count the clicks from “I should add someone” to that person contributing. Every step is invitations you are not getting.
4. Instrument users-per-account as a first-class metric, alongside signups. Total users can rise for years while density stays flat, and only the second number tells you whether the effect is real.
5. Ask a heavy-using team what they would lose if half of them left. “All our shared context” is a network effect. “Nothing we could not rebuild” is not, whatever the deck says.

A network effect is the slowest thing in this section to build and the hardest to fake, because it is a fact about your product rather than a decision you can make on a Monday. The last pattern is the opposite on both counts: it can be switched on this week, it requires nothing of the product at all, and it works entirely on people who have not used it yet. Waitlists manufacture desire, and they expire the day you satisfy it.

Updated August 2026