At some point between $10M and $30M ARR, most PLG founders have the same conversation with their board. Usage is strong. Expansion within SMB accounts is real. But the big logos are not closing, and the ones that do close churn at year two. Someone says "we need enterprise sales" and the next quarter a VP of Sales is hired, an SDR team is assembled, and the company starts running discovery calls on $150K deals. Twelve months later, almost nothing has closed and the AE team is pointing at the product.
They are right. Not because PLG products cannot sell enterprise, but because five specific dimensions of the product have to change before enterprise sales can succeed. When those dimensions have not changed, every dollar spent on sales capacity is spent early.
TL;DR
- The $20-30M ARR inflection is a DNA threshold, not a sales capacity problem. Adding an enterprise sales team before the product supports enterprise deals wastes headcount and loses deals you could have won later.
- Five Product DNA dimensions change during a PLG-to-enterprise transition: complexity increases, the buyer-user split widens, TTV has to be managed differently, admin and security surface becomes required, and the expansion model must shift away from seat-based self-serve.
- The product work happens before the enterprise AE hire. A minimum viable enterprise surface includes admin controls, SSO/SAML, audit logging, and a documented security posture. Without those, the deal stalls in procurement.
- The companies that got the transition right changed the product architecture first and treated the first enterprise AE as a signal-gatherer, not a quota carrier.
PLG works because it removes the human from the critical path of value delivery. A user signs up, reaches an aha moment inside the product, and the conversion or expansion happens downstream without a salesperson ever being involved. That architecture is genuinely efficient at the SMB tier.
Enterprise is structurally different. The decision involves more people. The buyer is often not the user. The security and compliance team has a vote. IT has a vote. Legal reviews the contract. Procurement negotiates terms. And every one of those stakeholders needs something from the vendor that a self-serve PLG product was never built to provide.
The failure mode is not that PLG companies cannot win enterprise deals. Some do, without much product change, especially when the initial user is also the economic buyer. The failure mode is attempting the transition at scale before the product has the structural surface area that makes enterprise deals reproducible.
"Hiring enterprise sales before the product can support enterprise procurement is not a sales problem. The AEs will tell you that. The question is whether you believe them before you burn a year finding out."
Jake McMahon, ProductQuant
The 5 DNA Dimensions That Change in a PLG-to-Enterprise Transition
These five dimensions are not optional upgrades. They are the structural requirements that make enterprise deals closeable. Companies that skipped them and tried to compensate with sales process found out that process cannot substitute for product.
1. Complexity: from instant to managed
PLG products optimize for low complexity. Short TTV, minimal configuration, fast aha moment. That architecture serves individual users well. Enterprise deals involve implementation scopes, phased rollouts, admin configuration, and organizational change management. The product has to support that complexity, not resist it.
This does not mean making the product harder to use. It means giving administrators the controls to stage a rollout, manage user provisioning, configure permissions by role, and monitor adoption across the organization. The individual user experience can stay simple. The admin and IT experience has to become more capable.
Figma did this deliberately. The core canvas experience stayed fast and minimal, but the admin layer grew substantially as enterprise deals grew. Workspace controls, user management, audit logs, and provisioning integrations were all built before enterprise ACV crossed meaningful thresholds.
2. Buyer-user split: from aligned to separated
In PLG at the SMB tier, the buyer and user are usually the same person or within one decision layer. The user loves the product, pays for it, and expands it. That closed loop is why PLG economics are so attractive.
Enterprise breaks the loop. The user may love the product. The buyer is the VP or CTO or CPO who has never opened it. The buyer cares about procurement terms, security posture, integration with the existing stack, and what the rollout plan looks like. The user cares about features. Those are different conversations and they require different product surfaces to support them.
Security documentation, compliance certifications, procurement questionnaire responses, admin reporting, and executive-facing ROI dashboards all exist to serve buyers who are not users. That material has to exist before the sales team can close deals. An AE cannot manufacture it on the fly in a procurement review.
3. TTV: from minutes to managed expectations
A 15-minute TTV is a PLG advantage. Self-serve activation, fast aha moment, low friction. But enterprise rollouts take longer, and that delay is organizational, not technical. The problem is when the product has no mechanism for managing a longer, staged activation and no tooling to help the customer success team track rollout progress across a 500-seat deployment.
The enterprise version of TTV management means onboarding milestones, progress dashboards for admins, executive-level adoption reporting, and defined success criteria that go into the contract. Companies that tried to give enterprise customers the same self-serve onboarding as SMB users found that those customers churned at renewal without ever understanding whether the product had worked.
Enterprise SaaS NRR with structured onboarding runs 20-30 points higher than self-serve onboarding at the same account size (OpenView, 2024), and the gap traces back to the first 90 days.
4. Admin and security surface: non-negotiable
This is the most concrete gating dimension. Before a mid-market or enterprise deal can close, the following typically have to exist.
- SSO/SAML integration with at least Okta and Azure AD. IT will not provision users manually across a 500-seat deployment.
- Role-based access control with at minimum viewer, editor, and admin tiers. Procurement teams ask for this in every security questionnaire.
- Audit logging covering user actions, permission changes, and data access. This is a compliance requirement for any company with SOC 2, ISO 27001, or regulated data.
- Data residency options or documentation about where data is stored. US enterprise customers with HIPAA exposure or EU customers with GDPR obligations ask before signing.
- A completed security questionnaire template (typically SIG or CAIQ) that the team can send to procurement without custom work per deal.
None of this requires SOC 2 Type II certification on day one, though that helps. It requires that the product and company have the posture to answer the questions. A prospect who sends a security questionnaire and gets a blank response or a three-week delay will not close. They will move to a vendor who had the answers ready.
5. Expansion model: from seat-based to module or usage
PLG expansion often runs on a simple seat model. More users join, the bill goes up, the company sees NRR. That works at the SMB tier where seat growth is organic and billing is handled by a credit card.
Enterprise expansion has a different shape. Annual contracts mean that seat growth does not generate revenue until renewal. The natural enterprise expansion mechanism is module adoption, usage tier upgrades, or expanded scope across more business units. The product and pricing have to be designed to capture that expansion at contract time or at structured upsell moments, not on a per-seat basis that procurement will cap anyway.
Intercom shifted from pure seat pricing toward a usage-based tier model as enterprise ACV grew, because enterprise buyers resisted open-ended seat-based pricing at scale. Notion moved toward business and enterprise tiers with feature-gated capabilities, not just seat count, to create defined upsell moments. Both moves were product architecture decisions before they were sales decisions.
When the expansion model does not fit the motion, NRR stalls at renewal.
The expansion ceiling article maps how PLG seat models break at the enterprise tier and what pricing architecture changes are needed before the sales motion can succeed.
The $20-30M ARR Inflection Is a DNA Threshold
The $20-30M ARR range shows up consistently as the moment when PLG companies attempt the enterprise transition. That number is not a coincidence, but it is widely misread.
Most founders interpret the inflection point as a sales capacity signal. The SMB ceiling is visible. Self-serve churn is rising. The funnel is filling with companies that need a human to close. The obvious interpretation is that the company needs more sales firepower.
The correct interpretation is that the company has grown into a segment where the product architecture does not match the buying behavior of the accounts it is attracting. That is a product problem before it is a sales problem.
of PLG companies that added enterprise sales before completing minimum admin and security features reported ACV deals stalling in procurement rather than competitive loss (Kyle Poyar, OpenView, 2023). The product gap, not the pitch, was the primary deal-stopper.
Companies that used the $20-30M signal as a product audit trigger, rather than a hiring trigger, closed their first enterprise cohort faster and with higher NRR at year two. The product work took 6-12 months. The first enterprise AE was hired after that work was substantially complete.
This reframe matters for budget allocation. The question at $15M ARR is not "how many AEs do we need?" It is "which of the five DNA dimensions are we missing, and in what order do we build them?" The sales hire comes after an honest answer to that question.
What Product Work Happens Before the Enterprise Sales Motion
The minimum viable enterprise surface has a specific, finite scope. It is the product work that takes a deal out of the "not ready for procurement" category and into the "can close with effort" category, without requiring feature parity with mature enterprise incumbents.
Phase 1: Security and admin foundation (months 1-4)
SSO/SAML, RBAC with admin controls, audit log export, and a completed security questionnaire template. This phase often gets estimated at two sprints and takes three to four months when done properly, because it requires security review, documentation, and testing across multiple IdP configurations. Ship it once and ship it right.
Simultaneously, the customer success infrastructure has to grow. Enterprise onboarding is not the same as self-serve activation. Assign a CS lead to every pilot. Define what success looks like in writing at the start of every trial. Build the internal reporting that lets your CS team see rollout progress before the customer calls to complain.
Phase 2: Enterprise-grade expansion mechanics (months 3-7)
Revisit the pricing model before AEs start proposing it. If procurement will cap seat growth or reject the contract structure, the model has to change first. Design the enterprise tier around defined feature packages, not just seat count, so there are clear upsell vectors at renewal without renegotiating the base contract.
Build executive-facing reporting. Usage dashboards for individuals are not enough. Enterprise buyers need aggregate adoption data and ROI documentation they can bring to their CFO. If the product cannot produce that, the renewal conversation becomes a negotiation by default.
Phase 3: Sales enablement before the AE hire (months 6-10)
Write security questionnaire responses before an AE needs them on a live deal. Build the standard MSA, DPA, and SLA documentation before the first enterprise pilot completes procurement. Run those pilots with a founder or product manager in the room, noting every question that could not be answered cleanly. That document becomes what the first enterprise AE inherits.
| Phase | Product work | Timeline (rough) | Gate to next phase |
|---|---|---|---|
| 1. Security and admin foundation | SSO/SAML, RBAC, audit log, security questionnaire template | Months 1-4 | First enterprise pilot completes procurement without a security block |
| 2. Expansion mechanics | Enterprise pricing tier, executive reporting, CS onboarding playbook | Months 3-7 | Pilot account renews with documented ROI |
| 3. Sales enablement | Procurement packet, MSA/DPA/SLA, founder-led pilot learnings documented | Months 6-10 | First AE can run a deal without founder in procurement review |
| AE hire | Sales motion begins at scale | Month 10-12+ | Product surface is complete; AE is not discovering gaps mid-deal |
Organizational Signals That You Are Attempting the Transition Too Early
Most teams attempting an early enterprise transition show the same set of signals before the first AE even joins. Recognizing them before the hire saves 12 months of expensive discovery.
AEs ask for product features in their first 30 days. If every deal that enters procurement surfaces the same two or three missing capabilities, the product is not ready. The AE is not wrong for asking. The deal is revealing a structural gap that will appear on every enterprise deal until it is fixed.
Pilots run longer than 90 days without converting. A 90-day enterprise pilot that does not convert is almost always a product-readiness signal, not a sales-skill signal. Either the onboarding was insufficient, the procurement requirements were not met, or the value case was not documented well enough to justify the spend. All three are product and CS problems.
The security questionnaire process takes more than two weeks per deal. When every enterprise prospect sends a questionnaire and every questionnaire requires custom work, the company is building its security documentation reactively instead of proactively. That process drag kills deal velocity and signals to procurement that the vendor is not enterprise-ready.
Churn at year two on enterprise accounts is driven by "not enough for this use case." If the year-two renewal conversation reveals that the account outgrew the product's admin capabilities or that IT never properly provisioned users because SSO was clunky, those are product-readiness failures that show up 18 months after the deal closed. The original deal closed on product promise. The churn reveals the gap between promise and product.
No enterprise deal has closed without founder involvement. When founders are required on every enterprise deal to paper over product gaps or answer procurement questions the team cannot handle, the company does not yet have a repeatable enterprise motion. It has a founder-dependent enterprise motion, which does not scale.
The Companies That Got It Right: What They Changed First
The pattern across PLG companies that executed the enterprise transition well is consistent. They changed the product architecture before they changed the sales architecture.
Atlassian
Atlassian is the canonical PLG-to-enterprise story, and the part that gets underreported is the product work that preceded the enterprise motion. User management, group-level permissions, and admin-facing dashboards were built years before Atlassian moved toward a formalized enterprise sales team. By the time enterprise ACV became a meaningful revenue line, procurement teams were not hitting walls they could not climb over.
Atlassian also treated the data center and cloud enterprise tiers as distinct product lines with distinct security postures, not just price points. Enterprise deals closed because the product had the right architecture.
Figma
Figma's enterprise transition followed a clear sequence. Admin controls and org-level management features were shipped well before the company hired a large enterprise sales team. The design tool was never simplified for enterprise. It was augmented with administrative capability while keeping the individual user experience unchanged.
The expansion model also changed before the sales motion changed. Moving from per-editor pricing toward enterprise agreements with defined feature packages gave procurement teams a structure they could negotiate against, which shortened deal cycles significantly.
Notion
Notion waited longer than most PLG companies before building admin controls, and the deal losses reflected it. When they did build the enterprise tier, it came with a full rework of the admin experience rather than a bolt-on. That rework took longer than expected but produced a cleaner result. The practical takeaway: when you build the enterprise surface, build it properly. Incomplete admin surfaces generate CS debt that compounds at every renewal.
Know which DNA dimensions your product is missing before you make the next hire.
The ProductQuant DNA audit maps the five transition dimensions against your current product state and gives you a prioritized build sequence before the sales motion starts.
FAQ
Common questions about the PLG-to-enterprise transition and what the product needs before the sales motion starts.
When is the right time to start building enterprise features?
Start building the security and admin foundation when enterprise-sized companies are landing via self-serve without converting. That signal means demand exists but the product cannot close. The typical trigger is 5-10 companies above 200 employees in your free or SMB base with meaningful usage but no conversion. Do not wait for an enterprise AE to surface the gap in their first quarter.
What is the minimum product surface required before enterprise sales can succeed?
SSO/SAML with at least two IdP integrations, role-based access control with admin and viewer tiers at minimum, audit log export, and a completed security questionnaire template. That combination covers the most common procurement blocks. Data residency documentation and a SOC 2 report (or a roadmap with a committed date) are strong additions and often required for financial services, healthcare, or government accounts. Without those four core items, the deal stalls in IT review on almost every mid-market or enterprise prospect.
Can you run PLG and enterprise simultaneously?
Yes, but only with separate surface areas for each motion. The self-serve experience stays fast and frictionless. The admin and enterprise layer serves buyers and IT without touching the user experience. The failure mode is building enterprise complexity into the primary interface, which degrades PLG users without satisfying enterprise buyers. Architectural separation is required, and the customer success motion should be operationally separate as well.
What does the first enterprise AE hire look like if the product is not ready?
It looks like a frustrated AE who spends their first quarter identifying product gaps and their second quarter managing prospects who have been waiting for those gaps to close. The AE is not the problem. They are a signal-gathering system that is telling you what should have been built before they were hired. If you hire an enterprise AE before the product is ready, treat them as a product researcher for the first six months, not a quota carrier. Do not fire them for missing a quota that the product cannot support. Use what they learn to finish the build, then give them a real number.
How do you retain PLG users while adding enterprise complexity?
Keep enterprise features in the admin layer and enterprise tier only. The individual user should never encounter SSO configuration screens, audit log exports, or procurement documentation. If enterprise complexity is leaking into the core product, that is a design problem. The companies that retained PLG metrics through their enterprise transition kept the two experiences isolated and measured each independently. Activation rate for self-serve signups and enterprise deal cycle length should never be managed toward the same product tradeoff.
Sources
Know where your product stands before you make the hire
The ProductQuant DNA audit maps your current product against the five enterprise transition dimensions and gives you a sequenced build plan. Most teams complete it in two weeks. It costs less than one month of a mis-timed AE hire.