PLG is not a boolean: practical advice for cybersecurity startups looking to embrace product-led growth
Helping founders think about implementing PLG without blithe excitement
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!
Two weeks ago, I had a Q&A session about product-led growth with alumni of CyRise cybersecurity accelerator - an investor, supporter, and champion of cybersecurity startups in the Asia-Pacific. We discussed practical steps companies in the industry can take as they consider or actively move toward product-led growth. In this piece, I will summarize some of the learnings I had the pleasure to share with the founders. Unlike many of my other articles, this one is less about “why PLG works” and more about “how to think about doing it”; it will be less structured and may read more like notes than a story. I would like to emphasize that this is not a list of “best practices”, rather a set of mental models any cybersecurity startup founder can find useful as they think about embracing PLG for their startups.
Before we dive in, here are some thoughts to keep in mind as we look at implementing PLG in cybersecurity.
Basics of PLG in cybersecurity
Product-led growth is one of the most commonly misunderstood concepts in cybersecurity. I have tried making it clearer and more accessible by working with founders, speaking at podcasts, and writing articles that include the following:
PLG is an oasis, not a mirage: making a case for product-led growth in cybersecurity
To bring PLG to cybersecurity, let’s change our hiring habits
4 ways cybersecurity startups can boost adoption and shorten time to value
I see a lot of evidence that there is a place for PLG in cybersecurity. But, it’s important to understand that there are also nuances and limitations to the forms it can take.
The purchasing process in cybersecurity is heavily based on trust. This means that:
Individual contributors can recommend security products but cannot get them adopted without the senior leadership signoff because of the high levels of risk.
Companies evaluating security tooling offered by a startup will most definitely have questions, are likely to request documents like SOC2 compliance evaluation, and will want to meet someone from the leadership team to gain confidence in the company's future. Implementing cybersecurity products is costly, and while PLG promotes the idea that a customer would "sign up in a self-serve manner, add their credit card and start paying", any serious security team will want to have confidence that your product will not disappear three months after the rollout.
Making it easy for customers to evaluate the product without having to connect it to sensitive production data can make a huge difference in adoption. Optimizing onboarding for PLG cybersecurity startups is much more than reducing the number of clicks and screens. It is about providing demo content, making technical documentation readily available, and having a customer support team to answer any questions that will most definitely arise.
Many cybersecurity products, including those built for defense, can be leveraged by malicious actors for the offense. I have previously discussed a similar conundrum in the context of open source (the two debates about open sourcing offensive & defensive tooling), and it can be even more complicated for commercial tooling. Vendors are responsible to make sure their products are not giving the threat actors who aren’t known to abide by terms and conditions, an easy way to break into the victim’s environment.
These factors make PLG, and the whole product management discipline in cybersecurity to take a somewhat unique shape.
Practical advice to cybersecurity startups looking to embrace product-led growth
If you are a sales-led startup targeting enterprise companies and thinking about embracing PLG, my advice would be to tread lightly. Instead of getting all of your pricing on the website and opening the product to free signups, understand that being product-led is not the same as having a free tier or a freemium model. PLG is a journey to build great products. This journey starts with the understanding of the customer.
Learn about your customers
“You should start by learning about your customers” sounds so obvious and basic that it is incredibly easy to brush it off, and that is exactly what many founders do. I would argue that this problem is especially pronounced in cybersecurity where startup founders typically have deep domain expertise and experience. When you have been doing security for a decade and someone suggests that you should “learn about your customers and their needs”, it is easy to wrongly take it as a dismissal of one’s expertise. “Of course, I know what the problems are - I have seen them first hand when I was a practitioner”, says the founder and marches on to build a product that is likely never going to be used.
Every company does security differently, and it is not always easy to gauge to what degree a certain use case is widespread enough to warrant a need for a new product. Even if it is - the way a large enterprise would want a problem to be solved may be different from a small startup, and the way a hospital wants it done may be vastly different from a cloud-native tech company. How people buy products will also be different if you are offering threat intelligence vs software security posture management or a web firewall.
Since there is no such thing as “how to do X in cybersecurity”, you have to become an expert on your customers. A great source I recommend for all founders (especially those with technical backgrounds) is The Mom Test: How to Talk to Customers & Learn If Your Business Is a Good Idea When Everyone Is Lying to You by Rob Fitzpatrick. This book offers practical advice about running effective customer interviews that result in deep, actionable learnings instead of a collection of biased responses to make founders feel good about their idea.
Understand if your product is suitable for PLG
Cybersecurity products suitable for product-led growth tend to have two characteristics in common:
they are well-defined, easy to understand, test, and prove the value proposition
it takes a short time for users to realize the value of the product once they created an account
These criteria highlight that not every cybersecurity startup can be product-led (although, arguably, all could benefit from implementing some elements of the PLG). Let’s take a password manager as an example. It is easy to understand what it does and easy for a user to compare the “before” and “after” of using the product: “My passwords were all over the place, and it would take ~20 minutes a week to access accounts I have forgotten credentials for. Now it only takes seconds to securely login into any site and sync my credentials across many devices”. The same is true for a security automation platform (time and effort savings can easily be quantified). On the other hand, a product that promises to keep the customer “safe” is very hard to evaluate as “safety” is a feeling, not an objective, empirically provable reality.
Some cybersecurity products are trying to “invent value" by adding charts and dashboards that are supposed to communicate that the tool is “working”, often showing the number of attacks they “stopped” and malicious software they “eliminated”. While that may be the right approach to show what the product does, this is not the same as demonstrating value. Value is something a customer cares about (and values). If a user does not deeply care about the specifics of what being “safe” means, or does not understand the significance of what the solution “stopped” or “prevented”, they are not likely to see the product as valuable. This is why the much-loved in the industry nice-looking charts and graphs cannot create value.
Crawl before you walk before you run
PLG is a journey so if you are a sales-led company considering becoming product-led, or an early-stage startup with lots of manual setups required behind the doors, do not rush to open self-signup and in-product upgrades. Instead of making big, irreversible decisions, start small and learn as you go.
Validate that self-serve experience would work for your product
Let’s assume your product today needs a manual, customer-specific configuration before it can be used, and you are not sure if people in your market would even be interested in self-signup. To test it, you could add a "sign up" call to action next to the “request a demo” button on your website, and see how many people are interested in each. If you are not ready to support the self-service right away, that’s Okay - your signup flow could have a few questions about the customer and the problems they are looking to solve and end with the confirmation that “a member of the team will get in touch for final setup steps”. Doing this can help your team learn about user needs, and whether or not these needs are painful enough to warrant a solution the customer is willing to pay for.
Start with a self-serve signup experience that requires manual approval
After you have validated that it does make sense to move further towards self-service and built a way to support it, you can release a version in which the user can register self-serve, but manual approval on your side is required before they can start using the product. If this sounds like it goes against the PLG approach, then it’s because we are used to seeing product-led growth as “all or nothing”, while it is not that. Product-led growth is a continuum, and it's okay to move methodically, step-by-step to implement it.
Self-serve in-product experience with a sales-guided upgrade path
You may now have enough evidence that a fully self-serve, ungated open signup experience is what you need to get people to try the product, but you are unsure about the pricing model. Great - you can now implement the fully self-serve signup and in-product experience, but have a “contact sales” button on the billing page inside the product. This way, the upgrade process will require engagement with sales, engineering, or product teams, allowing you to learn and iterate on your pricing. This will also enable you to offer different pricing to different customers if that's a path you want to pursue.
Fully self-serve experience
After learning more about your users, and developing a deep understanding of what makes them convert, you can now start designing the conversion triggers into the product and adding the self-serve upgrade and billing management functionality (assuming it makes sense for your use case).
Advantages of the step-by-step PLG implementation
Once again, this isn’t a recipe for implementing PLG, but rather how I encourage founders to think about finding the best way to make their startup product-led. By learning, iterating, pivoting, and reverting back as needed, startup founders can evolve from products that require manual intervention and support every step of the way to fully self-serve solutions or something in between that is more suitable in their market and to their specific customers.
The step-by-step approach also helps prevent some painful mistakes. For example, if your solution is very complex and has a steep learning curve, and you launch a new person into it with little context, you are much more likely to lose that user than if you were to do a demo beforehand. Some readers might think “how can I be product-led if I force everyone to attend a product demo?”. It’s a great question, one that highlights that PLG is a journey and a mindset: yes, you are asking them to attend a demo, but not because that’s how you want to sell your product. Instead, you need to continue learning and making your product easier to use so that after a few iterations, customers can succeed without any demos. Opening the product before it is ready for self-serve adoption and offering no help (demos, documentation, training materials, and hands-on support) is a path to increased churn and upset customers.
As you move towards self-serve adoption, make sure to collect information about your customers and their goals during the signup. I have previously written a guide about how to do it well, without turning the signup flow into a laundry list of questions someone on the team wanted to include because “it would be cool to know X”.
Remember that having a product open for anyone to sign up is not the same as being product-led. Make it easy to get started, understand the user’s journey, and help them succeed with your product. Whatever you do, stay focused on your customers and their needs.
Freemium vs Free Trial vs Open Source
PLG is not a prescriptive set of practices. The exact steps a company should take will depend on their understanding of the customer, their market, the kind of product they are building, and the way people in their market segment make purchasing decisions. Here are some thoughts and opinions taken out of context; your experience will vary.
If the company is targeting technical security professionals with experience using open source tools, then having an open source version of the product could be a way to go. This is especially the case for products that can benefit from community contributions.
If the solution does not require scale (say, the customer can get full value from one instance), or if it takes a short time to onboard, understand how the product works, and complete the evaluation, then a timed full-featured trial could be a good idea. Think of traditional “X-day trials”, and ensure that the length of time is sufficient for users to complete testing and make a preliminary buying decision.
If the full value of the product can only be realized at scale, and a customer looking to adopt the tool would need to deploy it across the whole enterprise (endpoints, containers, instances, repositories, etc.) or a variety of workflows, then having a free tier with limits to scale but no time restrictions could be a viable option. This way, you can provide an easy way for security professionals to set up the product in their home lab and learn how it works, but require the sales interaction for upgrades and deployments at scale.
These ideas are not prescriptive recommendations but rather examples of the thought process that a startup can go through when considering how to implement PLG.
The ability to try a product is not enough for adoption
I like Asana for managing my tasks. The difference between an Asana user who has a good experience (me) and an Asana user who brings it into their company (not me) lies in two factors: the presence of the business need, and Asana’s sales enablement effort.
If my company is not looking for a project management tool, it’s unlikely I will be able to get it to adopt Asana, no matter how great its sales enablement is. This is why the business need is a prerequisite for bottom-up adoption.
On the other hand, if my company needs a tool like Asana, and I am already a happy user of the software, it does not mean I will be able to bring it to my team. For that to happen, I would need to share some information with decision-makers, including what problem the tool solves, how it compares to other solutions on the market, and what makes Asana the best choice for the company. My personal experience alone, however great it may be, is not enough for the whole business to start using the product.
The same would be true for any cybersecurity startup attempting to implement PLG. While it is critical to ensure that users will experience the “AHA!” moment quickly, their testimonial alone won’t be enough to get their company to buy it. Understand how enterprises in your target market make buying decisions, what incentives are at play, whom you need to convince, and what arguments could work as you go about doing it. Sales enablement in cybersecurity is a must, and you have to be intentional about implementing it if you want to succeed with the bottom-up approach.
Money talk: going open with pricing
Another common mistake startups pursuing PLG do is making their pricing public before fully figuring out their go-to-market strategy and their margins.
There are many second-order consequences of making the pricing public that companies need to consider before they make that decision.
Public, fully transparent pricing shuts off the door for sales via channel partners. This can be a strategic decision, or if done unintentionally - a big mistake as being product-led and working with channel partners do not have to be mutually exclusive. A company can have a self-serve version for individual users or a tier tailored to SMBs with fully transparent pricing and limited functionality. On top of that, it can offer an enterprise-level product sold via channel partners with flexible and negotiable pricing.
Having the pricing open on the website can also make it very hard to work with resellers and managed service providers who may want to distribute your offering. If the end customer can buy your product directly through your website, and your pricing is transparent, they may have little incentive to go through a third party. Similar to the previous example, if this is done intentionally - great, but if not - the company may lose the ability to leverage an otherwise viable distribution channel.
When a startup that targets enterprises makes its pricing fully transparent, it sets an anchor for the negotiation. Enterprise customers will always work to go lower than the publicly listed price, asking for volume discounts, commitments, and guarantees. The procurement and finance teams have a mandate to reduce spending, and their performance is evaluated, among other metrics, on how far the final contract price is from the initial offer or listed price.
If the product pricing is complex and hard to understand, and tools to make sense of it (i.e., pricing calculators) are not provided, then listing the pricing openly can confuse people and drive them away.
If the startup has not yet figured out its profit margins, it may need to continue adjusting pricing as it learns more. People don’t like to see continuously changing prices - hence it may be a good idea to prevent confusion and avoid making pricing public until confidence levels are higher. There are some counterarguments to this as sometimes, especially at a very early stage, having pricing listed on the website can make it easier to test out the idea and understand the user's willingness to pay.
While there are many reasons to not make the pricing fully open, there are equally many reasons to do that. First of all, predictability can be a powerful differentiator in the industry that is tired of seeing “request a quote” and “request a demo” on every vendor’s website. Secondly, when security practitioners don’t have to spend hours going through the sales process just to understand how the startup’s pricing compares to that of competitors, it can make it easier for them to make a case about adopting the product. Lastly, having transparent pricing is important for companies that embrace the usage-based pricing model, as it enables customers and prospects to do the calculations necessary for budgeting.
There is more to pricing than transparency
There is more to pricing than transparency. In this part, I’d like to briefly touch on two important questions: monthly billing cycle and usage-based billing.
A monthly billing cycle is commonly seen as a default option for product-led companies. This makes intuitive sense: a user is expected to onboard in a self-serve manner, and start paying - often with a credit card. Usage-based billing, on the other hand, has disrupted the way components of the IT infrastructure are delivered (think of AWS, Google Cloud, and other cloud providers). While this way of billing is new to cybersecurity, I have a strong conviction it will shape the way security will be delivered in the future.
Both of these approaches can be a great fit for security startups, yet as everything else, they have downsides and trade-offs. First of all, they introduce uncertainty for the seller and make the revenue less predictable. Second, they raise the importance of customer retention as at any moment, the customer may stop paying, and they are under no obligation to continue using the product. While I think that philosophically, this is exactly how the future of software should look like, in real life early-stage startups need time to get their user experience in order, fix bugs, and find the product-market fit. It can be both very stressful and incredibly motivating to know that any of your customers can get frustrated with issues and stop paying as soon as tomorrow. Although long-term contracts do not eliminate this possibility, they make it somewhat less pressing.
The usage-based pricing may limit the potential upside and cause startups to charge less than they would if they were to sell a well-defined package. However, it can also help the company to limit the risk that customers’ usage will be well above what they paid for when signing the contract.
I would advise that startups interested in figuring out the best pricing model do not start by making a definitive statement about their pricing strategy publicly on their website. It is best to test different arrangements with select customers on a case-by-case basis, see how they impact profit margins, revenue, retention, and renewal rates and make necessary adjustments.
Complex and hard-to-understand pricing will always be an obstacle to product adoption. Ideally, you will want to review all the components of your billing model and identify ways to simplify it as much as possible. Use familiar concepts and leave customers in control of what they get charged for, especially if you are considering usage-based billing. If simplifying pricing is not possible (are you sure?), I have found pricing calculators to be the second-best option. On a different note, when you allow people to send a copy of the calculation to their email, you may find that pricing calculators can be great for lead generation (people who visit your pricing page have shown a strong interest in buying).
A brief note on bottom-up adoption
The textbook PLG implementation often makes us believe that a security professional in a large enterprise could use their company credit card to buy a security tool, and then scale their deployment up from there. While it could happen (theoretically, anything is possible), in my experience I have not seen it. When a security practitioner recommends a tool to their peers or managers, they put their professional reputation on the line. Security professionals will most commonly set up a product in their home lab first, test it, understand how it works, and only then bring it to their company assuming there could potentially be a fit. They will get as deep as possible into the ins and outs of the product, test the most unlikely yet still valid use cases, talk to the team and read every line of technical documentation before gaining enough confidence and a level of trust needed to recommend the product.
Most importantly, a customer will rarely go through the whole buying process and close the deal without ever talking to the startup founders. This is especially critical for early-stage companies that not only have to prove that they can handle customer data safely and securely but also have to convince buyers that the startup won’t run out of money or get acquired and triple its prices six months later. This is yet another place where PLG will look different in real life than it does in inspirational tweets and LinkedIn posts.
Examples of what PLG in cybersecurity could look like
Product-led growth is not a boolean, it is a scale. We are used to thinking that a company is either "PLG" or "not PLG", but in real life, it is rarely that simple. Product-led growth takes all shapes.
A great example of a product that treads the line between PLG and a sales-led approach is Tines. Tines offers users the ability to try the product, test it in their home lab or their company at a small scale, and experience the value in a self-serve manner without having to worry about pricing and contracts. Keeping their basic pricing tier free creates a great opportunity to serve practitioners, build a community around the product, and get hands-on security professionals to try, test, and learn how to use the tool. On the other hand, companies interested in adopting the solution are expected to go through the sales process. The absence of publicly listed pricing keeps the room open to sales via channel as well as reseller arrangements.
This isn’t an example of how PLG “should be” done as there are no recipes for success. Snyk, for example, takes a different path and offers a fully self-serve experience with transparent pricing anyone can access by creating an account on their site.
Implementing PLG in a cybersecurity services company
PLG stands for product-led growth, so it’s natural to assume that cybersecurity service providers cannot be product-led. That is not entirely the case. Service providers can greatly benefit from the elements of PLG if they productize their service - a trend we have been seeing more and more in the past decade. Productized services are a relatively new phenomenon in cybersecurity. The idea behind it is that services can be sold like products, with well-defined parameters, the scope of offering, and pricing.
Service providers that take this approach tend to package several services (i.e., antivirus, threat hunting, virtual SOC monitoring, forensics, and others) into one offering, with predictable pricing such as "$X per device, billed monthly". A company that treats its service as a product, can:
Look for ways to optimize the customer onboarding into their “product” - make it easier for new customers to try their offering, to get started, and to get to the “AHA!” moment (realize the value of offering)
Make support easily accessible and readily available in a self-serve manner
Employ a transparent pricing model
From the user’s perspective, it shouldn’t matter if they are seeing a fully automated product offering, or if there is a team of people behind the solution making it happen: it should feel like a seamless, almost fully self-serve experience.
Nano Cyber Solutions offers a great example of how elements of product-led growth can be implemented for a services company.
The easy way isn’t always the best
Implementing PLG in cybersecurity is hard. Despite how straightforward it may sound, the truth is that no one in the industry has had it all figured out. We know that the underlying assumptions are all valid: people want the ability to evaluate tools without having to attend mandatory demos; they want to pay for what they use and get support on their terms. Naturally, they also want easy-to-use products. We know that giving users the ability to get started and use the product in a self-serve manner also benefits the company as it cuts customer support costs, ensures the sales team's focus on the highest-value opportunities, and turns users of the product into internal champions for its adoption.
We have also learned that product-led growth in cybersecurity is not a substitute for bottom-up sales. It can greatly complement the sales strategy, shorten the amount of time it takes for the deal to close, and open new revenue channels. However, embracing PLG is not the reason to eliminate the sales team, and for early-stage startups, PLG will not replace the need to hustle.
As you are looking for your own way of becoming successful with PLG, you will inevitably run into challenges that will test your resolve to become product-led. There will always be at least two ways to solve any problem: one that looks like an “obvious choice”, and another that is less obvious, likely harder, but also tends to bring better strategic long-term results. For example, you may find that customers are getting lost in the self-serve product experience. The easy path to solving it is to embrace that “we’re just not created for PLG”; the harder - is to get to the bottom of why that is happening and address the root cause. Maybe, the product experience is too confusing and complex, or maybe the product documentation doesn’t cover areas that are critical to the user’s success, in which case simplifying the product and adding documentation will do wonders long-term.
When the product doesn’t appear self-explanatory and doesn’t tell the story of what role it can play in the company security stack, you can look for ways to redesign the navigation and the way the product is presented, add a welcome video, or a guided in-product tour. If a user needs to connect sensitive data before they can see how the solution works, you may consider adding a demo configuration or simulated data. In both cases, the easiest way is to offer a demo, but over the long term, mandatory demos do not scale as well as self-serve, in-product experiences. The easy way isn’t always the best.
Note on competitors stealing your intellectual property
If your product allows self-serve signup, you can be confident that competitors will check what you are up to, no matter what restrictions you put in place. Naturally, you have to be smart about how you approach this. If you are in stealth mode, making your work open would likely not be wise. If you are not in stealth, the decision about how to approach it is much less straightforward.
As a company, you need to have a set of competitive advantages that will defend you from being overtaken by your rivals. If proprietary technology is one of your advantages, and you are afraid that other companies can reverse engineer it by getting access to the product, it may be a good idea to not offer a full-featured product without vetting who the buyer is. Instead, you may want to come up with a basic version of the tooling that is enough for customers to realize the value of what you offer, but not enough for the competition to do any damage. You can always opt-out from self-service as well, at least until you can solidify your position on the market.
Having said that, keep in mind that if your business would be destroyed if one of your competitors got access to the product - you are very likely doing something wrong, and your competitive advantage may be short-lived.
Don’t make your product open and then wait to see what happens
If you implement a freemium or a free trial experience hoping that it will bring you thousands of new users that match your ideal customer profile tomorrow, the truth is that it will most likely not happen. I often see cybersecurity founders think of PLG as a magic wand when you can just "build it and they will come". It is not, and hope is not a strategy. If your product solves a compelling problem for a specific customer, and that customer can start using the tool without the need to go through a complex sales process - that’s a great start. Now, you need to think about the ways to get what you build into the hands of real users. If you have done the customer discovery (step 1) right, you should know very well where people in your target market spend their time, where they get their news from, connect with peers, learn new skills, showcase what they know, and how they earn credibility among others in the industry.
Events like capture the flag (CTF) competitions, hands-on training, bootcamps, security conferences, and similar may be great places to get people to experience what your product can do firsthand. For example, if it is suitable as a platform or one of the tools used at the CTF, see if you can become an event sponsor or even organize your own competition (think of Splunk Boss of the SOC and OpenSOC).
Talking to VCs about PLG
As you are talking to investors about building a product-led cybersecurity startup, be ready to get some odd looks and a lot of skepticism. Don’t fight it and don’t give up thinking “they just don’t get it”; instead, try to understand where they are coming from.
VCs have not seen many successful “purely PLG” startups in cybersecurity. They have, however, seen tens, hundreds, and sometimes - thousands of founders thinking they can just build a product, put it out there, and watch people flock to their amazing solution, asking “when can I start paying for this life-changing tool?”. Founders call that “PLG”, but what it really is is the “build it and they will come” mindset; a mindset that sets any startup on a path of failure.
When it comes to implementing product-led growth for cybersecurity, I would advise you to assume that you have to be sales-led until proven otherwise. Then, get determined to prove yourself wrong: learn about your customers, what they value, and how they make purchasing decisions. Don’t start by saying “we are PLG”, but build towards it: make your product easy to understand, easy to use, easy to share and refer friends to, easy to upgrade, etc.
Most investors will see “PLG” on a deck as a red flag when evaluating a cybersecurity startup. If you can convince them that your version of PLG is not “build it and they will come” but one powered by hustle, the ability to get the first 50 customers via sales and build the product so well that the next 500 will want to self-onboard, they are more likely to give you a chance. Being product-led does not mean getting to avoid hustling, it means hustling twice as much: to solve the same painful problem 1000 times, get someone to pay for the solution, and then find thousands more prospects with the same problem, get your solution in front of them, and compel them to start using your product on their own. If it sounds hard, it’s because it is hard. Anyone who suggests otherwise has some agenda and hidden motives in mind, is selling something, or has no clue what they are talking about (I am happy to be proven wrong).
Closing Notes
Product-led growth can be a great component of your startup’s go-to-market strategy, although it is unlikely to solve all of your problems. Implementing PLG in cybersecurity has many nuances and you may find it to be harder than the stories you’ve heard from founders in other industries. Being product-led is a journey that requires persistence, openness to learning, the ability to adjust, and a company-wide buy-in. Whatever you do, remember to keep experimenting and start with the customer's needs in mind - without a happy customer, there is no business, and no dashboard, no signup flow, self-serve or otherwise, can change that.