I really like the job applications where you answer a couple relevant questions instead of having to write a cover letter. It seems more efficient for both sides of the equation. Anyway, one of the applications I filled out asked “What’s your spiciest product marketing opinion?”.
What a great question.
I answered:
Product-led growth is important, but it can’t be the whole product marketing plan. Some differentiating features don’t work or can’t be shown in a freemium model. And in an economy that prizes efficiency over expansion, counting on developers to have time to noodle around with experiments may not be sustainable.
I’ve talked about this a bit in Team-led Growth, but it’s more than that.
PLG works well
Here are some things that make PLG products work well.
Learned by analogy
Product-led growth is great for things that are related to something your user already knows about, at least conceptually. Dropbox is like your hard drive, but in the cloud. Amazon is like a catalog. Slack is a BBS. AWS is like a datacenter. So often, people find software because they want “something like Photoshop, but less expensive” or “a way to keep my notes on all my devices”. That’s great, but they have a well-defined need or an exemplar.
PLG still works for novel things, but you have to make people ask the questions that drive them to look for answers. More on that in a bit.
Immediately rewarding
Most of us are unconsciously efficient with our time. Or as our teachers phrased it, “lazy”. If we don’t see why we’re doing something, if it’s not rewarding, if there’s no reason to keep doing it or punishment for stopping… we don’t. We stop doing our PT when we stop hurting, and we don’t walk around our cars to inspect them every time before we start driving like our driver’s ed teachers taught us. We wander away from books if they feel like a slog.
This absolutely applies to software discovery. If I have to do 30 minutes of setup to even get to “hello, world” or making a shared grocery list, my incentive or pain has to be pretty strong. For software that we know we have to use, we can do it. If someone tell you that your tech stack has to have a web server in it before you can start work, you just get it done. But if you have to install and configure a database, set up a webserver, and reset some jumpers to get to the fun parts, many people are not going to bother. Sadly, some products need all that to be done, and you may not be able to shortcut it.
PLG struggles
But not everything lends itself to pure PLG. Here are some software attributes that make PLG harder.
Actually complex
So many of the product-led growth stories we hear about are companies that have done an excellent job of eliminating or abstracting the complexity of using them. You don’t have to know what POP servers or SMTP is to use Gmail. But some software is actually complicated and you can’t elide it. Heavens knows, we’ve been trying to make git more usable and accessible(1) for two decades, and it’s still a significant barrier to entry for a lot of people. It’s just complicated. Managing access for large groups of people is complicated. Traces are complicated. You have to connect a lot of things to start getting any value. Frequently this also means that you need to work with other people in other parts of the organization, and so coordination becomes an issue.
For different people
Lots of people do not find working out puzzles and exploration rewarding. Or they may, but not at work. We all have different things we want to spend our exploration energy on. For example, as a kid, I loathed those grid-logic puzzles where Sheila was taller than Colleen, but everyone with red hair ….. I don’t know, that’s about where I noped out, every time. I have discovered that there are adults who do those for fun. Truly, the world is filled with a variety of people. On the other hand, I have spent several hours in the last week trying to get the last of my Kindle books archived properly, including replacing the battery on an older Kindle reader.
When we assume that product-led growth will work for, say, a developer tool, we’re assuming that the target developer has a similar problem to the one we imagined, that they have time to research solutions, and that this is the kind of puzzle they enjoy, or at least will do for work, but is slightly less fun than building it themselves.
Needs teaching, or standardization
You can’t explain everything about how to use a product with tooltips.
You can’t even put it all into documentation.
Sometimes, the way a product works needs to be demonstrated, in a way specific to the people using it. The bigger an organization is, the more important it is that everyone uses the tool in roughly the same way. If you’ve ever looked at an internal portal site with inconsistent pages, you know what I’m talking about. Product-led growth stops with adoption, and doesn’t do the essential work of optimization.
Novel products are hard to sell
It’s hard to sell something totally new. Buyers don’t have a comparison point, and their life is not built for it. The infrastructure to support it doesn’t exist, and early adopters take on a lot more effort than they get reward. Electric lighting started as arc lighting, which is miserable to live with. It took the development of better generation and transmission to make it something you’d want in your house. Before that, it was special-purpose, and honestly, oil lamps or gas lighting was much cheaper and more comfortable. Why switch to something unknown and probably worse?
To take a newer analogy, do you use IPv6? It was proposed in 1998, and officially adopted in 2017. Technically, we’re all out of IPv4 addresses. But we have come up with a lot of workarounds to avoid changing our IP address habits and tools.
Category creation is the fancy marketing way of saying “I know about a problem you have that you don’t realize is fixable, let me show you.”.
When we did category creation for “feature management” at LaunchDarkly, people had a lot of the parts they needed, but there was no good way to stick them together. Targeting delivery, controlling code paths, seeing user response, observability, automated rollbacks… there’s a bunch of things that existed, but there hadn’t been a good reliable way to stick them together and make them accessible to the people making product decisions.
We had to get people to realize they had a problem, that there was a solution, and only then were they ready for the free trial. And during and after the free trial, we still needed to do education around what kinds of features you could control, and how, and how to see the results. It’s relatively easy to put up a freemium offering, but that’s a tiny portion of the marketing that needs to happen for a product to actually work well enough for people to use and recommend it
So that’s my spicy take. PLG is good, but not sufficient, and how effective it is depends on your product, how it’s used, and whether people know they want it.
1: I worked on this project https://www.fujoweb.dev/, which is cute and hilarious, but would not need to exist if everything was simple.