Time to trust: what it is, why cybersecurity startups must shorten it to accelerate growth, and how to do it
Discussing the number one metric cybersecurity startups should think about to improve customer acquisition - time to trust. Offering practical ways to do it.
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!
Not too long ago, I wrote a deep dive about the role of trust in cybersecurity, and how what is happening in the industry leads to the tragedy of the commons. It summarizes many of the observations about the dynamics of the industry I have been observing for a long time. Before that, I explained how the reliance on trust is the main reason why we have thousands of cybersecurity vendors, and why it makes “great industry consolidation” highly unlikely.
In this piece, I will introduce a metric that I think is key to improving the adoption of cybersecurity products - namely time to trust.
The original (and shorter) version of this article was first published on TechCrunch.
This post is brought to you by… ViS Angel Syndicate
ViS Angel Syndicate believes that security engineers, SOC architects, detection engineers, penetration testers, threat researchers and other hands-on security professionals are best positioned to shape the future of cybersecurity.
As cybersecurity is becoming more technical, traditional investors are struggling to evaluate ideas and solutions of the future, often funding tools that make big promises but don’t solve real problems. On the other hand, while security practitioners spend an incredible amount of time staying on top of new innovations, they still have little impact on what gets funded. ViS Angel Syndicate is changing this.
Why traditional playbooks for success fall short in cybersecurity
New product adoption in cybersecurity moves with the speed of trust.
“Among all the reasons why that is the case, there is one unique to security: in other fields, a customer is evaluating products against known or reasonably foreseen present and future requirements. When a finance department is looking for a new forecasting tool, it knows exactly what it needs to do today, and it can envision some great functionality for tomorrow. In cybersecurity, it is typically hard to make sense of what the vendor is offering to address the present-day threats, and it is not at all possible to predict future ones. A purchasing decision in security is a leap of faith: “Knowing what I know, do I think this company will be on top of new issues that neither of us can even begin to imagine when we’re signing the contract?” - Source: Venture in Security
In practical terms, this means that unless security vendors can build trust during the sales process (and even before that), the deal is not going to be closed.
What is interesting is that while trust is so critical to the industry, we do not hear any discourse about it when talking to product, marketing, sales, and other teams in charge of the go-to-market. I think that isn’t an accident as the body of knowledge in all these disciplines comes from two sources: Silicon Valley and large enterprises like Cisco, Intel, and Microsoft. Unfortunately, both fall short of giving us what we need to succeed in building companies in cybersecurity.
The Silicon Valley playbooks of success are focused on the consumer space: build a thing, design growth loops, get millions of people using it, and then aggressively capture value (monetize) this usage. The ideas of product-led growth, community-led growth, and the like all originate in this space. Cybersecurity is a different beast: it is predominantly B2B, and most of it is enterprise sales. Few consumers care about security, and SMBs are only starting to realize the magnitude of their vulnerabilities, albeit very slowly. Here are two examples that illustrate why the Silicon Valley playbook fails in security:
Enterprises buy based on their plans and budgets approved months in advance, and implement new tooling as projects. Most cybersecurity startups are tackling emerging attack vectors, and it takes a long time to educate prospects about the problems they need to solve. Naturally, if the problem is not well understood, and if solving it is not planned for the next calendar year, the sale won’t happen no matter how much the founders are hustling.
Bottom-up adoption has a unique flavor because while elements of product-led growth (PLG) can help the security team validate in their home labs that a solution is worth checking out, for the purchase to happen, a traditional sales process will need to occur. In other words, having a free trial and a free sign-up does help to speed up adoption, but it is not a replacement for the traditional sales process.
The enterprise sales playbooks of Cisco and the like fail for a different reason: all of these companies have well-established brand names, which automatically gives them a huge credit of trust. Few customers are afraid that Microsoft will go out of business next year, or that the product it advertises on the company website does not actually exist.
From time to value to time to trust
Here is an example of how several companies I advised are impacted by the problem of trust. Most security products require the user to a) send sensitive data into the tool, and/or b) deploy an executable in their environment, and that is before the value this product offers can be experienced. Not surprisingly, few security practitioners will download and deploy a random executable on their machine. The result: even if the product was capable of solving all security issues on the planet, it would not have scaled as quickly as ChatGPT or any consumer-focused unicorn, because it would need access to the most sensitive data and environment, and that requires trust.
I have concluded that in cybersecurity, trust must come before value can be realized. And, while it is commonly understood that in order to be successful, companies have to shorten their time to value, I think that cybersecurity startups must first focus on shortening their time to trust.
The concept of time to trust
I think of time to trust as a concept, rather than a metric. In that regard, it is similar to time to value.
We know that by removing the requirement to attend demos before people can get started with the product, optimizing onboarding flows, reducing the amount of data users are required to provide upfront, stripping down the need to enter the credit card details, and adding demo content, we can make it easier for customers to experience value cybersecurity product offers. For those interested in this topic, I have previously published a practical guide about how to do it. We also know that it is not easy (and often not possible) to measure when exactly something clicked in the person’s mind and they “got it” - realized that a specific solution is something they need. However, the sooner it happens, the more likely it is that the person (and the company) will adopt the product & start paying for it.
Time to trust works similarly. It is understood that prospects must trust the company, its founders, its approach to security, and the product before they can be comfortable sharing their data, and even more so - becoming paying customers.
In the next section, I will discuss some of the specific dimensions of trust and how cybersecurity startups can effectively shorten the time to trust.
Time to trust: questions cybersecurity customers ask, and how to answer them well
Trust is fundamentally about a sense of safety, familiarity, and assurance that “everything will be fine”. It gets built as we address our doubts - questions in our heads that make us look for clues if we can rely on someone or something to be there when we need them.
The process of vendor selection is not much different; what’s different are the questions people ask, and the clues they are hoping to find.
What problem is this company trying to solve? What problem is it not trying to solve?
The number one question people ask as they learn about a new tool is “What problem is this company trying to solve?”, and it is on this first step where many companies fail. Intentionally or not, cybersecurity marketing rarely makes it easy to understand what the product does, and equally importantly - what it doesn’t do.
In these rare cases when a company is clear and transparent about where it stands, we see security practitioners get impressed by this.
Image Source: Lennart Koopmann
Make it easy for people to understand where in the security stack the product fits, what it does, and what it does not do
Make help center, technical and API documentation, and other materials easily accessible so that people can quickly skim through and build a mental model of the company offering
Does it actually solve it?
The fact that someone is trying to solve a problem does not mean it actually solves it. There is a lot to be said about the importance of social proof, but the tough part is that security teams often do not want to disclose what solutions they are using and how they fit in their environment as adversaries can use this information to accomplish their goals. There are, however, other forms of providing real user feedback, and proving that the company does what it says it does.
Collect customer testimonials and make them easily accessible. If there are no paying customers - see if any of the design partners would be comfortable going on the record as users of the product. Make sure that they are real and truthful, and that the person who provided them is prepared to be randomly pinged by prospects with questions. A good security team will do their due diligence and talk to other customers, especially if the startup is early in its journey and is not known in the community.
Have an easily accessible online community where people can join, ask questions, and send direct messages to one another. It is very common for security professionals to reach out to DM their peers who have responded to questions and engaged in the community to get some unfiltered feedback about a vendor.
What are the chances the company will be out of business soon?
Trying and implementing new security tools is incredibly expensive, and organizations are not looking to rip and replace their security stack every year. At the same time, the vast majority of cybersecurity companies are startups, and startups come and go all the time. One of the most important questions a potential buyer is trying to figure out during the purchasing process is whether or not the company is likely to be around a year or two later.
The easiest proxy for this is access to funding: while having access to capital does not necessarily mean that the company will be able to survive, not having it does imply that it won’t.
On the website and in publicly-facing materials, disclose if the company is venture-backed, and if possible - list the investors. This is especially useful for early-stage startups without any customers as it acts as another source of social proof.
In demos and calls with prospects, be transparent about your stage and plans for the future. Sooner or later, the truth will come out; being upfront will help you earn respect and make it more likely that the company will be willing to take a chance compared to situations when startups start the relationships by lying and hiding the real state of affairs.
Is there a real product? How does it work?
In many other industries, it is possible to build an empty web app with some easy flows, launch that as an MVP, and start getting customers. Cybersecurity products are more complex, they take a longer time to build, and little to no value can be delivered by a half-empty web app.
Security teams have a lot of experience working with startups, and they know that early-stage companies typically take many shortcuts to get to market quicker and validate their solution. Naturally, they need to understand to what degree these shortcuts can impact the value the product is able to offer, and also if the startup itself can become a “trojan horse” for bad actors due to its weak security maturity.
The best way to build trust at an early stage is to start with an open source version that can be inspected by prospective buyers. While this level of transparency comes at a high cost, for young startups (say, one-year-old) with no solid reference customer base and design partners, it can be very hard to get enterprises to take them seriously.
For a product that must remain proprietary, it is a good idea to implement elements of product-led growth such as free trials and self-serve experience so that any security practitioner can evaluate the product in their home lab before they invest time and effort to kick off the traditional sales process
Make API and technical documentation accessible so that security practitioners can build an understanding of how the product works, and test it on their terms
Encourage people to ask questions, submit feature requests and report gaps/bugs in the online community. Be open and transparent about what the product does not do so that people don’t have to waste their time testing scenarios you cannot (or are not planning to) support
Can I trust the founders & the team?
When a security team is evaluating a new vendor, many factors are important such as product, technical documentation, price, and the like. However, trust is personal, hence vendor evaluation is first and foremost about deciding if they can trust the people behind the startup.
On the company site, dedicate some space to talk about the team - who they are, what brought them together to solve this problem, what they know, where they’ve accumulated their expertise, etc. Look for ways to communicate credibility through people’s stories.
Make it easy for vendors to understand what drives the founders to do what they are doing. Did they experience the problem themselves as practitioners, or did they get excited about “hot” valuations in the space and decided to make lots of money? Answers to these kinds of questions shouldn’t be stated, they should be read between lines by looking at the founder's bio, how they talk, behave, and what they pay attention to.
Remember that in security (and in life in general), transparency is key. By openly talking about what works and what doesn’t, being honest about gaps, whether or not they can be addressed, and how long it would take, and by being truthful in general startups can build long-lasting trust and get the goodwill of people much quicker.
Can I rely on them for support?
It is well understood that startups can’t have everything figured out, and there will be gaps. Most importantly, even if everything is working well, given that every company has unique security needs, new requirements, and feature requests are inevitable. The fundamental question a prospect is asking is “Can I rely on the team for support?”.
Make sure your response time is short, regardless of the communication medium. Security teams will look at online communities (Slack, Discord, or whatever the company is using), check public GitHub repositories, and the like. If there are tens of unanswered questions, or if it takes the startup team days or weeks to unblock a user who is stuck, this won’t work.
Remember that startups can use their ability to provide a good level of support quickly as one of the core differentiators. While it takes large enterprises weeks to review questions and support tickets, and sometimes - months or even years before the problem is solved, startups can be much more agile. Seeing that the team is helpful, transparent, and responsive can help accelerate building trust.
Invest time in building a comprehensive knowledge base about the product, how it can be used, and the like.
How much does it cost?
Decisions about vendor selection are made within the constraints of security budgets, therefore companies are not simply looking for the best tool, but rather the one that solves most of their problems and that they can still afford. I believe in pricing transparency, but I do also understand the desire of some businesses to have a conversation and/or to get the prospects to request a quote. Whatever path they choose, it must offer a hassle-free way of getting the pricing information, as departing from this principle increases the chances that the security team will waste their time and effort (and subsequently - money) testing the tool only to learn that it does not fit within their budget.
Make it easy for security teams to understand how much a solution to their specific problems is going to cost, and estimate the future pricing based on the changes in their situation (number of endpoints, amount of data, etc).
A note on looking for shortcuts to build trust
Savvy vendors are always looking for shortcuts and even ways to completely bypass the important steps of the buying journey. That makes sense - the less time it takes for the prospect to convert into a paying customer, the more money the company will make. What makes less sense are the methods some companies choose to employ to get there.
If you’ve read my other deep dive about the role of trust in cybersecurity, and how what is happening in the industry leads to the tragedy of the commons, you know what I am referring to. For those who didn’t, here is a simple example: when the concept of “time to value” became well understood in the industry, many companies realized that what they are actually selling aren’t security capabilities, but a warm and fuzzy sense of safety. The value of these offerings is naturally hard to communicate.
Think this way: the value of a security automation platform is easy to understand: if the time spent performing manual tasks before implementing the tool was X, and the time spent on it after the tool is X minus 5 hours or X minus 25 hours, that’s fantastic. If, on the other hand, the product is selling “security”, it is hard to say if it’s valuable: are we okay because nobody is trying to go after us, or because the product is doing its job (or maybe we’ve been breached 10 times already but this magic all-knowing tool didn’t alert us about it)? There is no way to tell, so the smart security providers started adding meaningless charts and dashboards to show how much the product has “stopped and prevented”. While they often look impressive, they do not communicate value as most customers have no idea what they are looking at, and why they should care.
Building trust by pretending that something is there when it isn’t can, unfortunately, be done. That is why we are seeing companies celebrate pay-to-play awards, finance getting their “featured” content in pay-to-play magazines, and so on. I hope that buyers will become better at recognizing these tricks, and we as an industry put some checks and balances in place to weed out the unethical players.
It is important to keep in mind that trust is built over a long time and lost in an instant. Companies looking for shortcuts are likely to lose credibility and reputation in the community even before they can get any traction - which can be a beginning to an end of their journey.
In the past decade, the concept of time to value gained a broad adoption in the tech industry as the level of competition is increasing, and startups are looking to shorten the time and effort it takes for people to become paying customers.
Because as I noted before, the new product adoption in cybersecurity moves with the speed of trust, focusing on time to value alone won’t get companies where they want to be; cybersecurity startups must look for ways to shorten the time to trust. While there is no exhaustive list of questions that would cover everything a prospective buyer would be interested in, questions about the product, pricing, tech, team, support, and internal security measures are the most obvious ones.
By embracing transparency, encouraging feedback and new ideas, and building genuine relationships, cybersecurity startups can greatly shorten the time it takes for potential customers to become loyal promoters of their products. And, most importantly, it helps us protect people and organizations from bad actors while building a more secure tomorrow. For that, transparency sounds like a low price to pay.