How we made developers love security

Building a successful company is no small feat. Since the acquisition of Bridgecrew by Palo Alto Networks, many people have asked me and my co-founders about how we did it and what was the secret sauce to make developers love and adopt security. When Guy Eisenkot, Barak Schoster Goihman and I founded Bridgecrew, we did so with a focus on those who became the true owners and operators of infrastructure security – the software engineers. Like many startups, It has been a chaotic journey that depended on quite a bit of luck, but I can still recall the important decisions we made, helping the stars align faster than expected.

1. Technology is not the most important thing

There is a common assumption that technology creates the value in a start-up and hence its significant importance. Too often investors ask entrepreneurs: "What is the unique technology? Where are the patents, the algorithms?" As a result, entrepreneurs focus heavily on the technology and then go looking for the problem it solves. But maybe there is no problem at all?

Despite our technological backgrounds, Guy, Barak and I did not start by engaging in technology. Instead, we asked ourselves: Who are the users we want to help and what are they truly missing? We interviewed over a hundred (!) customers and realized that the problem with cloud security is not a lack of tools for identifying risks - but rather the abundance of tools. Too many alerts are sent to software developers, but they do not have sufficient toolsets to deal with them.

We knew then that we had to focus on providing security tools to developers. Only then, we started to develop our technology stack and our product. Now with the ability to deepen our commitment to the developer and enhance the capabilities of our platform, this mission rings truer than ever.

2. We started working with users from the beginning (and for a fee!)

At one point, we met the Chief Information Security Officer of one of the fastest-growing companies in Silicon Valley. "I have actually a huge security review next month. Instead of just talking about how you could help in the future - maybe you will come and help now? Send me an offer.”

This was not our plan, but we went for it (then doubled down with four more customers). So, without planning and before we even had a product, we started generating revenue by providing cloud security services.

Many startups follow the typical path of building a product in a lab, hoping that it would meet the customer’s exact expectations. The decision we took that day changed our path. Instead of building a product in theory - we, first of all, became the users ourselves; we joined internal discussions, listened to the real pain points of developers, and noticed patterns and needs from the field. And indeed six months later, it was not a services business at all. The first product in the industry that delivers cloud security value to the developers in just 60 seconds, was launched.

Product development ‘in theory’ is like learning to swim just by reading about how it should be done. Since then we are a natural part of the developers’ community, building tools to help with their needs, providing intuitive ways to find and fix misconfigurations and vulnerabilities.

3. It's not just the product but how it is sold

Almost all cyber companies sell products to the Chief Information Security Officer (CISO) and their team. But in our case, the users are developers and their way to consume products is different. They do not want calls from salespeople, have no patience for a long demo or pilot, and don’t have a huge budget.

We did in-depth research about companies outside cybersecurity that target and serve developers. We learned how they encourage developers to use their self-served product and monetize it. We fell in love with this method, stuck to it in an almost extreme way and translated the strategy into our product and target audience. With this method you don’t need to hire an expansive sales team or work with channels – you just need a good and simple product that will attract users, then it will land and expand with their accounts.

Thus, we became one of the only companies in the cyber world that managed to build a proven business model based on product-led growth (PLG).

4. How to turn users into advocates?

When we started implementing the strategy, we wondered how we could attract a huge number of developers and engage them in what we were doing. Customers suggested we try open source.

I was apprehensive – open source might be risky to the business, but Guy and Barak smartly insisted: "With a developer, one should speak in code." They believed that if developers knew the technology, we would gain their trust and create a community that would happily contribute content back. And so it was. Not only did we get quick feedback from the users, but we could understand the real need and demand from the community – just by closely monitoring downloads.

In just three months, we started to see a huge spike in usage. More and more developers came to our website, signed-up for the free tier product and quickly started to pay for the paid-tiers of it. We noticed how developers invite their peers to use the open-source and our product, how one team invites another one, how one customer attracts another one. It became viral.

This relationship with the open-source community cannot be overstated. From the moment we committed to being user-focused, aligning with the developers that use our product has been of prime importance. This created trust and a great go-to-market for our product. By collaborating with developers, we hope to identify many more open-source projects to invest in for the future.

5. It's the people who make the company

The first position we recruited for in the company was not a software architect, nor a front end developer. It was actually an HR manager. Even before we knew what the product was, we decided to focus on hiring the best talent for the company. We prioritized values, "drive" and "relentlessness", “modesty,” and “collaboration” – much more than specific experience.

We recruited talented developers who had added unique capabilities to the product, a support team that answered the developers' support questions quickly, and in the developers' language, a growth team that brought in more developers and a sales team that translated the viral buzz into revenue.

It proved itself. Right after the acquisition, I examined our superb management team and I noticed what they all have in common: for almost all of them, this was the first management position they’d had in their career. It was a good bet to take. Recruitment is something that continues to be so important, and we are always looking for the best people to come and join us on this journey.

6. We did not think of an "exit"

No entrepreneur will admit it, but many times you are too busy promoting the possible M&A. The risk here is that your strategy becomes short-term rather than long-term. We were in for the long run. We did not think for a moment about an exit. Focusing on our users and the business brought us to rapid growth and a business with efficient expenditures.

The decision to join Palo Alto Networks was not premeditated, but after realizing that the connection would allow us to continue to focus on what we love but with (many) more resources and a global customer base, we realized it was the right thing for the company and for our developer community. In the six months since the acquisition, we have been able to maintain our “start-up” culture, launch three new products, and keep recruiting heavily.

I know that with the lessons we have learnt over the past two years and the support of our users this is just the beginning of our journey to create the comprehensive security platform both developers and security professionals need for the cloud-native era.

Idan Tendler is VP DevSecOps at Palo Alto Networks. Prior to that he was co-founder & CEO of Bridgecrew, which was acquired for $200 million by Palo Alto Networks, less than two years after it was founded.