PLG Features to Actually Build First in Early-Stage SaaS

Answer capsule: If you're pre-Series A, the PLG features worth building first are frictionless sign-up, a time-to-value onboarding flow, in-product activation triggers, and usage-based upgrade prompts. Virality loops and advanced analytics come later, after you've proven your activation baseline. Build sequence matters more than feature completeness. Full stop.

Look, most PLG content is written for companies like Slack and Figma. This post is not. It's for SaaS founders and product leads sitting somewhere between $0 and $2M ARR who keep reading that content and trying to apply it. And that content isn't wrong, exactly. It's just aimed at a stage you haven't reached yet. Following it too literally will cost you months of engineering time on features your users genuinely do not need right now.

Product-led growth isn't a feature set. It's a philosophy that the product itself, not a sales team, should drive acquisition, activation, retention, and expansion. But what that philosophy looks like at 200 users is completely different from what it looks like at 200,000. Early-stage teams routinely over-invest in viral referral mechanics and team collaboration hooks before solving a more basic problem: getting a single user to experience value inside the product within the first session.

And honestly? That sequencing mistake is expensive. A typical early-stage SaaS team building misaligned PLG features will spend 3 to 5 engineering weeks on shareable links and in-app NPS surveys before realizing their Day 1 activation rate is sitting at 18 percent. Fix the activation problem first. Everything downstream of it gets better on its own.

That math never works the other way around.

Start With One Number: How Fast Are You Delivering Value?

So what does time to value actually mean in practice? Time to value (TTV) is how long it takes a new user to reach the moment your product delivers on its core promise. For a tool like Loom, TTV is measured in seconds. The user records a video, someone watches it, and the value is self-evident. For a revenue intelligence platform, TTV might be four days because the product needs CRM data to generate meaningful insights.

Before you plan any other PLG feature, you need to know your TTV benchmark and whether it's acceptable for your category. Project management tools should aim for TTV under 10 minutes in the first session. Analytics platforms can tolerate 24 to 72 hours if the setup process is clearly guided. Anything longer than that without active sales support is basically a churn machine. You're just not going to keep people.

The PLG features that reduce TTV are the ones worth prioritizing first. These typically include:

• A sign-up flow that collects only what's needed to personalize the first experience, like role, use case, and team size, not a 12-field form
• An empty state that isn't actually empty, meaning a product that shows a useful demo or pre-loaded template before the user has entered any real data
• A first-run experience that leads the user to one specific action, not a tour of every feature

Notebook, a project management startup that raised a $4M seed in early 2026, cut their TTV from 22 minutes to 6 minutes by replacing their generic onboarding checklist with a role-based first-run experience. Activation rate went from 23 percent to 41 percent within 60 days. They built nothing viral. They just stopped making users figure out where to start.

Which is the whole point.

Activation Triggers Are Underbuilt. Almost Always.

Here's a question worth sitting with: do you actually know your activation event? Activation is the moment a user completes an action that predicts long-term retention. It's different from signing up. It's different from simply logging in. For Dropbox, activation was uploading one file. For Slack, it was sending 2,000 messages as a team. For most early-stage SaaS products, this magic moment hasn't been formally identified yet. Most founders couldn't tell you what it is if you asked them directly.

Finding your activation event requires data. You need to look at your retained users, the ones still active at Day 30, and identify what they did in their first session that churned users didn't do. If you don't have enough data yet, 50 to 100 users is usually enough to spot a pattern through interviews and session recordings. Not always, but often.

Once you know your activation event, build toward it deliberately. That means:

• In-product prompts that guide users toward the activation action without being intrusive
• Progress indicators that show users how close they are to getting full value
• Contextual tooltips that explain why a specific action matters, not just how to do it

The mistake most early teams make is building feature tours instead of activation paths. A feature tour shows users everything the product can do. An activation path shows users the one thing they should do right now. These are opposite approaches, and the data consistently favors the latter. I keep thinking about how often I see teams get this backwards.

Budget-wise, a solid activation flow built in-house typically costs 3 to 6 weeks of a mid-level product engineer's time, or $15,000 to $30,000 if you're working with a development partner. That's one of the highest-return investments an early SaaS product can make. If you're still defining your core product, scoping your EdTech MVP without a technical team or in any vertical, really, the same principle applies. Nail activation before adding complexity.

Freemium vs. Free Trial: One Motion, Not Both

This question comes up constantly in early-stage product conversations. My take? The honest answer is that it depends on your product's value density and your activation TTV. But there's still a right way to think through it.

Freemium works when the product delivers genuine value at zero cost, the free tier creates a natural upgrade ceiling users will hit organically, and the marginal cost of serving free users is low. Notion, Calendly, and Airtable are the obvious examples. The free tier in those products isn't a crippled product. It's a complete product with meaningful limits. That distinction matters more than people give it credit for.

Free trials work better when the full product is required to demonstrate value, setup cost is high, or the product category naturally involves a buying committee. B2B infrastructure tools, revenue operations platforms, and compliance software often fall into this camp. A 14-day trial with a credit card requirement converts better than a perpetual freemium tier for these products because urgency is built in.

Where early-stage founders go wrong is trying to run both motions at once. A free tier that's too restrictive to be useful, combined with a 14-day trial, creates a confusing funnel and splits your activation data in ways that make it hard to improve either path. Pick one. Optimize it to a strong baseline. Then consider adding the second. If you're deciding between building a fully-featured product or starting smaller, choosing between MVP and MLP for your SaaS product can clarify which motion fits your stage.

My advice? If your median TTV is under 30 minutes and your core feature can be valuable without a full team, lean freemium. If your TTV requires significant data import or multi-user setup, lean free trial. Most early-stage SaaS products should start with a free trial. Most don't.

Building the Expansion Engine: Upgrade Prompts That Actually Work

Revenue expansion inside your existing user base is where PLG pays its biggest dividends. But expansion only works if users have hit a genuine limit they want to overcome. That means your upgrade prompts need to appear at moments of actual friction, not on a timer and not based on arbitrary usage thresholds. This part gets botched constantly.

The features to build here are straightforward in concept but easy to get wrong in execution. You want:

• Usage-based triggers that prompt an upgrade when a user approaches a meaningful limit, specifically at 80 to 90 percent capacity with context, not at 50 percent and not after they've already blown past it
• Contextual feature gates that show locked features in relevant situations, with a clear value statement, not just a lock icon
• Team-based prompts that appear when a solo user takes an action that would be more valuable with a colleague involved

And honestly? The contextual feature gate deserves way more attention than it usually gets. A gate that says "Upgrade to Pro" tells the user nothing. A gate that says "Automated reporting is available on Pro plans. You spent 40 minutes building this report manually last week," tells a story. Personalized gates convert at 2 to 4 times the rate of generic ones, according to product analytics benchmarks from tools like Pendo and Amplitude in 2026.

Building smart gates requires knowing what actions predict upgrade intent. That takes time and data. But even a simple version, one that shows the right locked feature in the right workflow context, outperforms a pricing page link sitting in the navigation. By a lot. Most teams skip this.

What to Deprioritize Right Now

Viral referral loops. Built-in collaboration features for teams larger than you currently serve. Advanced analytics dashboards for users who haven't yet formed habits in the product. White-labeling options.

These are real PLG features. Real PLG companies use them. They also require an active, retained user base to generate any return on investment. Without that base, you're just burning engineering time.

Building a referral program when your Day 30 retention is below 30 percent means you're paying to acquire users into a leaky bucket. Building team collaboration features when 80 percent of your users are still solo operators is solving a problem your users don't have yet. You know how that goes.

To be fair, the sequencing principle here is pretty simple once you see it: fix retention before virality, fix activation before retention, fix sign-up friction before activation. Work backwards from the problem your data is actually telling you about, not the problem that looks impressive in a PLG case study.

An early-stage SaaS product with 40 percent Day 30 retention, a 6-minute TTV, and a clean upgrade path will outgrow a product with a viral loop and a 15 percent activation rate. Every single time. Personally, I'd take the boring fundamentals over the flashy mechanics at this stage without much hesitation.

A Realistic PLG Feature Roadmap for Getting to $1M ARR

So where does this actually leave you in terms of sequencing? Here's how we'd think about it.

Months 1 through 3: Reduce sign-up friction to under 90 seconds. Build a role-based first-run experience. Identify your activation event through user interviews and session data. That last piece takes longer than people expect. Especially in year two, when there's pressure to skip it.

Months 4 through 6: Build in-product guidance toward the activation event. Instrument activation analytics. A/B test your empty state. Establish a baseline activation rate. Not a guess. An actual number you can track.

Months 7 through 9: Build contextual upgrade gates for your top two or three locked features. Instrument upgrade prompt performance. Choose your freemium vs. free trial motion and commit to it. Stop hedging.

Months 10 through 12: Begin instrumentation for expansion triggers. Build usage-based upgrade prompts. If Day 30 retention is above 35 percent, start exploring viral or collaborative features. If it's not above 35 percent, don't.

This isn't a rigid prescription. It's a sequencing logic. The specific features you build will depend on your category, your ICP, and what your data actually shows. But the order holds across most early-stage SaaS products because the dependencies between these features are real. Activation has to exist before you can optimize expansion. Retention has to be positive before virality compounds in your favor rather than against it.

The teams that get this right aren't the ones with the most PLG features. They're the ones who built the right features in the right order and measured honestly along the way. That's it. It's not more complicated than that.