The PLGeek Guide to a best-in-class PLG org
Note: This is a repost of an interview I did with OpenView Partner Kyle Poyar for his newsletter Growth Unhinged. Please consider subscribing over there to have a treasure trove of PLG wisdom regularly dropped in your inbox.
Real talk: what the heck does a best-in-class PLG org look like?
It’s one of the most frequent questions I get asked by founders, investors, and leaders. It’s also top of mind for both companies that are optimizing an existing PLG motion and those who are building a PLG motion from scratch. Some common questions include:
Should there be a dedicated growth team or should it live within the product org?
Should someone own the self-serve revenue number? If so, who?
What skills and experiences should I look for in PLG talent?
I finally decided that “it depends” doesn’t cut it anymore. For help I turned to PLG expert and advisor Ben Williams, most recently Snyk’s VP of products (Developer Journeys, PLG). While at Snyk, Ben’s teams contributed to explosive growth across all core KPIs including ARR (+160% YoY), acquisition, activation, and monetization. Snyk of course is the maker of developer-focused security software, most recently valued at $8.5 billion (up from “only” $1 billion in January 2020).
Keep reading for Ben’s take on why you need a dedicated PLG team, what that team should look like at scale, and how to hire for top PLG talent.
This is a guest post in partnership with PLG expert Ben Williams. Ben is British—expect to see an occasional “s” where a “z” should go and please don’t hold that against him!
The TL;DR - How to build a PLG org
Over time, PLG teams typically own a company’s growth model. Without this dedicated team, there is often no ownership of the growth model—or worse, the growth model isn't even created and quantified.
A PLG team is a cross functional team empowered to create, evolve, and optimise whole product experiences to drive customer acquisition, retention, and expansion.
PLG teams will typically be organised by outcome as opposed to by function or product architecture.
A good rule of thumb is that each team in a SaaS PLG group should have the following: 1 product manager, 1 engineering manager, 3-5 engineers, 1 designer, and 1 growth marketer.
North Star metrics in PLG companies tend to be product-engagement-based metrics that every customer-facing function in the company has the ability to influence in some way.
PLG companies can also look to Product Driven/Influenced Revenue (PDR) to track overall GTM efficiency. PDR is revenue from customers where meaningful activity was observed and recorded in the product before any sales interaction.
Some of the most amazing, successful PLG hires are often right under your nose. Investing in internal mobility can be a big advantage for building a PLG org.
Why you need a dedicated PLG team
Consider the three core growth levers of acquisition, retention, and monetisation. Every business needs to be able to answer the question how do we:
And in each of those three dimensions a business will have primary (and sometimes secondary) growth motions including product-led, marketing-led, and sales-led.
When users realise value from a product, it’s unsurprising that most companies’ primary motion for retaining users and teams will be product-led. Many businesses will also either have—or aspire to also have—product-led motions for acquisition and/or monetisation.
A growth model ultimately describes and quantifies how a product grows. A founder or first growth hire might create the initial iteration, but over time, PLG teams typically own the growth model. They ensure it is kept up to date with feedback incorporating observed performance of growth loops, learnings from the growth team, evolution of the product, and shifts in company strategy or the wider market.
And they use the growth model to plan and execute the strategic opportunities they focus on.
But the growth model should inform plans not only for the PLG team, but teams across the company, R&D, and beyond.
Without this dedicated team, there is often no ownership of the growth model—or worse, the growth model isn't even created and quantified.
That leads to prioritisation decisions being made without strategic input. Inevitably, competing priorities such as building feature X to help close the next big deal can mean important product growth initiatives are inadequately funded and resourced, or passed over entirely.
Antipattern to watch out for - organisations that default to believing that PLG is the sole responsibility of this one team/org. By that logic, they assume PLG is not their concern. This should be a red flag.
Standout PLG companies have growth built into their DNA. Product teams prioritise what they build based on whether the motion supports the overall growth model, or whether it fuels or inhibits micro and macro growth loops. The criteria for judging the initial and ongoing success of new features can include relevant core growth metrics at the feature level and product level.
When that is the case, having a PLG team can be an additional superpower, as the PLG team can focus on:
core constraints within the growth model;
finding and alleviating those constraints;
getting growth loops spinning faster;
and where and when appropriate layering on new loops.
When it's not the case, and the business is effectively delegating PLG success to a single team/org, then that team will unlikely be set up for success.
Evangelising and over-communicating this as an anti-pattern across all R&D teams is important—they need to be aware of the growth model, and how what they do contributes to it. Consider naming the team something other than “the PLG team”—an alternative might be something like “Lifecycle team.”
How to structure your PLG team at scale
What is a PLG team anyway?
It’s a cross functional team empowered to create, evolve, and optimise whole product experiences to drive customer acquisition, retention, and expansion.
Unpacking a few things from that:
Multiple connected outcomes: each interplaying as part of a larger growth model
Whole product: the end-to-end experience from the first time a user hears about your brand through their entire lifecycle
Cross-functional: diversity in both ideas and ability and agency to execute across that whole product surface
The growth model and strategy will determine where the PLG team is focused at any given time. Sometimes the focus will need to be on driving improvements to activation through onboarding as a means to drive improved long term retention and downstream monetisation.
At other times, the focus may shift to drive new user growth through, for example, content loops or viral loops. Monetisation initiatives might cover a self-serve revenue channel and/or synergy with an enterprise GTM via a product-led sales process. Larger PLG teams are able to execute on multiple focus areas concurrently.
As such, PLG teams will typically be organised by outcome as opposed to by function or product architecture. It's not untypical for the organisation to evolve over time to adapt to changes in the broader growth model and market.
An outcome-oriented organisation provides freedom for a PLG team to operate wherever opportunity lies. A team driving improved activation, for example, could undertake initiatives that unlock new acquisition channels. These ICP users may be known in your org to activate at consistently higher rates than others.
A team focused on new user acquisition could work on initiatives like standing up a new growth loop via a sidecar product, to building mechanisms supporting virality, or optimisation of the signup and login experience.
The surfaces worked on might include the company website, web apps, mobile apps, content in integrated third-party platforms, notifications (emails, Slack/Teams), and more (e.g. IDEs in the dev tooling space). That's where the whole product perspective is important.
At Snyk for example, just looking at acquisition, some efforts included (non-exhaustive):
Conversion optimization (CRO) on website landing pages and login flows
Building content-based SEO-optimised growth loops (company generated company distributed content loops using non-search distribution channels e.g. SCMs such as GitHub, GitLab, and Bitbucket)
Building and optimising team invitation and referral mechanisms
Free taster tools requiring no signup
To be effective in growth execution across the entire user and customer lifecycle, PLG teams need to be truly cross functional.
Working across this variety of surfaces and mediums requires diverse, balanced teams. Product managers, developers, and designers tend to form the typical core of a product team. In my experience, PLG teams necessarily also include decision scientists, and in my experience, growth marketers. Not only does this kind of diversity bring a broader toolbox to new paths to innovate and experiment, it also brings a wider palette of creative ideas.
While it’s hard to give universally correct guidance, a good rule of thumb is that each team in a PLG group in a B2B SaaS should have:
1 product manager
1 engineering manager
1 growth marketer
I prefer decision science as a shared resource and central function, with each supporting two to three teams, and helping join the dots with data across the lifecycle. Growth marketers will often be specialists and be part of teams where they have relevant expertise. For example, a team focused on activation is best supported by a lifecycle marketer, whereas a team focused on acquisition will benefit from SEO expertise.
On the engineering side, starting smaller and scaling out over time is generally preferred. Teams in smaller, earlier stage organisations will likely have more hands-on engineering managers.
How to prove impact with a North Star KPI
Most B2B companies default to revenue as their lowest common denominator North Star metric. Revenue, however, is a lagging indicator too far removed from many teams' day-to-day activities, so it's critical to understand how teams across the company can contribute toward advancing that revenue goal.
For product-led companies, revenue is closely tied to users, their teams, and their companies realising value from the product. As a result, it's typically appropriate for North Star metrics in PLG companies to represent that. This often ends up being a product-engagement-based metric that every customer-facing function in the company has the ability to influence in some way.
Having a value-based North Star metric in place allows a derivative to be used as a meaningful measure of retention. Additionally, it can be used as the basis of regression analysis to help define PLG-focused metrics such as activation and engagement states.
Working backwards can help you understand the behavioural shifts a PLG team might want to drive in order to create impact. It's not uncommon for the North Star and derivative growth metrics to be researched, defined, and ultimately, evolve over time as part of the work of a PLG team.
PLG companies can also look to high level metrics such as Product Driven/Influenced Revenue (PDR) to track overall GTM efficiency. PDR is revenue from customers where meaningful activity was observed and recorded in the product before any sales interaction. While it’s not immediately actionable, PDR (and changes to it over time) can demonstrate the efficacy of the PLG go-to-market motion and how well the product performs as an acquisition, retention, and expansion vehicle.
It can also be decomposed to look further at only product-driven land (net new) revenue, or to cohort other key metrics. For example, looking at net revenue retention (NRR) through the lens of product-driven vs. non-product revenue can be revealing.
If you go a step further, the natural rate of growth (NRG) is a metric that factors in PDR relative to overall company growth, with a discounting factor for any paid acquisition. It helps describe the company rate of growth in the absence of any paid marketing or outbound sales motions.
How to hire top performing growth talent
Over the years, I've learnt that some of the most amazing, successful hires are often right under your nose. Which is why investing in internal mobility can be a big advantage. That might take the form of:
Lateral moves, such as a product manager in a platform team moving to a PLG-focused role;
Promotions, like a stellar growth PM taking on broader PLG group-wide responsibility;
Or even role shifts (a talented engineer stepping into a growth product management role).
The most important advice I have here is to understand what makes a successful hire on a PLG team. And we’re talking about more than just the things that people can learn while in the role, with the right organisational support, tools, data, and so on. I've absolutely seen brilliant folks have a challenging time creating impact in a PLG team, and conversely I've seen people blossom in the growth context.
It's a necessity for folks in a PLG team to be highly collaborative. The benefits of diversity of ideas and execution of such widely cross-functional teams can't be realised without that. They need to enjoy moving fast and pivoting often, be willing to fail and be accepting of failure as a necessary part of the learning process, while being totally non precious with their ideas and implementations.
They should be super curious, love talking with and learning from users, and simultaneously gain great fulfilment from creating quantified and qualified impact through their work. It's not where everyone feels comfortable, and that's OK—but having this in mind when building out a PLG team will help avoid costly missteps.
Closing advice: how to ensure the success of your PLG org
We've mostly focused on the people and strategy aspects of building a PLG org. But there are other important ingredients that go into ensuring the success of any PLG org. PLG orgs need executive support and alignment—and this kind of foundation needs to be in place before any efforts to spin up a team.
PLG teams also require trustworthy product data. If that's not in place before a team is created, it needs to be at the top of their backlog to instrument and start to collect data. Further needs include tooling for instrumentation and experimentation, and developing processes that foster learnings leading to impact.
Another important consideration is timing. When is the right time to create a dedicated PLG team, and how do you get started?
The general accepted advice I’ve heard is post product-market fit. Before that point, everyone should be singularly focused on reaching that critical milestone. And don’t underestimate the value of starting small. It's going to be a journey of learning, as the team builds muscle around likely new ways of working.
Small teams can be remarkably effective and make it easier to make a case for expanding the team down the line.