PLG FAQs: The Most Common Questions about PLG from Sellers

The team at Pace has spent the past several months meeting with hundreds of sellers and sales leaders navigating the transition to product-led growth (PLG). As you can probably imagine, patterns start to emerge in these conversations.

I sat down with Pace’s CEO and co-founder, Justin Dignelli, to cover some of the most frequently asked questions about PLG he gets from sellers.

It seems like you can’t open LinkedIn or Twitter without seeing something about product-led growth (PLG). Why do you think PLG has become such a hot topic?

The idea that you can scale customer acquisition and revenue without scaling headcount and cost is obviously very attractive, especially as the market for hiring great talent gets even more challenging. There is an incredible opportunity if you can unlock this motion.
There have also been enough notable success stories of companies growing rapidly through product-led growth that there’s clearly something to this concept. It’s not limited to a specific industry or type of SaaS, either. We’ve seen PLG success stories across segments: from cloud infrastructure (AWS, MongoDB, Twilio) to collaboration tooling (Calendly, Figma, monday.com), and marketing software (Hubspot, Wix).

‍

What do you think the biggest misconception about PLG is?

I think a lot of folks hear PLG and assume that means you can build a great product and not invest in go-to-market. That it’s a re-branding of “if you build it, they will come.” The reality is the most successful product-led companies invest significantly in marketing, sales, and customer success. The difference is that those functions are more specifically focused on driving in-product outcomes like adoption, retention, and growth.

‍

So if PLG is such a no-brainer, why isn’t every B2B SaaS company going product-led?

Well, some might argue that over time, they will. But at the moment, the reality is it’s not an easy transition to make for a whole lot of reasons.
First and foremost to succeed with PLG, companies have to have some degree of product-market fit. On top of that, the product has to be compatible with a low- or no-touch model. That is, can people realistically get to a point of value on their own?
Secondly, companies with existing sales-led go-to-market motions have a lot of organizational inertia. Getting sellers to go from a mindset of optimizing for large upfront dollar commitments to a mindset of consistently deepening usage doesn’t happen overnight.
Put another way, embarking on this transition introduces real execution risk across people, process, and technology.

‍

I think a lot of sellers and sales leaders are skeptical of PLG. Why do you think that is and is there any merit to their skepticism?

There’s absolutely reason to be skeptical of anyone suggesting that PLG means a world without sales. I remember feeling similarly at first. 
However, I think anyone who has spent time in a sales role knows that the process of buying B2B software isn’t always totally rational. At the end of the day, humans are making these decisions and that means they’re influenced by internal politics, other people’s perceptions and a whole list of other factors. Sellers are uniquely positioned to navigate those things in a way that software likely never will.
The other thing we see with sellers, though, is simply a reluctance to relinquish control over the sales cycle. In a hybrid GTM (where you have both sales and PLG), potential customers have the choice to work with sellers. That means sellers no longer get leverage by withholding access to the product or enterprise features. So, there’s the “old school” enterprise software sellers who have this really adversarial approach to selling and that’s totally out of step with what good selling looks like with PLG. 

‍

‍So what does good sales look like in a hybrid model?

As cliche as it sounds, sellers need to be adding value every time they interact with the customer. 
That could be through their expertise and enabling the customer to solve problems with the product but it could also be helping users prepare a business case for their boss or sharing data about how other customers are using the tool.
One of the hardest parts about making the transition to PLG is that you don’t always know where the most important moments to add value are. There’s a degree of trial and error that happens before you can codify these new motions into repeatable playbooks.

‍

How do you suggest teams go about that process of experimentation (without totally tanking their pipeline)?

One of the things I see over and over again is that sellers aren’t getting actionable insight into product usage. Product usage data is really one of the most valuable source of information about a customer that we have access to, but so often is hidden away in a tool that only engineering can use or is piped into dashboards that you feel like you need a degree in data science to decipher. 
Distilling the most important product insights for sellers was one of the biggest unlocks for us at MongoDB. It meant we could spend time with the customers who were actually likely to benefit from working with us and stop trying to chase down the ones who wouldn't.

‍

What do you actually mean when you say “product insights” though? There’s a ton of data out there. How do you know what’s going to be important for sales and what’s just noise?

It has to start and end with the customer journey. First, sellers need to know where someone is in their evaluation and adoption process. Then they need to know what type of engagement will help the customer get to the next step. But if you haven’t taken the time to map out what your customers are actually experiencing when they buy from you, then what’s the point? It’s just a science experiment.
Let me give you an example. At MongoDB, in the early days of our PLG product, Atlas, we spent a lot of time on customers who didn’t really need our help. However, once in a while, we’d catch someone in the process of migrating really mission-critical applications over to Atlas. In those scenarios, they really leaned on me and my team to ensure that the migration was successful. Maybe that was helping them calculate the size of the infrastructure they needed or ensuring they had set up their security controls correctly.

It turned out that these “high risk” projects were the most lucrative for my team to focus on. Risk is obviously not something you can measure directly but we started to look at product metrics like data size, the types of instances they were exploring, the query patterns to create a proxy for risk. This became our mechanism for prioritizing which accounts we spent time with and which we left to self serve.