Growth Isn't a Department. It's an Architecture Decision.
Most founders treat growth as a hire. They launch the product, watch retention flatline, and post a job for "Head of Growth." By then the product's bones are already wrong, and no marketer can fix what the architecture won't support.
What product-led growth actually means (and doesn't)
Product-led growth (PLG) is a go-to-market model where the product itself drives acquisition, activation, retention, and expansion, instead of a sales team. Users sign up, reach a moment of value quickly, and then pull other users in through behaviors built into the product: inviting teammates, sharing output, publishing public artifacts, or hitting a usage ceiling that nudges them to upgrade. PLG is not the same thing as freemium, and it's not the same thing as self-serve signup. Freemium is a pricing tactic. Self-serve signup is a frontend pattern. PLG is an architectural decision about where the work of growth lives. If the product does that work, you're product-led. If a human has to do it, you're sales-led, no matter what your landing page says.
Most founders don't understand this distinction until they've already built something that can't grow without humans in the loop. They add a free tier, wait, and wonder why nothing happens. The free tier didn't fail. The product was never designed to create growth loops in the first place.
If you're searching "how to make my SaaS product-led," this is where to start: not with pricing, but with what the product forces or invites users to do.
Why bolting on growth after launch never works
Growth tactics applied to a product that wasn't designed for them rarely move the needle. The loops that drive PLG (invitations, collaboration, sharing, public artifacts) have to live inside the core user flow. Retrofitting them onto a finished product means either adding features that feel bolted on, which users ignore, or rewriting the core experience, which usually costs more than starting over.
Sean Ellis and Morgan Brown make this point explicitly in Hacking Growth: growth isn't a channel, it's a property of the product itself. The teams they profile (Dropbox, Airbnb, Slack, LinkedIn) built growth mechanisms into the product before they hired growth people. Dropbox's referral program wasn't something a marketer cooked up in year three. It was baked into the signup flow from the beginning, because the team knew viral acquisition was the only way the unit economics worked.
Here's what usually happens instead. A founder ships a product designed for one user to log in, enter data, and get output. It works. Some users stick. Retention flatlines at 20%. The founder hires a head of growth at $180,000 a year. The new hire A/B tests the signup page, writes lifecycle emails, and tries to "juice the funnel." Nothing moves, because there's no structural reason for users to bring other users in. The product was built as a single-player game, and no amount of marketing makes a single-player game multiplayer.
This is the trap: by the time you feel the pain, the fix is a rebuild, not a campaign.
Three growth loops you can design on day one
The three most reliable growth loops to design into an early-stage product are onboarding, activation, and referral. Onboarding is the path from signup to first value, compressed into minutes. Activation is the moment the product becomes part of a user's routine, measured by a specific behavior that predicts retention. Referral is the structural reason one user pulls others into the product, not a tacked-on "invite a friend" button. These three, designed together, turn a product from something users try into something users depend on and spread.
Onboarding: time to first value. Define the exact moment a user first experiences the core promise of your product, then engineer the shortest possible path to that moment. For Slack, it's sending the first message in a channel and getting a reply. For Figma, it's opening a file with someone else's cursor moving on screen. Pick the equivalent for your product. Measure it in seconds or minutes, not sessions. If a user can't get there in under five minutes, the onboarding flow is the bug.
Activation: the metric that predicts retention. Find the single behavior that predicts a user will still be active in 30 days. At Facebook it was adding seven friends in ten days. At Slack it was a team sending 2,000 messages. You won't know yours on day one, but you can hypothesize it, instrument it, and iterate. Activation is the difference between a user who signed up and a user who integrated your product into their workflow. One churns. The other stays.
Referral: the reason users bring users. The strongest referral loops are native, not appended. Dropbox gives you more storage for inviting someone. Calendly forces a new invitee to meet you through a Calendly link. Typeform shows its branding on every form you send. Ask yourself: what does a user have to do inside my product that naturally exposes someone else to it? If the honest answer is "nothing," you don't have a referral loop. You have a referral button. One works. The other doesn't.
The question isn't "how do we grow?" It's "what are we building that grows itself?" Every decision about onboarding, data model, sharing, and permissions is a growth decision, whether you recognize it as one or not. The founders who figure this out early don't need a head of growth. They need a product that doesn't need one.
If you're about to start building, or you've shipped something and retention is telling you growth was never designed in, we can help. Our Retention & Scale Sprint audits your growth architecture and rebuilds the loops that matter. Email us before you post the job listing.