Product-oriented teams are triumphantly declaring, “Sales and marketing had their time. The future is product-led growth.” In other words: if you build it, users will come. We at Greylock are longtime investors in product-led growth (PLG) companies such as Clockwise, Clubhouse, Coda, Demisto, Dropbox, Figma, Quip and Sqreen. I’ve recently invested in this trend of end-users becoming increasingly networked into communities, and therefore increasingly powerful. We understand the power of bottoms-up distribution. But we also continually see great product founders get caught flat-footed, underachieving against their growth goals when they rely solely on organic end-user adoption as their go-to-market (GTM) strategy, rather than as part of a whole-company system. Let’s look at the limits of PLG, a playbook for incorporating it into a more complete GTM strategy, and some of the unique challenges of getting this right.
The legacy enterprise software sale has fallen out of favor over the past decade. Founders, customers, and investors all want to move faster, and to more incrementally risk time and money. The technology industry has largely lost patience for slow elephant hunting -- or conversely on the buyer side, being the elephant. Users are empowered, choosing their own apps and pulling out company credit cards only for the worthy ones. Technology sales become ecommerce, and the best products get picked up magically by the users.
However, “no sales” is an idealistic characterization of how platform product-led organizations scale, especially as they go upmarket. Without designing their company for buying, many self-serve SaaS companies hit a growth ceiling as they saturate their early adopter audience. Some symptoms of hitting the ceiling include plateauing top-of-funnel, small pockets of adoption in companies (vs. consistent user activation and wall-to-wall expansion), continual churn between free/paid product tiers, and churn of the largest and fastest-growing customers churning to enterprise-class solutions.
Companies can achieve greater success if they understand the limits of organic end-user self-service as an initial lead generation and community goodwill strategy, rather than a silver bullet. So how can product-led companies break through this ceiling, and drive scalable growth?
The Three Limits of Product-Led Growth
1. Failing to Serve Other Masters: PLG companies need to go beyond serving individuals, to serving collaborators, teams, their leaders and companies.
Within b2b SaaS, end user adoption is simplest for people solving their own well-contained pains, where they have the most ability to influence their tools. Thus, productivity tools and developer services have been the vanguard of product-led growth. However, most problems SaaS can attack are fundamentally collaborative problems. The pain (and value) is distributed -- either felt by leaders or experienced in cross-team collaboration. In these cases, in order to adopt new solutions, the individual contributors feeling the pain need to convince others to take action.
Team adoption won’t happen magically. There is a much higher expectation for products you need to get others to use, vs. ones you’ll try yourself. Convincing others to try new tools, especially in the age of tool fragmentation and fatigue, takes social capital.
Cross-team adoption, cross-use case adoption, and wall-to-wall standardization won’t happen on their own. Each “expansion” vector can be either product-led or marketing, sales, and success-assisted.
Finally, the Tragedy of Organizations is that some important business objectives don’t map to a specific empowered and incentivized end user, largely due to poor organizational design.
A Case Study: Quip
Quip was clearly a product-led company, with millions of freemium users for both work and personal use cases. However, we discovered that “individual sign-up” was just the start of a buying process. Rather than leaving it at “product-led,” Bret Taylor and team engineered a GTM motion that led to full-company purchases of Quip. Separate product efforts against individual free adoption and team activation were started. Quip’s leadership looked to create clear handoffs of responsibility for different expansion vectors, identified signals of expansion, and then measured the marketing, sales and account management teams against progressing teams to the next stage of expansion. They realized they had the most success when their initial deals were with influential teams, and they needed executive sponsorship to get cross-team expansion. Even though they built a product that prided itself on intuitive experience, the company still trained teams to work successfully on Quip.
No alt text provided for this image
2. Failure to Segment Customers: PLG companies need to understand and adapt their product to differing needs and buying processes if they want to extend upmarket.
Different segments have different needs, different adoption paths, and different willingness to pay. SMBs are churnier and can spend less, but have more consolidated decision-making. They more naturally fit fully self-serve end-user adoption, whereas bigger companies are stickier and offer more room for expansion, but require more internal coordination.
Many organizations start with the SMB with an assumption that they will build upmarket. Serving the enterprise often requires starting at square one in terms of customer discovery. The difference in requirements can be extensive, ranging from access control to different architectures of communication, to completely different workflows. Some products extend upmarket relatively easily: Figma released an “Organization” tier to support enterprises and Slack connected teams with “Grid” for enterprises. However, Gusto will never cross paths with Workday, because HR/payroll are entirely different products at <100 and >1,000 employees (their respective target customers).
As another example, while the core Sqreen IP (dynamic security micro-agents) technically would work in enterprise companies, the team had to evolve the product significantly as the company was pulled upmarket. Startup engineering leaders were happy with an all-in-one-security Node and Ruby solutions with single-line-of-code developer integration. In the enterprise, they had to build at-scale agent deployment, workflows for developers and application security teams to collaborate, and integrations into existing security tools.
A Word of Caution: Once You Go Enterprise, You Don’t Come Back
Extending upmarket is mostly a one-way street. There are many extraordinary companies that have started in the SMB or in prosumer use cases, and eventually grown into the enterprise: Datadog, Zoom, Twilio and Slack are recent favorites. However, companies that build their enterprise business early generally struggle to “add self-serve” or “shift downmarket” later. Complexifying a product is easier than simplifying it, and an enterprise software business is a special case of the innovator’s dilemma.
Selling to SMBs feels like cannibalizing your cash cow, if you’ve already built an enterprise business throwing off large-dollar contracts. Very few companies have been able to “move downmarket” after building an at-scale enterprise business first. The possible exception is companies like MongoDB, which build strong bottoms-up adoption (in their case, in the form of open source usage), monetized the enterprise first (with an on-prem product), and has since released a product that is bringing in smaller customers (cloud product Atlas, boosted by acquisitions such as mLab).
We do not believe that all PLG companies should rush upmarket, but instead that they need to clarify their value prop to different customer segments. Sometimes, the globally-maximizing move is actually to consciously delay an enterprise extension, build for and own the SMB/mid-market, and to defer the largest enterprise customers that can skew your roadmap and drown your company.
Some markets support product-led distribution in the SMB and midmarket, but then require traditional outbound selling in the higher end of the enterprise market, where roles are more divided. Continuing the Sqreen example, in the SMB the user and buyer were the same and we could do a single phone call to drive a sale. In the enterprise, helping security teams convince developers to deploy the agent became an additional Sqreen responsibility.
Enterprises, for good reason, have built many gates and hired many gatekeepers: security, legal and compliance reviews, processes for accessing data and APIs, IT and procurement processes that push for tool consolidation. They test for scalability and they have requirements around access control. This is especially true for highly regulated industries; if you work at a bank institution or a hospital, it’s quite hard to “self-serve” any software as an end user.
Enterprises also have more complex deployments. While many companies self-serve GitHub’s SaaS offering, private cloud deployments of GitHub or GitLab necessarily involve technical resources and customer work. How much does any one user want to use GitHub? Not enough that they will single-handedly navigate the convoluted on-prem network architecture of a large financial institution and deploy supporting infrastructure for that GitHub instance without support. Enterprises have larger sunk and switching costs. To navigate all that, these customers usually need sales people (and sometimes a supporting case of sales engineering, technical account management, and customer success) to help user champions navigate their messy internals.
While bottoms-up adoption is a huge top-of-funnel advantage, strong enterprise sales and success practices that result in executive-sponsored standardization efforts can be the most effective way to expand accounts that a product has already penetrated. For example, even at Quip, CEO-level buy-in and training was a major deal accelerator over landing in a hundred separate teams and expecting them to organically coalesce.
Companies that have amazing bottoms-up adoption can see their growth stall as they saturate the early adopters of the SMB/startup segment they initially targeted, unless they redesign their business for the next leg of growth.
3. The Law of Large (Revenue) Numbers: PLG companies need to invest in a portfolio of top-of-funnel strategies to complement organic viral adoption.
While organic word-of-mouth driven adoption is a massive advantage, it is best amplified with community enablement, paid end user acquisition, traditional enterprise demand generation, field, content and brand marketing activities, and even sales people doing outbound pipeline generation. By the time bottoms-up companies go public, they spend enormously on these efforts.
At some point, gravity sets in, and purely organic inbound won't support the company’s growth goals. As companies scale, they need to take destiny into their own hands to build their top of funnel robustly, and continually experiment.
Designing for Buying in PLG: A Playbook
To leverage initial end-user adoption to its fullest potential, companies must build this product-led growth into an integrated buying system.
1. Do Your Recon
Start by understanding how different the problem you are solving is across individuals, teams at different levels of scale, leaders, and if applicable other use cases/departments. For product-led companies, this generally requires four pieces: good product instrumentation, good sales activity measurement, good community intelligence, and the ability to tie these signals together.
Identify all the stakeholders involved in choice, purchasing and adoption. Interview, survey and articulate how each stakeholder sees your value prop. Is it unique and compelling, or insufficient and irrelevant?
Understand the whales. Do you have a single customer paying 10X what others are? Do they use the product differently than others?
Map the golden paths. Chart the buying journey for different segments of customers (choose no more than 2-3). Identify the breakpoints for conversion against each stage of that buying path. Are there RFPs? How are you evaluated differently? Do you have a single customer paying 10X what others are? Does the buyer differ in your segments?
2. Treat Land and Expand Like a User Journey
Use Your Full Force. Design a user and buyer journey that apply different teams to different problems -- just as there are times to use drones, spies, infantry and air support, progress in the customer could require in-product activation and upsell, or a nurture email or phone call from sales.
Go Beyond the Beachhead. Bottoms up enterprise products aren’t adopted in one-fell swoop. Some questions to consider:
- Is there a compelling single-player use case for the product?
- If so, what is the trigger for individuals to bring in teammates?
- Who are the best individuals within a team, to introduce a product for team activation?
- How do teams test the product?
- How many people need to use the product for it to be useful?
- What happens if only some people switch?
- Is there interoperability with existing tools?
- What if there’s one holdout user on a team?
- What if you sit at the intersection of two personas, and one persona, or one leader resists?
Making investments in product virality of B2B products beyond the land is still an emerging art, taking many cues from consumer companies. SaaS companies can be intentional and clever about the growth motion of the product, beyond the initial user acquisition. They can design for in-team and cross-team virality.
Success is Part of the Sale. If existing users are your biggest marketing channel, and “expansion” becomes most of revenue growth (true for companies like Figma), then the success and happiness of those users and customers is mission-critical. While many companies treat community and customer success as cost centers, in the most scalable PLG companies they are often strategic, outcomes-oriented, proactive functions.
Software usage is a prerequisite to value, so define engagement-oriented goals that are leading indicators to value (and thus, revenue) for community and success teams, rather than operational goals (response time) or “happiness” goals (CSAT, NPS) that can be incomplete or even misleading.
3. Whole-Company Systems Are Hard: Mind the Gaps
This is incredibly hard for companies to get right. Here’s a checklist of the major debates to have as you build your system. Many of these issues boil down to needing strong leadership clarity and cultural alignment around what customers to prioritize and serve.
Functional Scope and Handoffs Between Teams
Designing whole-company systems requires leaders to look at functions with a fresh eye (and even building new teams, such as community and success). Companies such as Figma, Notion and Datadog are building a new playbook with new kinds of leaders. They work across traditional silos, build trust across functions, and must be incentivized and measured differently.
This can go badly wrong, even in great product companies; GitHub’s GTM organization was infamously restricted from marketing to any existing free users of GitHub. For a period of time, they failed to leverage their company’s biggest strategic advantage, for fear of pissing off the developer community; the root cause was lack of alignment across and trust between functional silos.
Unclear Resource Allocation and Underlying Cultural Conflicts
Building a whole company system that leverages end-user adoption to serve different personas and potentially go upmarket, requires continually tough choices. Resource allocation in product and engineering across segments and personas is a recurrent question. How much effort should you put toward “enterprise must-have features” or the self-serve billing engine? How many commercial vs. enterprise reps should you hire?
Startups that equally value multiple customer segments before they’ve really won any are doomed to fail. Equally common is a cultural allergy in to the “enterprise” in companies that start out prosumer or developer-focused. Without resolving cultural conflicts like this, companies will struggle to scale.
Category Choice and Consistent Positioning
While you may have different value propositions for different personas in the same company, you only get one “elevator pitch.” Startups with small bullhorns are best served with a single core category positioning focused on one clear persona. This is hard in some cases, simpler in others.
To illustrate -- a few examples: should your landing page emphasize the product's ease of use and simplicity, or its robustness and enterprise integrations?
Is Segment’s core audience marketing teams, product teams or engineering teams? The value of the platform is in part that unifies the data pipeline across use cases, but they still need to focus their marketing on a single buyer. Based on their website, their core audience today is marketing, and “CDP” is considered marketing technology, but it’s a tough call.
On the other hand, in the case of Twilio, a communications API for developers is a communications API for developers, no matter how big the development team is.
Prioritizing Customer Feedback
Without a set of principles for prioritizing customer requests, the loudest and neediest customers will drown out others. This often manifests as companies building for the highest revenue customers (who will have scale use cases, at the cost of simplicity) or the most experienced customers (who will have advanced use cases, at the cost of the new customer experience).
As a PLG company scales and attempts to serve different users and customer segments, it is crucial to manage these tradeoffs consciously. Without good processes and tools for high-context, cross-silo product collaboration, these questions remain murkily unresolved, teams make inconsistent investments, and products (and customers) suffer.
There are three conflicts that regularly come up in pricing for product-led growth companies:
- Prosumer vs. business pricing. For example, the majority of Dropbox “pro” accounts were being used by businesses in lieu of the “business plans,” and thus were underpriced for a long time.
- SMB vs. enterprise pricing. For example, enterprises tend to expect volume discounts but are actually more able and willing to pay for richer feature sets.
- Pricing for usage expansion vs. revenue capture. For example, in many companies there are at least three categories of users: superusers (creators, administrators), users, and lightweight users or observers. Charging for lightweight users discourages adoption.
Pricing is specific to each product, but a few good rules of thumb for PLG companies: create experienced value for the customer before charging for it, differentiate pricing by customer segment, and clarify if you are pricing for growth (encourage adoption) or harvest (maximize value capture) mode.
Product-Led Growth is Only the Beginning
Individual end-user adoption is only a small slice of the modern whole-company GTM system that product-led software companies need to build. It’s incredibly difficult, because it requires product leaders to think about growth, go-to-market leaders to think about adoption and customer success, and companies to organize themselves to coordinate across end-to-end user journeys. I often hear founders say they’ll hire great sales and marketing people once they “get the product right.” Hiring in GTM is only part of the PLG challenge, which requires system-wide design rather than a sequential handoff.
However, the reward of solving this puzzle is worth it; bottoms-up companies that build whole-company buying systems are incredibly valuable and extremely defensible. They have their cake and eat it too: an efficient and high-velocity sales motion, and the user scale, stickiness and contract value of larger customers.