Growth.

The framework

1. 01

   Which side of your network does the hard work?

   Chen's term for it is the hard side: in almost every network a small group carries disproportionate load — the drivers, the sellers, the hosts, the people who post rather than read — and they're harder to recruit, quicker to leave, and doing something that costs them real time. Build the launch for them first, because the easy side follows supply and supply doesn't follow demand. Then count them on their own for the rest of the launch. One number matters more than your user total: how many of the hard side were active inside the cluster this week against last week. That is the failure you get almost no warning of, because the easy side keeps signing up for a fortnight after the supply has quietly gone.

2. 02

   Carry the group across from Day 69, then put it under a harder test.

   You have already named it: the smallest group inside which the product works with nobody else present. Lift that line straight off your network effect audit rather than redrawing the room this morning — today's work is checking it, not choosing it. The test is blunter than the one that produced it. If nobody else on earth joined this month, would these people still get real value from each other through your product? An answer that needs a caveat means the group is still too big, and one more cut costs you nothing today and a relaunch later. Then stop sizing it altogether. Density is a ratio, and forty people who transact with each other weekly are a network where four thousand scattered sign-ups are a list.

3. 03

   The first network is a template, not a triumph.

   One working atomic network proves the product; it doesn't prove the business. What you're looking for next is whether the thing can be rebuilt somewhere else with a repeatable set of moves. Write the playbook while the first one is still fresh, and make it specific enough to hand to somebody who wasn't there: who you approached and in what order, what you offered the hard side to go first, what you did by hand, how many weeks it took to stand on its own, what it cost, and the signal that told you it had. Then run that page deliberately on a second cluster and read the only two numbers that settle it — cost per cluster, and weeks to self-sustaining. If the second cluster is no cheaper and no faster than the first, you don't have a method yet.

4. 04

   Seeding costs that look like waste, and mostly aren't.

   Getting a first network to stand up usually takes things that don't scale and shouldn't — guaranteed earnings for early suppliers, matching people by hand, paying for the content that fills the empty room, turning up in person. These are launch costs, not operating costs, and confusing the two does damage in both directions: teams either refuse to spend at all, or keep subsidising a cluster that's had every chance and still can't hold itself up. So price a launch like a launch. Fix the amount and the end date before the first dollar leaves, write down what self-sustaining means as a specific behaviour at a specific rate without you, and name the date you check it. A subsidy with no stop date stops being seeding and becomes the business model — which is how a network with impressive activity turns out to have been buying every transaction inside it.