PLG is an oasis, not a mirage: making a case for product-led growth in cybersecurity
Musings about product-led growth in cybersecurity: what it is, what it is affected by, and what it can become.
Welcome to Venture in Security! Before we begin, do me a favor and make sure you hit the “Subscribe” button. Subscriptions let me know that you care and keep me motivated to write more. Thanks folks!
Thanks for supporting Venture in Security!
Earlier this week, I came across a Medium article by the co-founder of ShiftLeft Manish Gupta arguing that PLG in cybersecurity does not work; the article is titled “PLG in Cyber Security is a mirage”.
Rather than getting into an argument in the comments, I wanted to put a few thoughts together to better explain my point of view. That’s how this article came about; I am going to argue that there is, indeed, a strong case for product-led growth in cybersecurity. In other words, “PLG is an oasis, not a mirage”.
Before I go into details, for those new to the topic or looking for a deeper dive, here are some links to articles about PLG in cybersecurity I have published to date:
Shortening Time to Value for PLG cybersecurity startups: a founder’s guide
First principles thinking and how the PLG approach can help solve the talent shortage in cybersecurity
I intend for this article to be complementary, not to repeat what I have already said elsewhere. But, I will be using links to some previous writing as well.
Cybersecurity is a broad industry
Before talking about PLG, I would like to point out that cybersecurity is a large industry with an ever-growing number of sub-segments and product categories, not to mention vendors. For that reason, I am confident that we can find (or will soon be able to find) examples of pretty much anything working for someone in the field. In this post, I am going to argue that PLG, if done thoughtfully, is a mindset and a go-to-market strategy that can be adopted by a broad variety of market sub-segments. I will also be taking a deeper look at the variety of use cases, user & buyer personas, and industry segments.
With that out of the way, let’s talk about PLG.
How I think about PLG
When some people think of PLG, they often picture a “100% self-serve experience when an entry-level employee from a Fortune 100 company signs up today, deploys the product across the whole company tomorrow, and starts paying a multi-million dollar bill using their personal credit card”. That is not what I have in mind when I think about PLG.
I see PLG being about offering product experiences that people will love and will be compelled to pay for. It is about continuous customer discovery, shortening time to value, and focusing on providing value. It is about building a community of champions around the product and the company’s mission. I think that companies that don’t embrace PLG essentially say they don’t care about the user experience; this is no way to build a business.
To me, PLG is not about having a free tier, or a 60-day free trial. These are specific implementation decisions that may or may not be the right choice for a given company at a given time in a given market.
PLG is a journey of continuous learning and continuous learning. As you start on this journey, you will have many assumptions and hypotheses and little knowledge; at that stage, driving people to talk to sales is appropriate — it does not make you “anti-PLG”. What matters is your approach and intent: are you trying to learn as much as possible, disprove as many hypotheses as you can, and iterate on the product to get as many people as you can into a fully self-serve experience? If so, you can get to PLG. If, on the other hand, you are looking to keep the “talk to sales” wall and grow the sales team linearly as the demand grows without opening up the product — you will get a very different outcome. It’s not the starting point, it’s what you optimize for that matters over the long term.
A prerequisite for successful PLG implementation is a deep knowledge of the customer, their pain points, mindset, jobs to be done, factors impacting decision-making and product adoption, and others. Only when a company truly understands its customers, can it design a product that customers would love. This is especially critical for companies looking to become fully self-serve. It is not enough to build a product where people can sign up themselves. You have to continue learning and working iteratively through each step of the customer journey to eliminate anything that prevents or has the potential to prevent them from using your product.
PLG is not a substitute for sales; it is a mindset and a way to structure an organization where product, marketing & sales are all aligned about the common goal — providing a great experience, and using product as a vehicle to achieve this.
Factors influencing the probability of PLG success across industry segments
There are a large number of factors influencing the probability that PLG adoption in a given segment of cybersecurity can be successful. Here, I will go over a few that, in my opinion, are the most relevant.
The ability to measure value
I have written about this one at length before; this section is largely a summary of that. For product-led growth to work, a person needs to be able to understand the value they receive from the product and experience this value as quickly as possible.
We can put all security products into two broad buckets:
Products that are intended to solve a broad problem of “keeping one safe”. It is very hard to realize the value of products that fall into this category as you never know if you haven’t been breached because nobody tried, or because the product is quietly doing its job. Therefore, they are generally sold, not bought. They are not the best candidates for the PLG although fear-based purchasing can drive adoption in the short term. Examples include AI-powered security platforms.
Products that are intended to solve a smaller, well-defined problem (i.e., “allow people to do X”). They have a clearer value proposition and therefore, they are often more suitable for the PLG as they tackle smaller use cases that are easier to evaluate such as password managers, security posture testing, breach simulation, and security automation tools.
In most cases, it’s not a clear demarcation and most products are located on a continuum between these two. The more “tangible” the value is, the easier it is to expose it and therefore the easier it is to take the PLG path.
Keys to success:
Ensure products in your market are suitable for PLG
Ensure that you can clearly communicate value
The role of the trust factor in getting to value
What makes cybersecurity somewhat unique is the chicken or egg problem as it relates to trying the product. To see the product value, users generally need to take a step that requires a high level of trust (connect their data, deploy the product on their network, etc.). At the same time, to compel people to move forward and build trust, the value of the product must be apparent even before they take this step. This is a tough problem to tackle.
As with other factors, the degree to which different products are affected by this problem will vary. For some products, very little is required to test how the product works (say, password managers). For others, like code security platforms, the initial investment is high.
Cybersecurity heavily relies on trust, more so than other industries. It’s rare (if at all possible) for the company to adopt the product without a heavy due diligence process and proof of concept (POC). The good news is that PLG can make POCs largely low- or no effort.
Keys to success:
Eliminate the hurdles preventing people from trying your product. Ideally — avoid them at all (add demo content/data, etc); if not possible, look for ways to reduce cognitive load by offering guarantees, meeting compliance requirements, and similar.
Leverage social proof and build trust in the community by being responsive, showing integrity, and doing what is right
User & buyer readiness to experience the PLG approach
User & buyer readiness to experience the PLG approach varies depending on the persona. Readiness comes from familiarity, so naturally, some user personas are more ready for PLG than others. Think, for example, about security engineers with experience in open source & developer tools versus compliance professionals. This disparity is both intuitive and expected.
What is less obvious is that markets did not magically get into the place of maturity. It’s a process, an evolution in its own right. Developers didn’t always have the power to buy their own tools — it became possible when there were enough vendors in the industry offering them, and enough engineers who were looking for different ways to do it. Cybersecurity is a young discipline, and, naturally, the purchasing power of individual security professionals today might not be as high as in software engineering. But, as security is maturing, getting better defined as a profession and more specialized, the purchasing power of practitioners will grow. We are seeing more and more security engineers being empowered to recommend the tools they have tested in their home labs, and that trend is likely to accelerate.
I have a strong conviction that the times when CISOs would spend XX% of their time evaluating vendors are nearing an end, and more and more tools will be brought into the organization from the bottom-up. This is simply because it is not sustainable for security leaders to spend so much time with vendors when they have more strategic problems to take care of, and because with the growing specialization in security, no one person can be great at everything. While CISOs will remain final approvers, they will not necessarily be the ones doing the initial product screening & vendor evaluation, creating an opportunity for PLG companies to shine.
Keys to success:
Be there early for those who aren’t 100% PLG ready today, which can enable you to build trust and community around your product when nobody else is doing it. Markets with high PLG maturity were once where cybersecurity is today; it takes time for people to gain purchasing power and gain a voice in the buying process.
Build sales enablement materials for users with low buying power but high enthusiasm about your solutions so they can be armed to get the buy-in decision-makers internally. Have your sales team readily available when a user of your product is bringing their leader on the call so you can convince them to go ahead with the purchase.
Keep in mind that SMBs are generally more willing and ready to take the PLG approach compared to enterprise customers. They are more flexible and more willing to use their credit card & upgrade self-serve compared to large enterprises that are used to contract and pricing negotiations. Even if you are a PLG startup, be ready to talk pricing with enterprises as they are unlikely going to be willing to pay what you have on your website.
Number of parties involved in purchasing decisions
In his article, Manish talks about the fact that there are multiple parties commonly involved in buying decisions. That is true, and interestingly, it is not unique to cybersecurity. Think about cloud providers, developer tools, feature flag managers, incident management tools, and others — it is common to have multiple functions evaluating the product during its purchase. In most cases, however, there is one function that acts as a sponsor, or a champion, of a proposed solution. Cybersecurity is not an exception but yet another example of a rule.
Keys to success:
Develop strong customer discovery habits to make sure you have a clear understanding of who is involved in the buying process, in what way, what their needs and pain points are, and be ready to address them.
Build sales enablement materials that the sponsor (or a champion) can use to get other functions on board with a new solution. Have your sales team readily available when the sponsor is bringing people from other functions on the call so you can address their concerns and convince them to go ahead with the purchase.
Level of competitive pressure
I would argue that the more competitive the market segment is, the more likely it is that a company will not be able to survive by betting on self-service alone.
In general, cybersecurity is an incredibly crowded space with some segments being in a better place than others. Companies embracing the PLG approach cannot afford to sit and wait until people realize the value and convert on their own. That should be the end goal, but the reality of building the business is that PLG startups in security have to keep moving forward; combining PLG with product-led enterprise sales is a key to success.
Keys to success:
Combine PLG with product-led enterprise sales
Ensure that product, sales & marketing are all working in alignment
Let’s have a quick look at open source in cybersecurity
PLG in cybersecurity has a great uncle — open-source tools. Open-source in security is living proof that security professionals do appreciate the transparency, the ease of getting started on their own, and the ability to start small and scale their deployment as needed. Even though many open-source tools do not offer a short time to value and require manual configurations and fine-tuning before they can be used, this has rarely been an obstacle that prevented adoption. If a tool solves a real problem for enough people, it has a great potential to be successful.
From digital forensics to automation, threat intelligence, network, and endpoint security, we see successful open source tools in different segments of the market. Security professionals of all types — security engineers, architects, detection engineers, threat intelligence engineers, security analysts, SOC managers, and others bring open-source tools to their organizations, advocate for their adoption (despite all compliance challenges), and use them when appropriate.
Open-source tools that have been successful, tend to solve measurable security problems (as opposed to the broad task of “keeping one secure”). They generally target engineers and technical security professionals looking for effective, transparent, and affordable tools to solve their problems. This aligns with the observations about factors impacting PLG adoption summarized above.
If open-source is a thing in cybersecurity, so can be product-led growth, as both rely on building great products to address real customer pain points, and leveraging product as a vehicle to grow.
PLG is not a substitute for business fundamentals
While PLG can make a difference for a company in cybersecurity, it is by no means a substitute for business fundamentals. In other words,
There need to be a problem (a pain point) people experience
People experiencing the problem should realize that they have a problem, have intent and urgency to solve it, and be willing to pay for a solution
The company should have the necessary capabilities to solve the customer’s problem in such a way that allows it to capture value
There needs to be a market, a demand for whatever solution the company is proposing. Now, this does not mean that the exact product category the company is competing in needs to exist. It is possible (and often advantageous although also hard) to be a category creator. However, one cannot create a category if there is no problem.
If the problem does exist, but the customer does not know about it, the company will need to invest resources to expose the problem in such a way that makes it apparent and raises the level of urgency driving people to explore available solutions. Companies attempting to define a new market segment, need to evangelize about the problem; if people “get it”, their solution has a great chance to become a leader in the new category.
What will most certainly not work is building the product that solves no problem, or solves a problem the customer is not aware exists or solves a problem that does not need to be solved immediately, and waiting until people discover the solution. This isn’t about PLG; this is about business and common sense. “Build it and they will come” is not PLG, it’s bad product management.
PLG is an oasis, not a mirage (and not an ocean)
PLG is not a mirage and neither is it an ocean. Around an oasis, you can build a nice town, but you cannot build a megaregion; for that, you will need an ocean or at least a large river. Product-led growth has its well-known limitations, so companies thinking about PLG need to have reasonable expectations.
“While a bottoms-up strategy is instrumental for initial traction, many companies ultimately need to layer in top-down sales in order to reach $1 billion ARR by leveraging enterprise adoption.”
Source: Bessemer Venture Partners. Introducing enterprise sales to a product-led growth organization.
In other words, PLG is not a substitute for sales, nor should it be. Companies attempting to get rid of sales because they are “going PLG” misunderstand what product-led growth is, to begin with. I am glad to see more and more content about product-led sales — “a customer-centric method of reducing friction in the sales cycle” as defined by Anna Talerico.
Product-led growth, when combined with enterprise sales, makes it easier for people to fall in love with the product and to start paying for it, subsequently making it easy for sales to sell it.
PLG today reminds me of the early days of Agile
If you have worked in tech long enough, you will probably remember the time when Agile was considered to be something new & life-changing. Even as recently as a five-seven years ago, it wasn’t uncommon to hear presentations about the importance of delivering value early and often, taking an iterative approach, and giving teams autonomy and ownership to solve hard problems.
As the adoption of Agile grew, we saw growth of training providers who started mass producing Scrum Masters and Product Owners all around (it would only take a day or two to get “Scrum/Kanban/Agile certified”). Enterprises looking for “Agile transformation” would then hire these “certified” professionals and see them “take the company Agile” which in practical terms often meant taking a framework and applying it with little thought process, renaming engineering managers to Scrum Masters, and scheduling daily standups. We’ve seen lots of that.
In many other industries, you would hear that “Agile is not for us because you can’t do weekly releases when you are in banking/insurance/health tech” (or hundreds of other industries for that matter). It felt as if incremental value delivery “can only work for someone else, but not for X”.
Very few understood what the Agile manifesto was all about — the mindset. Very few truly internalized its values, and even fewer were able to implement them. In 2022, decades later, you won’t even hear the word “Agile”. It’s just how the software is built. All companies needed five-year roadmaps and detailed long-term project plans for building software applications until they didn’t. Today, many of these “not for us” businesses are doing a great job delivering value incrementally and iteratively in a way they never thought was possible.
Many changes in the industry go through a similar process, and PLG is unlikely to be an exception. Someone tried a new thing, and it worked. Someone else put together a great deal of evidence that PLG can benefit the company and enable it to grow exponentially while simultaneously reducing the cost of revenue. Educational providers will create courses and certificates for PLG; a quick google search shows there are at least three out there already — ProductLed, Product-Led Growth Core Certificate™, and Product-Led Growth Micro-Certification (PLGC)™. Some people with little understanding of product management will get “certified”, while some sales-led companies choosing to “go PLG” will start hiring “PLG certified” professionals with plans to change a little. We will see more products offering free trials & a free tier, and thinking that it makes them product-led. We have seen that before with Agile, and lots of other stuff. But despite the BS, the train is moving, and we’re not going back.
It’s all too easy to say that “PLG does not work for cybersecurity”, as Agile “did not work” for banking. It’s common for people in any industry to think that they are unique and unlike others, and in most cases that is true. Having worked across multiple different markets, I’ll not argue that there are no differences. But I am yet to meet people in any market who will say “I wish I spent more time negotiating pricing”, “ I wish I had to attend more demos before I can access this product”, “I wish I was charged for features I don’t use”, “I wish I had to sign a multi-year contract” and so on.
Arguing against PLG in 2022 is like trying to turn the time backward and demanding that we “stop releasing so often and go back to doing it once a quarter”. That ship has sailed.
I don’t know how long it will take for PLG to become widely adopted in cybersecurity. What I am fairly confident of is that customer expectations are changing, and people in B2B are increasingly looking for B2C experiences. When it only takes us 15 minutes to create an account and get food delivered to your door, it’s hard to wait six weeks to get access to a security product to see if it does what it claims to be doing. PLG is not a prescriptive methodology, and it will most definitely find its way into cybersecurity even though it has some unique characteristics such as strong reliance on trust, the need to get approvals and signoff before any data that makes the product useful can be shared, or before a tool can be deployed in the company, to name a few.
As a general rule, the closer you are to the technical professionals (software and security engineers), the more tangible & measurable problems you are solving, the more you are targeting SMBs, and the more likely you are to succeed with the PLG approach out of the box. If you are looking to target enterprises, engage less technical security professionals, or sell the warm and fuzzy “sense of security”, it may require more effort.
If I were to place bets, I would imagine a world where 20 years from now, people can try products before purchasing them, get started for free, and pay only for what they use. I don’t think we will hear anything about PLG; it will be simply how things are done.
The future of cybersecurity will be people-focused and product-led. Why would we build it any other way?