PLG is not always the answer

PLG or product-led growth has become the status quo in SaaS companies. The general premise is that the product itself helps acquire and convert users to paying customers, thus reducing the reliance on sales teams. Following this train of thought, it is often true that the easier a product is to set up and get going for the first time, the more successful it will be.

But there are a class of dev tools and infra startups that don't always benefit from following this rule at the very beginning and this comes down to a few things.

What type of problem is your company solving?

There are big and hairy problems deep in the tech stack that aren't well-known or well-defined. These champagne problems usually show up when you're operating at a large scale -- think the FAANGs of the world.

If you are a startup building a product that solves these types of issues, then the initial difficulty of getting the product up and running is not a deterrent for these sophisticated engineers and companies. Investing a ton of engineering effort into making the initial installation process easier might not be worth it during the early stages of the company, given the initial set of users.

Assuming your product delivers real value, this set of users gets an almost perverse sense of pleasure from that steep learning curve. As a concrete example, self-hosting Cadence and Temporal servers for production workloads is a challenging endeavor, however users who see the value manage to do it and then inevitably become champions for the product.

What is your distribution model?

One of the huge benefits of being open-source is that users can try your product out for free without all the bells and whistles. At minimum, it should be easy to run your software locally. OSS is basically the OG PLG -- although yes, it can be difficult to figure out who these users are to convert them into paying customers. I wouldn't stress too much about having the commercial product being very PLG-friendly early on if you have an OSS version that's easy to use.

If your commercial product is the only point of entry, I might think a bit harder about delaying the PLG motion. Yes, sales can still walk users through signup and onboarding, but it would really only work if your product is solving a very critical and urgent business need for a significant set of users.

What is your revenue distribution?

It's pretty typical I think for most dev tools startups to follow a rough 80-20 rule where 20% of customers generate 80% of revenue. These whales are not deterred by a challenging onboarding experience, so depending on your GTM strategy, it might make sense not to prioritize smoothing this out in the early years of your product.

It is tempting to put off hiring a sales team and instead optimize for the self-serve experience to get as many users as possible into your product. But the reality is do you really want to run your service at a loss for the 80% of users who contribute very little to your ARR in this economic climate?

I'd argue that it's better to have a small sales team walking larger customers through setting up an account and onboarding.

How much time and energy are you spending on day zero vs day one and day two experiences within your product?

Initial buzz and getting users in the door does not mean they will stick around and pay for said product. On further investigation, I've found that a lot of these products fall flat when it comes to day one and two operations because they only optimized for day zero. Users who rely on these products for mission-critical workloads will churn once they realize they're shit out of luck when they have to deploy a change or need advanced metrics or need to deal with an outage.

If your product has early traction despite having rough edges during onboarding, it might be wiser to prioritize making the core service better and coming back to the onboarding experience when your GTM moves lower down the funnel to a broader set of customers.

Who is your customer? What is your ideal customer profile (ICP)?

I saw the opposite end of the spectrum when I was at VMware building Tanzu, which involved installing a Kubernetes control plane into the hypervisor. Getting Tanzu installed onto your servers was a huge pain -- and guess what, our customers (much love to them) were not FAANGs! They were the non-tech native Fortune 500 companies of the world and they could barely make it past the day zero experience of the product.

In this case, it made sense to invest in engineering improvement to simplify onboarding given the customer base.

In conclusion, PLG is absolutely necessary once your company reaches a certain size and scale. You're going to have to go down-market at some point. The point I'm trying to make is that starting with PLG as the default is not right for every company.

Tl;dr

• Define your ideal customer profile (ICP) and the category of problems you are solving

• Optimize your product experience for that ICP

• Don't assume that smooth onboarding is a panacea to all user concerns

• Watch what competitors are doing but don't blindly follow them. Your ICP strategies could be entirely different