To succeed, cybersecurity startups need to be triple fit
To succeed, cybersecurity startups need to be triple fit
Talking about the fundamentals of the founder-problem fit, product-zeitgeist fit, and product-market fit and what they mean for cybersecurity startups
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!
Every founder who has been through the fundraising process knows that there are three questions investors ask all the time: “Why you? Why this? Why now?”. The answers usually go as follows:
“We are a rockstar team with many years of experience in cybersecurity”
“We are building a solution to a very painful problem”
“The number of breaches caused by whatever thing we’re addressing keeps growing, so CISOs are paying attention and we must do it now”
After the founder gets the term sheet, and most definitely after the money is in the bank, these questions are forgotten, deemed irrelevant, and shelved until the next fundraise. This is unfortunate because answering these three questions is critical to the company's success. Let me explain.
“Why you?” and founder-problem fit
Even though founder-problem fit is critical to startup success, I don’t think I’ve seen much discussion about it, neither in general nor in the context of cybersecurity. The story the founders share is typically a variation of the following: “I have worked X years in security so I am qualified to solve a problem Y”; this simplicity is incredibly misleading. Note that I am talking about the founder-problem fit and not the founder-market fit for a reason: although the market is a huge part of the problem, it is only one component of it. The skills founders need to bring to the table to build a successful startup depend on many factors:
the type of company they are trying to build (cash-efficient bootstrapped business, venture-backed startup with a path for acquisition, a platform company with the ambition of going public, etc.)
the specific sub-segment of security (identity, endpoint, cloud, etc.)
whether it’s a product or a service company
whether the company operates in an established market or its customers need to be educated about the problem
It is well understood that the person building the product needs to have a good grasp of the technical domain and that a generic “security” experience is rarely enough: someone who spent a decade building in the network space won’t be able to easily design a solution in identity and vice versa. The other dimensions of the founder-problem fit are not being discussed enough. For instance, if all founders who spent years in the services space are looking to build a SaaS offering, do they have the skills they need to succeed, or will their background hinder their ability to think like product founders? Or, if a founder has a vision about solving an entirely new problem in security but no interest in spending half of their time educating the world and evangelizing about their work, can they get their solution to market?
Thinking about the founder-problem fit is incredibly hard for several reasons. First, people can learn and become great at doing something they haven’t done before. Nobody was born a founder, a security practitioner, or a CEO of a public company; even repeat founders had their first venture. Just because someone didn’t have the opportunity to showcase certain skills, it doesn’t mean they are not a fit or won’t grow to be a fit for the job. Second, industry-defining companies are started by those who are outliers - those who think differently, and bring a new perspective to the field. Jeff Bezos wasn’t a merchant, Sergey Brin wasn’t a librarian, and Elon Musk wasn’t a car mechanic yet the first has shaped the world of commerce, the second - the world of information, and the third - the world of cars. Third, many non-obvious adjacencies are incredibly hard to evaluate. Just because a person hasn't worked in security, for instance, doesn’t mean that he or she cannot solve the problem of security data at scale, especially if they did it in another industry. All this is to say that what matters most, in my view, is understanding how founders think, and seeing what they’ve done in the past to overcome adversity and make something happen, not their formal pedigree.
It’s often said that founders need to be obsessed with solving the problem, but I don’t think we’re being clear about how important this factor is to a company's success. Getting to the product-market fit is hard, closing those early sales is daunting, and pushing forward despite little (or any) signs of success takes a degree of determination and persistence that someone not truly passionate about the space they’re in most likely wouldn’t have.
I often debate the degree to which security founders have to be “technical” (in this case, I mean cybersecurity expertise). Overall, I believe that domain knowledge is very important, especially at the early stage when the founder needs to handle sales, engineering, customer success, fundraising, and all kinds of interactions that require a strong understanding of the market and specific technical topics. This also highly depends on the type of customer: selling to security leaders demands a different level of depth than selling, for example, to pentesters and incident responders. Another factor why domain expertise is important is that early-stage startups routinely pivot: even if the company started in an area where the founder has some experience, it may ultimately end up evolving into something very different. An entrepreneur not able to catch up, or contribute at the right level after the company pivots, may be left behind or even drag the startup down. Worse yet, without a broad exposure to adjacencies in the domain, founders may not be able to identify the need or the opportunity to pivot, and if they’re on a path that’s not working, they could be forced to shut down entirely even if an opportunity to pivot was just a tiny bit below the surface. On the flip side, too much expertise and decades spent in the industry can cause a curse of knowledge and hinder the ability to think outside of the box.
As the company grows, domain expertise becomes less and less critical: running a Series B or C company is much more about building a business, than it is about developing a technical solution.
What is required of a specific founder is highly dependent on the number of people on the team. If there are three co-founders, the first can focus on building, the second on selling, and the third - on fundraising/day-to-day/operations, etc. If there are only two founders, it changes the equation. I must say that I don’t think solo founders are a good idea in any industry, especially in cybersecurity. A solo founder would need to be a technology expert to engineer the solution, a domain expert to solve the right problems well, and a business expert to sell it and scale the company. Being great in all three areas is hard, not to mention that it’s nearly impossible at the early stage to find time to do all this without support, or even just having a counterpart to bounce the ideas off and get reenergized when things don’t go well.
“Why now?” and product-zeitgeist fit
Product-zeitgeist fit is a concept that was introduced by D'Arcy Coolican of A16Z back in 2019 in his article Product Zeitgeist Fit: A Cheat Code for Spotting and Building the Next Big Thing. It explains that timing is critical to start success: if the idea is too late to the market, it will be faced with fierce competition in the crowded space; if it’s too early, people won’t “get it” and they’ll fail to embrace the innovation.
Product-zeitgeist fit is a big challenge in cybersecurity because the space is rapidly changing, and new ideas are proposed all the time. In hindsight, it’s always tempting to think that a new approach or a new solution was obvious, but that is rarely the case. While many founders are jumping on the bandwagon of building obvious widgets in crowded markets, some - the minority - are betting on the uncertain future. In cybersecurity, this is often referred to as “category creation”.
In security, there are three types of innovations: those that address new threats in a well-understood attack surface, those that address new problem areas in a new attack surface, and those that change the way security is done in general.
The first approach is, in my view, the most straightforward: there is a widely used technology and a legacy way to secure it. Eventually, we discovered that attackers have matured their approaches, and tools that worked before are no longer sufficient. An example would be endpoint detection and response: when we’ve learned that not all attacks can be prevented by creating a library of known bad signatures (antivirus), behavioral detections and detection engineering as a discipline was born. This category of solutions is the least risky in terms of product-zeitgeist fit: the buyers already have the budget, they just need to be shown the shortcomings of their existing stack. The downside of taking this path is the fact that the startup is likely to face steep competition.
The second kind of idea - addressing new problem areas in new attack surfaces - is a bit more risky. Here, founders need to anticipate several things:
the probability of the new technology being widely adopted
the speed with which the new technology will be adopted
the risks and attack methods that can be used to compromise it
Many people assume that doing all this is easy: say, when the cloud became big, it was “obvious” that someone out there would try to exploit it; now that AI is seeing widespread adoption, we can anticipate what will happen in a few years (or so we hope). While it’s tempting to think of this type of innovation as “obvious”, it’s not quite the case. An example would be 3D printing and virtual reality (VR): when these technologies appeared, we thought they’d reshape society in a few years but that didn’t happen. Security companies that made a bet on 3D security, thinking that all buildings would soon be printed, probably went out of business by now. Quantum security is another such example - if it will take 30 years before quantum computing becomes a reality, none of the deep tech startups focused on that area today are going to survive by the time the vision of quantum is realized.
The third type of innovation, changing the way security is done, is the riskiest but it is also where the biggest rewards lie, both in terms of the scale of impact, as well as monetary outcomes. Just seeing the direction of the trends is not enough; one also needs to be able to anticipate the speed of them unfolding. For example, security is inevitably evolving from promise-based to evidence-based & becoming a more engineering-like discipline; it’s also becoming obvious to the market that every organization’s environment is unique, and without security practitioners (detection engineers, security engineers, security architects, etc.) accounting for that difference, it’s hard to truly safeguard the business. The question isn’t if these factors are true, the question is what will this maturation look like? Will it take us five, ten, or thirty years to get there? Only time will tell, and that’s the essence of the product-zeitgeist fit, and the risks it brings.
“Why this?” and product-market fit
Unlike the former two, product-market fit is a frequently discussed topic; not surprisingly it’s also the only one which got an abbreviation - PMF. There are a myriad of ways to define what a PMF is. People typically think of it as a market pull, where the customer needs the solution so much that they are willing to pay for it and sign a contract immediately; a frequently used descriptor is that product-market fit is when the product is literally “flying off the shelf”.
Regardless of how it’s defined, the PMF is a sign that the solution the company is building is solving a problem some customer segment is experiencing, which compels them to pay for it. What it doesn’t mean is:
That the total addressable market for the solution is big enough to justify building a company, or that is growing or expected to grow. It could very well be that the startup has found the PMF selling to the incredibly sophisticated top 0.005% of mature security teams, but since that market is small, it may not be well suited for a fast-growth startup.
That the company has priced the product in a way that will allow it to grow at healthy margins. Every problem has an associated cost, and the startup can see strong demand at a very low price not sustainable over the long term, and find itself losing the PMF when it changes its price point if the market segment it targets is not willing to pay the new price.
That the company is in a good market to compete in. One can build a great endpoint detection and response (EDR) solution in 2023 and achieve a product-market fit with it, but be smashed in the red ocean market of hundreds of EDR vendors.
That once achieved, a product-market fit is there to stay. Markets change, and with that, so do customer expectations for what constitutes a suitable solution. When this happens, startups can lose their PMF along with the ability to acquire new or retain their existing customers. Founders and product leaders must stay on top of changing customer expectations and continue innovating to meet them.
Similar to product-led growth, product-market fit is too often understood as “we will build it and they will come” when that isn’t the case. In new markets, when a startup needs to educate the industry about the problem, and position itself as the best (or the only) solution, achieving PMF is hard: if what the company was doing was obvious, there would be a lot of competition. On the other hand, the easier it is to get the product-market fit, the more likely it is that many other founders are solving the same problem.
There are several mistakes I often see cybersecurity founders repeat when working on getting to product-market fit:
Not talking to users early and often. Too many talented security practitioners are building what they think are game-changing ideas behind closed doors, taking years to get the early prototype. This hinders them from getting customer feedback and iteration early and produces solutions with little to no real-life value to the broader market.
Since the product-market fit is about product, it’s fascinating that many entrepreneurs mistake a PMF for having some “killer feature” that is going to change the company’s trajectory. It may very well happen, but it’s rare that some magic widget would define the future of the business: instead, it is commitment and consistency over a long time that make startups succeed.
Mistaking surface-level feedback such as “Yeah, that sounds great - we could probably use it” as signs of the PMF. People will say anything to make a founder happy because no one wants to discourage someone who took a risk from continuing on their journey. But, good wishes aren’t equal to buying intent, and “Sounds very interesting, I would try” means little.
Mistaking proof of concepts (POCs), proofs of value (POVs), or design partnerships for product-market fit. These are fantastic signs that there is interest, but prospects may sometimes be curious to learn about new ideas, without having the intent to buy. What’s great about this is that potential customers who went as far as to formally try the solution are typically a great source of feedback.
Thinking that if the founder is building the solution to the problem they have personally experienced in the past, it automatically means that there is a PMF. This is only true if we clarify that until proven otherwise, the market for such a solution is one (the founder). For us to talk about product-market fit in a broader sense, there has to be evidence that there is indeed a market - a pool of customers that share similar characteristics, experience similar problems, and are willing to pay for solutions to their problems.
Mistaking a certain revenue threshold for the PMF. Although the $1 million annual recurring revenue (ARR) milestone is often used as a proxy for product-market fit, the reality is much more complex. The number that can signal (when taken together with other factors) that the company has achieved PMF is relative to the size of the market it is tackling, the cost of solving the problem, and so on. If a founder can convince three of their former employers to buy the solution, that doesn’t signal real market demand. The same is true when the startup offers its product at an 80% discount and the customer hasn’t renewed it yet at full cost.
Not validating their assumptions about the market, or not testing other potential markets. Customers that from the outside appear to share similar characteristics may react differently to the same problem and have different degrees of urgency when it comes to solving it. This is often a sign of some deeper differences that founders should understand and learn about. A market of “small and medium enterprises that employ 200 to 500 people” may include a 40-year-old food catering company, a network of pharmacies, and a fast-growing SaaS startup, all of which would have very different security needs.
Assuming that they don’t need to worry about product-market fit if they are not looking to take venture funding. Any commercial enterprise needs to have someone who sees its solutions as feasible and is willing to pay for them, be it a three-people security consultancy, a four thousand people product vendor, or an open source project that is being developed not as a hobby but as something that has the ambition to grow into a company.
Closing thoughts
Why you? Why this? Why now? Each of these questions is much more than VC checkboxes; they are true prerequisites for business success. Founders of cybersecurity startups need to think beyond the basic definitions of the product-market fit and look for ways to get all three - product-market fit, problem-founder fit, and product-zeitgeist fit.