PLG Resources and Wrap-Up

I put blog ideas into a to-write folder which contains more than 300 files full of brain dumps, outlines, and rants, all in various forms of disrepair. It’s my process. In that folder, there are 21 posts with PLG (product-led growth) in the draft copy and 5 with PLG in the title. It’s a topic I’ve always been interested in, but two things have prevented me from attempting a seminal post on PLG.

  • There is so much great work out there already. Every time I start to write, I hear stand on the shoulders of giants ring through my head followed by, “Dave, stop. Stop, will you? Stop Dave.”
  • I still consider myself more student than master. I grew up in enterprise. I have experience with market-seeding strategies and open source. I work with some velocity SaaS businesses. I’ve debated founders and boards on how enterprise companies should think about a PLG motion. But I’ve never run a PLG company and I’ve never worked in-depth on a PLG process.

Thus the drafts remain unfinished. But after having learned a fair bit, met many interesting people, located some great resources, and developed some strong opinions, I didn’t want to just drop everything. So I decided to write this summary report to provide links to PLG resources and share a few PLG thoughts before moving on.

PLG Resources

Thoughts and Opinions

Here are some opinions forged by my PLG research and conversations.

  • Don’t do PLG just because a board member wants you to. Try introducing a PLG product or motion if and only if you (as CEO) want to. While we are past peak-hype on PLG, there can still be a lot of pressure to try it because everyone else is doing it. Resist.
  • Try PLG if you think it can help your business. There is a lot to learn from PLG companies so I don’t recommend resistance for its own sake. But, if you weren’t born PLG, the odds your enterprise product will be ready overnight for a PLG motion are low, so keep expectations in check. Here’s a great post to help you get started on the journey. Alternatively, you could run PLG motion on a teaser product to pull people into your overall offering (e.g., Clearbit’s de-anonymization can lead to a later purchase of enrichment, Moz’s online presence can lead to a later purchase of its SEO).
  • I like growth teams. In general, I like silo-busting where you take groups of experts in different functions and aim them at a business goal. ABM does this, uniting sales, marketing, and SDRs in the quest to crack target accounts. Pods do this, uniting different sales and marketing functions, typically within a geography or vertical. Growth teams do this, uniting product managers, designers, marketers, sellers, and analytics team members on maximizing PLG conversion rates. They’re a good idea.
  • The product doesn’t sell itself. Knowing how expensive sales and marketing people can be — with S&M expenses typically running at twice R&D in a typical software company — I think for some people the PLG dream was to elminate S&M with a product that sold itself. That didn’t happen. In PLG, most of the time, the product helps sell itself. That’s certainly a lot better than not helping (I’ve seen that too), but we’ll still need those pesky sellers and marketers after all. See the McKinsey paper.
  • PLG ain’t cheaper. While a few PLG companies end up ahead on the S&M vs. R&D expense trade-off, most end up spending more on both. See the Tunguz post or the McKinsey paper. Don’t do PLG to save money. Do it because you think you’ll have a better product, grow faster, take market share, and build leadership. PLG is not a cost-cutting strategy.
  • PLG still needs marketing. How do you think we get people to do all those trials anyway? Yes, you may have a viral product or a strong community (word of mouth), but you’ll still also rely on marketing to drive people to your trial via SEO, SEM, and making TRY-IT the primary call-to-action on your website. (This always makes me think of Boston with the anaphoric “listen to the record” on the back cover of their debut album.)
  • If you’re starting a new company, try to be born PLG. For example, were I to start a new EPM company, I’d try hard to build a PLG motion in from day one. That’s not particularly easy in a space with separate buyers and end-users (where end-users need to be connected to the corporate system), but I’d sure try. You’ll likely end up with a better product as a result. Or a teaser product linked to a core one.
  • PLG is another pipeline source. Traditionally we’ve had four pipeline sources (marketing/inbound, partners, sales/outbound, SDR/outbound). When do you PLG, you’re not only adding any direct revenue, you’re also adding a pipeline source (with its own vernacular, e.g., PQLs) much as ABM adds a pipeline source (with its own vernacular, e.g., MQAs).

One response to “PLG Resources and Wrap-Up

  1. My observation are that PLG is best suited (I would say only suited but suspect there will be some examples where that’s not the case) for collaboration products where there is incremental value from more people using it. Slack, LinkedIn, Jira, etc. Also the product has to be super-simple to use. When a product can be used by a small group of people without an Enterprise standard being required – good luck using a workplace scheduling system if we’re not both in agreement as to which we’re using, or getting accurate forecasts if we’re using 3 differently configured SFA solutions. If you were selling an FP&A solution, and I started using it I would likely need training, interpretation of inputs and outputs, and my ability to share a model I created with you would be limited even if you used the same tool if you didn’t have the same training. As you say your experience is with Enterprise products, as is mine, but we would call Slack and Jira Enterprise products, however, you and I could use them to perform work and they would work just fine, there is just incremental benefit if more people use them.

    I used to have long debates with a friend who worked at a PLG company about the value of sales teams, and I fully agree with you there was a reasonable amount of glossing over the marketing spend, people with roles that looked like salespeople and smelled like salespeople but went by other names, and one thing neither of us could prove would be what results they could have got with an Enterprise sales team. I maintained larger ASPs, bigger initial contracts, faster deployments. I acknowledge I would say that, but bias doesn’t mean you’re wrong, it just means you’re biased, you can be biased and right.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.