Product Led Growth: What It Actually Requires (Not What the Blog Posts Say)

Additionally, interested customer fills out a contact form. We schedule a demo. We close or we do not. Repeat.

In fact, this works until it does not. It works until the founder’s time becomes the bottleneck. It works until you want to grow faster than your calendar allows.

Additionally, here is what I learned building the infrastructure to make that work.

Product Led Growth Is Not a Strategy

In fact, “Product led growth” has become a category of marketing content. The idea: build something so good that it sells itself.

This is true but useless. Every founder wants to build something that sells itself. The question is what that actually requires.

Also, after building it: product led growth is a system, not a product decision. It requires specific infrastructure across pricing, onboarding, billing, and support that most early-stage SaaS companies do not have.

What You Actually Need

Self-Service Billing

Obvious in hindsight, surprisingly hard in practice.

Furthermore, before PLG: customers sign contracts, pay invoices, and have a sales rep manage their subscription.

Moreover, for PLG: you need Stripe Pricing Tables, checkout flows, subscription management portals, webhooks for payment events, trial enforcement, upgrade and downgrade flows, cancellation flows, and lifecycle email sequences that trigger based on billing events.

In addition, we built most of this in a single large PR (#2972), which took six weeks from start to merge. It touched 137 files and added 4,433 lines of code.

That is a significant infrastructure investment before the first self-service customer.

A Trial That Proves Value

However, self-service only works if the product delivers value during the trial without human intervention.

This required rewriting our onboarding flow. The previous version assumed someone would walk new users through the product. The new version assumes no one is available and the product must explain itself.

Onboarding is the hardest UX problem in self-service. You are trying to teach the product’s core workflow in the first 5 minutes to someone who has never seen it before.

Free Email Domain Filtering

Small detail, large impact.

Without this, anyone with a Gmail address can create a trial. You end up with a database full of personal accounts that will never convert to paid, noise in your analytics, and if you have a generous trial, abuse of that generosity.

We block 4,779 free and disposable email domains. It took two hours to build. It will improve the quality of every trial signup going forward.

Usage Limits With Billing Consequences

This is where PLG gets technically complex.

On a free trial, sessions should be limited. On a paid plan, sessions above the limit should trigger usage-based billing. The code that enforces these limits needs to be correct in production because errors have direct revenue consequences.

We built this in PR #3045: trial session counting, overage tracking, usage indicators in the UI, and the email sequences that fire when users approach their limit.

Email Sequences That Actually Work

Sales-led: the sales rep follows up personally.

Product-led: the email sequence follows up automatically.

The emails that matter:
– Trial started: explain the product, show the first action
– Day 3: remind them of core value, show what they have not tried
– Day 7: midpoint check-in
– Day 12: trial ending soon
– Day 14: trial ended, upgrade prompt
– Usage threshold: 80% and 100% of session limit

Each of these needs copy that does not sound automated. That is harder than it sounds.

Support That Does Not Require You

Sales-led support: you answer every question personally.

PLG support: you need documentation comprehensive enough that most questions are self-answerable.

We are still working on this. The help center articles exist. Whether they are good enough to replace a 30-minute onboarding call is something we will learn over the next quarter.

What PLG Does Not Fix

PLG does not fix a product that does not deliver value in the trial window.

If someone signs up, spends 20 minutes confused, and leaves without ever running a successful session, the problem is not the billing infrastructure. The problem is the onboarding experience or the product itself.

PLG does not fix a market that does not understand the product category.

If your potential customers do not know they have the problem you solve, or do not know that software exists that solves it, PLG does not help. Someone still has to educate the market. That education does not happen in a trial.

PLG does not fix pricing that is wrong.

If the price is too high relative to perceived value, the conversion rate will be low regardless of how smooth the signup flow is.

The Honest Version of the PLG Promise

PLG removes the founder from the sales process. It does not remove the sales process.

What you are building is a sales process that runs at scale without a human. It requires the same elements as a human sales process: awareness, education, trial, conversion, onboarding, and retention. It just runs automatically.

The advantage of PLG over sales-led is not that you stop doing sales. It is that you can run 1,000 trials simultaneously instead of 10.

Six Months In

We launched self-service in April. The feature flag is on (or will be soon). Our goal for Q2 is 20 paying customers through self-service.

We built the infrastructure. The product has a free trial. Additionally, the billing flows work. The emails are set up.

Now we find out if the trial experience is good enough to convert.

That is the honest version of product led growth. Not “the product sells itself.” More like: “we built a system that gives the product the chance to sell itself.”

For additional context, see recent analysis from Harvard Business Review on trends in this space.