PLG in Cyber Security is a mirage

Product-led-growth (PLG) is beautiful when it works. This post is not about its advantages or what makes PLG successful — there are plenty of resources that speak to it. My friend Alok Shukla also has written a lot about PLG. I am here to argue that PLG does not work in cybersecurity.

An article (https://openviewpartners.com/product-led-growth/) on PLG has an important statement: “ Users have direct buying power or have influence over buying decisions”. I would like to expand this to: Users can experience your product on their own and have direct buying power. “Experience the product on their own” is where cybersecurity falls short. Let’s look at a few examples:

1. Application Security: the appsec team needs to have access to the CI/CD pipeline in order to install and experience the product. In most companies, the ownership of the CI/CD pipeline is with DevOps. Additionally, when a vulnerability is identified, appsec cannot tell whether it’s a real vulnerability because they are not familiar enough with the code. They can of course request DevOps to get access to code so that they can review the vulnerability on their own, but these are big hurdles. End of PLG.
2. Endpoint Security: sure, endpoint security can install the tool on a few machines in the lab. But eventually they have to try it on a large number of machines to experience the operational aspects of the tool for which they have to talk to Desktop Ops. End of PLG.
3. Network security: to install a network sensor, the security team has to talk to DevOps who may have their own priorities and requirements — does it increase latency, is it inline and what will be the impact of downtime. Network Security needs to convince another person — who does not directly benefit from the solution. End of PLG.
4. Security Architecture: Security is responsible for it but needs to work with developers and architects to insert themselves into the discussion first, let alone try a new tool. Big hurdle for PLG.

You can see where I am going. Security is complex and multi-faceted and most security practitioners are not hands-on enough to do some of the tasks described above on their own. Testing a security tool is always a collaborative exercise between security and at least one other function which prevents PLG from being successful.

And the Security function is getting broader without commensurate increase in resources. Every new technology brings with it its own security challenges. This dichotomy is forcing the Security team to focus on higher-order tasks and metrics such as measuring and reducing risk, providing the metrics to the board to get more budget and knowing fully well that no matter what they do they cannot eliminate risk, and prepare for the worst to come.

There are two exceptions to this rule:

1. When the security responsibility is transferred to the team that can experience the tool. E.g., if the developers are held responsible for AppSec they can try the tool (at the least in their own pipeline), and verify the accuracy of the tool.
2. PLG in cybersecurity can work for “innovators” and maybe (maybe) even “early adopters” who urgently need your tool and are hands-on enough to experience it on their own or where the organization is not mature enough to have multiple functions with clearly defined responsibilities. The test remains the same: Can the users experience your product on their own and have direct buying power? But even here, as you move to the “early majority”, be prepared to complement PLG with top-down enterprise selling.

Do you agree?