Table of Contents
Why operationalizaing “Land and Expand” Expansion Revenue can be challenging?
Expansion revenue in PLG sounds simple: users love the product, invite teammates, accounts grow, revenue follows.
In reality, it’s operationally complex because of the internal and political workflows. Without a system, you get siloed revenue, sales reps unhappy, and a chaotic revenue op.
The 3 Problems This Playbook Fixes:
Channel conflict - Sales hates self-serve "stealing" their deals
Ownership gaps - Product owns PLG, Sales owns enterprise, nobody owns expansion
Broken signals - PQAs go to sales with zero context or playbook
First, channel conflict. Sales reps are unhappy with self-serve upgrades because they feel like the product is stealing their commission. The Product PLG team avoids in-app expansion prompts because they are supposed to send those deals to Sales. Nobody pushes expansion hard.
Second, ownership gaps. Product owns the PLG motion. Sales owns enterprise deals. RevOps counts the revenue. But nobody owns expansion as a shared outcome. So when expansion underperforms, theres blames, and no one is sure who should take the helm.
Third, incomplete signals with poor follow-through. You detect that a user is a high-intent expansion prospect (they invited teammates, usage spiked). But that signal goes to a rep with zero context and no playbook. The rep sends a generic "checking in" email. It gets ignored. The expansion moment dies.
1. How Do You Operationalize "Self-Serve" vs. "Sales-Assist"?
Without being explicit, the org treats expansion as binary. Either it's fully self-serve or fully sales-led. Who does it go to?
The answer is a "Traffic Light" Rubric, a simple decision tree that routes Product Qualified Accounts (PQAs) based on user signals.
🟢 Green (Self-Serve):
Signal: Solo user, low complexity (<2 docs/week), generic domain (gmail.com).
Action: Automated email nurture + in-app "Upgrade" nudges.
Why: Low-intent users need friction removed, and don’t need human touch. Your product does the selling.
🟡 Yellow (Sales-Assist):
Signal: User invites 1-2 teammates, hits specific feature gates (ex: "Shared Folder," "Team Memory").
Action: Lightweight human outreach. "Saw you invited X. Want help setting up our team workspace?"
Why: These are hand-raisers showing team intent. A 5-min check-in + context often closes the upgrade.
🔴 Red (Enterprise):
Signal: Enterprise domain, high volume (>50 docs), API usage, or security requests.
Action: Account Executive takeover. White Glove onboarding, custom MSA, dedicated resources.
Why: These are whale accounts. Speed and trust matter more than efficiency.
Having these upfront rules of engagement resolves internal disputes. Stop sending weak signals to sales (alert fatigue), and you stop underselling high-intent users with automation.
How to Solve Channel Conflict for a Sales rep?
Most reps resent self-serve upgrades because they feel the product "stole" their deal. Fix this by setting clear Rules of Engagement: Self-serve owns expansion up to 5 seats; Sales owns 5+. Crucially, compensate reps on expansion revenue regardless of channel. If a rep owns the account, they get paid even if the user clicks "Upgrade" themselves. Now, reps cheer for self-serve because it’s serving them highly qualified leads on a “silver platter.”
Learn more about how to setup 🟢 Green (Self-Serve) low touch automation and the data architecture:
Expansion sales happen inside the product. The products winning the expansion are making it frictionless and natural for users to invite teammates.
The "Empty State" Nudge
Don't just show an empty "Shared Folder" or "Team Workspace." Use that real estate:
"Collaborate faster. Invite your team to access all projects in one place. Invite Teammate"
The user wants to collaborate, and you are just removing friction.
This is how Miro, Figma, and Notion drive adoption.
They weaponize the "setup" phase.
Notion templates often start as empty "Team Wikis" that need to be filled by colleagues, making the invite feel like content creation, not admin work.
Miro prompts new users to "Say Hi" with a reaction, triggering notifications to others that pull them back in.
Figma embeds design files directly into project pages (like Notion docs), so inviting a PM isn't just "giving access", it's showing the work.
These invites are framed as "unblocking" the user, not "selling" a seat.
Notion: Adding users to collaborate like Google Docs
The "External" Trojan Horse
Allow users to invite external collaborators for free or limited access.
Here's the growth loop: External user experiences value → loves it → buys it for their org → invites their partners. This is the DocuSign/Dropbox/Clio playbook. For example, legal tech, General Counsel invites an outside counsel firm, which then invites their other clients. One seat expands into a network.
The trick: Remove the friction of "ownership" or "roles." Let them invite freely. Gate the capabilities later.
Then you have all of these folks… a network of users that you can take advantage of and build a platform around.
Create profiles for them on your platform, which they can later claim to get full access.
Frictionless "Guest" Roles
The winning pattern: unlimited guests on lower tiers, but gate advanced capabilities (editing, admin controls, or cap active guests at 5).
Result: Broad adoption, low friction, and a natural upgrade trigger ("You've hit 5 active guests. Upgrade to expand.", “John was added as a guest. Upgrade as an active guest.”).
3. How Should You Price for Seat Expansion?
Most SaaS founders treat seat pricing like it's simple math: $X per user.
But pricing psychology shows that's leaving money on the table, and worse, creating friction in expansion.
Anchor & Pack Pricing
Anchor value on your solo/individual plan. Then use "pack pricing" for teams:
"Add 5 seats for the price of 4." or "First 3 team members included; $X per additional."
Why does this work? Reduces decision fatigue. The buyer feels like they're getting a deal. And from your math, you've actually improved margins because the "per-seat" cost drops while adoption goes up.
Role-Based Pricing
Don't charge for every login. Charge for value-creation.
Structure:
Admins/Editors: Full price. These are power users.
Viewers/Guests: Free or 70% discount. These are lurkers and stakeholders.
Why? Incentivizes broad adoption (viewers build lock-in) while you monetize power users. And for many highly compliance regulated industry specifically, this maps to risk: Admins care about governance and controls; viewers just need read-only access.
The battlecard: "Your team can have unlimited viewers at no cost. Editors and Admins are where the value sits."
Miro adding teammates
Figma’s role-based pricing
Figma Seat Requests
Read more about how to make advanced features and paywalls discoverable:
4. When Should You "Gate" Features for Expansion?
Founders often gate collaboration features (like "invite a teammate"). This is backward. You want collaboration to be free because it drives virality. If you block the invite, you block the growth loop.
Instead, gate the Admin & Governance features.
Why Gate Admin Features?
The Motivation: End users (lawyers, designers) just want to get work done. They don't care about SSO, Audit Logs, or User Roles. They won't pay for them.
The Buyer: The Buyer (General Counsel, IT Director, VP Ops) cares deeply about these things. They are motivated by risk, control, and compliance.
The Strategy: Let the end users run wild (ungated collaboration) to build groundswell. When the account hits critical mass (e.g., 10 users), the "Shadow IT" alarm bells ring for the Buyer. That is when you sell the Admin Tier.
What to Gate (The "Enterprise Guardrails"):
SSO/SAML: "Secure your team's access."
Audit Logs: "See who viewed what contract."
Data Retention Policies: "Auto-delete after 90 days."
Centralized User Management: "Provision/deprovision users instantly."
Kyle Poyar's Principle: Focus your monetization on the "Admin Tier." End users aren't your buyer for enterprise deals; the person fearing a security breach is. Ungate the usage; gate the safety. Learn more about PLG Pricing 201.
5. How Do You Send Product Qualified Account data and playbook to the Sales team?
Build an Operational Loop that connects data to action.
The Operational Loop:
Product Data (Segment/Mixpanel) captures the event: "User X invited 2 teammates" or "User Y hit the 'Export' limit."
Enrichment (Clearbit/Clay) adds context: "Company size: 500+, Industry: Legal Services, Role: General Counsel."
Routing Logic (Pocus/Census) applies the "Traffic Light" rubric (🟢 Green / 🟡 Yellow / 🔴 Red).
Delivery (Slack/Salesforce) puts the alert and the playbook in front of the rep.
The Rep's View:
The "Battlecard" Alert. Don't just ping them. Give them the script.
Slack Alert: 🚨 PQA Alert: High-Intent Team Activity
User: Jane Doe (General Counsel @ TechCorp)
Signal: Invited 2 external guests + Uploaded 15 contracts this week.
Playbook: "The Shadow IT Play"
Script: "Jane, noticed your team is collaborating on 15+ contracts this week. I can help set up a dedicated workspace so you have audit logs for those external guests. Open to a 10-min setup?"
The Feedback Loop:
The Head of Growth (or PLG Owner) shouldn't just build this and leave. They need to be alerted too.
Weekly PQA Review: Sit down with Sales Leaders. Look at the 🔴 Red/ 🟡 Yellow PQAs.
The Question: "Did this signal actually convert?"
Refinement: If "Invited 2 guests" yields low conversion, change the threshold to "Invited 5 guests." If reps ignore the "Shadow IT" script, rewrite it.
Accuracy: This loop ensures the signals get sharper over time, reducing noise for sales and increasing trust in the system.
Learn more about Product Led Sales:
6. The Biggest Challenge: Org and Ownership Conflicts
There’s a mismatch in ownership of self-serve revenue. Is it Product own or Sales own?
The Problem: Product owns PLG optimization. Sales owns enterprise deals. RevOps watches from the sidelines. Revenue somehow gets counted as a "win" for three different teams, and nobody's accountable for it.
The "revenue is revenue" mantra dies in execution when commissions and KPIs clash.
The Fix: The "Revenue Council"
You need a governing body, not just a meeting. Call it the Revenue Council.
Who: Head of Product, VP Sales, VP Marketing, RevOps Leader.
Cadence: Weekly "War Room" (tactical PQA review) + Monthly Strategy.
Single Source of Truth: One dashboard. One definition of "Expansion." No arguing over attribution.
Shared KPIs:
NRR (Net Revenue Retention): The north star.
Expansion Pipeline: How much potential revenue is sitting in the user base?
PQA Conversion Rate: How well are we turning usage into deals?
This council forces alignment. A governing structure where Product, Sales, RevOps, and Marketing sit down together and own expansion as a shared outcome.
Here's what that looks like:
Weekly War Room (30 mins)
Pull 5-10 Red PQAs (highest-intent accounts). The Sales leader says: "We've been emailing this account for two weeks, no response." The Product lead says: "They hit the API limit three times this week—they're clearly interested, maybe the email message is off." RevOps jumps in: "Actually, they're also hitting the guest limit. Maybe the friction is in the product, not the sales approach." Suddenly, you're not blaming each other. You're debugging the system together.
Monthly Strategy
Look at the macro numbers. NRR is flat. Product says, "Usage is up 40%." Sales says, "But close rates dropped." RevOps digs in: "The close rate dropped because we changed the PQA definition last month. We're sending way more weak signals to sales, creating alert fatigue." Now you know the real problem. It's not the product, it's the signal accuracy.
Single Source of Truth
Using one dashboard that shows:
How many Red/Yellow/Green PQAs exist
How many converted to paid
How many churned
Which sales reps have the best expansion close rate
Which PQA signals convert best
Quarterly strategy:
What should be the PLS compensation for sales reps? Compensating reps on 🔴 Red/ 🟡 Yellow expansion revenue regardless of channel. If a Yellow PQA self-upgrades to Team Plan, the assigned Sales-Assist rep still gets 10% commission. Same for Red PQAs.
Why? The rep owns the relationship. Their job is maximizing account LTV, not just closing the initial deal. When reps realize self-serve helps their quota, they want the product to drive adoption in their territory.
Source: Running PLG and Sales-Led Motion, SaaStr
Execution is the Moat
Scale expansion and land and expand fundamentally an internal operations challenges. If your Product team, Sales team, and RevOps can't coordinate, expansion stalls.
The real work is internal alignment, figuring out who owns what, how signals flow, when human-sales-assist jumps in, and how to measure success together:
A rubric (Traffic Light) that sets the mandate and routes opportunities
UX that drives viral adoption (Empty States, Trojan Horses, frictionless guest roles)
Pricing that uses psychology (Pack Pricing, Admin Gates)
Data that gives the Sales team alerts and context
Revenue Council that aligns the operations
Here’s what to do for the next 90 days:
Run a Product Qualified Account audit, what signals actually convert?
Launch one UX experiment (empty state nudge)
Schedule your first Revenue Council meeting
Test pack pricing on 10% of new signups
Build out this operational foundation for land and expand.
Additional reading, how to transform a $300M SaaS Company from Sales-Led to Product-Led:
I write weekly about my learning on launching and leading PLG. Feel free to subscribe.
I am Gary Yau Chan. 3x Head of Growth. 2x Founder. Product Led Growth specialist. 26x hackathon winner. I write about #PLG and #BuildInPublic. Please follow me on LinkedIn, or read about what you can hire me for on my Notion page.
