A Practical Advice for Building Products in Cybersecurity

When I started building cybersecurity products, I noticed that many product leaders in the industry have great domain knowledge but lack experience when it comes to product management practices such as customer discovery, product-market fit expansion, and category creation. Domain expertise is so important that it’s not uncommon to see a security practitioner with deep industry knowledge become a senior product leader without any prior product experience. It’s much more common to see cybersecurity product leaders attend conferences and training for security practitioners compared to product management conferences like Mind the Product, or leading product training such as Reforge. All this makes intuitive sense as cybersecurity startups are often founded by deeply technical people with a strong vision, who tend to see product as a discipline focused on execution, not strategy and vision which come from the top. It does, however, also mean that the maturity of the product craft in cybersecurity may be seen from the outside as much lower than in many other industries. In this piece, I will be looking at product management in cybersecurity - what it looks like, the challenges it faces, and the opportunities it presents. Factors that impact the work of cybersecurity founders and product leaders Every industry has unique characteristics: some are dominated by one or two large players, and others are regulated to the degree that makes innovation a problem for lawyers, not technologists. There are also those driven by the emotional buying behaviors of consumers, rather than rational needs. I have as an industry, including the fact that it is deeply technical, that the innovation is driven by an external force - adversary - who is actively working to find holes in products released by security vendors, and that the quality of what is bought and sold cannot be evaluated at the time of purchase, and long thereafter. previously discussed how cybersecurity is unique In this section, I will discuss how these and other factors impact the work of cybersecurity founders and product leaders. Massive distrust in vendor outreach As cybersecurity is a very crowded market, both security leaders and practitioners live in a reality where every day, multiple sales teams try to reach them by any means possible - email, phone, warm introductions, and whatever creative channels they can come up with. The objective is typically to get them into a product demo, and from there - into the so-called “sales funnel'' which hopefully ends with signing a deal. The sheer volume of sales outreach, and sometimes questionable sales practices employed in the field, have made security professionals cynical and distrustful about interaction with vendors. When founders and product people try to reach security professionals for a harmless user discovery interview, to learn about problems they may have, or get their take on the approach the company is embracing, it is hard to tell what kind of call a practitioner would get themselves into if they were to say yes (most likely it’s going to be a sales pitch). This is why, sadly, even the most harmless requests with the sole objective of learning are generally being ignored. Lastly, the number of requests from friends, friends of friends, and well-intentioned founders all around makes it impossible for practitioners to take vendor calls without that becoming their full-time job. The need to guard company secrets Before starting in security, I was working at a company that built products for mortgage brokers - financial advisors who help borrowers find a lender with the most suitable mortgage products, including the best terms and rates that match their financial needs. A mortgage broker typically needs good tooling to collect the information from the borrower, prepare and underwrite a mortgage application, submit the application to a lender and obtain approval, and stay connected with the borrower after the transaction closes. Some people in the space are more sophisticated than others, but by and large, they care about efficiency, user experience, and price, as well as vendors’ resolve to solve their problems. Mortgage brokers are running their own businesses so they are incredibly busy, but when they do get some free time, they will happily talk to vendors about their experience, workflows, and pain points. They know that that’s how the mortgage industry gets better products that solve its most pressing challenges, and are happy to do their part. Security professionals, on the other hand, have fewer incentives to share their pain points with strangers. For once, this is exactly the opposite of what their job expects them to do: securing the organization and making sure that system vulnerabilities do not become known to outsiders and malicious actors. Founders and product managers asking a stranger to share what security tools their organization is using, what their exact setup is, and what is not working as intended, would often be out of luck as those are the exact same questions an adversary would be wondering about when looking to penetrate the company’s network. A conversation like this can generally only happen if there is a signed NDA in place or at least a trusted relationship between parties. Fragmented market and a large number of product categories The cybersecurity market is greatly fragmented with thousands of vendors attempting to get a piece of the pie and prove their value. This fragmentation is accompanied by confusing marketing where companies that do the same thing, position their offering in ways that make them look unique. Nearly every cybersecurity startup wants to become a category creator. For security practitioners, it is often hard to imagine where this “yet another great tool” would fit in their environment. This makes them even more skeptical of new startups trying to get their attention. At the same time, security teams do understand that new threats require new approaches, and with that - often also new tooling. This dichotomy - the desire to shield themselves from confusing marketing and the understanding that they should stay on top of new developments, creates a bit of cognitive dissonance for security leaders and practitioners. A strong need for people who think differently and understand the business of security Historically, cybersecurity has been an industry for deeply technical people. While the nature of the industry hasn’t changed, what is changing are a few realizations: The than by coming up with new technologies. Several companies have become unicorns by taking a different angle to market, innovating go-to-market strategies, and looking for ways to add value beyond research and development (which will always be important). realization that there are many more ways to innovate The realization that cybersecurity is not a separate planet, but one of many markets, and that experiences companies have in other fields shape their expectations when it comes to security products as well. In other words, if it takes 20 minutes from the time a person creates an account to the time they deploy a Docker container, why do they need to go through five demos before being able to deploy an endpoint agent for their security product? The realization that what got us here, won’t get us there. To implement innovative approaches in cybersecurity, . We have to look for ways to complement technical expertise with business minds that bring experiences from other industries. we can no longer simply continue recruiting product talent from large corporations Building products in cybersecurity The fundamentals of product management do not change From the foundational level, the role of a product manager is to be the expert in the problem space, and that does not change regardless of what industry they are in. I quite like how the former VP of Product at Netflix Gibson Biddle describes the role of product as well - “delighting customers in hard-to-copy, margin-enhancing ways”. Whatever definition we take, it would apply to a product person building a consumer app, ideating the next-generation cybersecurity tool, or trying to change the way agriculture works. Product management sits at the intersection of business, design, and technology, working as a glue between stakeholders from across the organization such as legal, marketing, sales, compliance, and the broader product team. As the fundamentals of product management do not change from one industry to another, neither do many best practices and habits that make product leaders effective at their jobs, such as customer obsession, the ability to get stakeholders' alignment, and leading without authority. What Marty Cagan evangelizes about in his books - “ ” and “ ” - is applicable across industries. Inspired Empowered Many commonly accepted best practices do not work to the same degree in cybersecurity While product management is still product management regardless of the industry, cybersecurity is without a doubt a unique space. Many modern product management theories and best practices come from consumer space - Netflix, Facebook, Apple, and others. The assumption is that there are millions of users so PMs can run large-scale experiments, get instant feedback and validate hypotheses quickly within short discovery cycles. Tools like feature flagging, A/B testing, cohort analysis, regressions, and others along with different ways to engage users such as gamification were created precisely in the B2C space. This is much harder to do when building cybersecurity products for several reasons: the install base is substantially lower as few cybersecurity products get mass adoption and the vast majority are B2B, PMs in security are building the product for expert users that often know the domain much better than the company trying to solve their problems, short release cycles that work well for select cloud-native companies built in the cloud and for the cloud such as Cloudflare and Wiz, do not work for the majority of the vendors forced to support obscure technologies, legacy architecture and on-prem solutions as all of them still do need to be secured, security needs are heavily defined by the company’s unique processes, operations, tech stack, geographies, and a myriad of other factors which makes it hard to come up with a one-size-fits-all solution. Instead of providing product managers with the ability to iterate quickly and often, and introduce impactful user experience enhancements, cybersecurity presents a complex puzzle with a large number of conflicting inputs to consider. A proof of concept (POC) can take months before the product team learns what worked and what didn’t. Many factors that influence buying decisions are completely outside of the product leader’s control (such as meeting various compliance requirements, and satisfying frameworks and standards). The importance of the trust factor is so high that any small perceived gap discovered during the POC can jeopardize the potential partnership. While having a green symbol with a lock and the words “secure and PCI compliant” may be enough for a consumer app to reduce the fear of customers putting in their credit card details, much, much more is needed to convince a large enterprise to deploy a tool from an unknown startup on their network. To put it simply, the modern product management theory and best practices do not prepare people for the level of complexity that is a norm in cybersecurity. Other challenges of building products in cybersecurity Some of the other challenges that the cybersecurity space presents for founders and product leaders are listed below. I have talked about this before in a different context but it is also worth mentioning here: . It is hard enough to assess if a security tool is capable of detecting malicious behaviors that can be seen in the wild today, and it is not possible to evaluate if the product will be able to detect something new that will emerge tomorrow. At any given time, a security practitioner (user) can take the latest attack and ask a valid question: “Would your product detect that?”. The list of possible product gaps is limitless, while the tech company’s resources are finite. This makes cybersecurity unique as there are few industries where the rules of the game change continuously, without warnings, preliminary discussions, or announcements. the quality of the cybersecurity product cannot be fully evaluated at the time of purchase, or often even after that It is often hard to critically evaluate the value the product offers as all metrics have their limitations, and explaining the numbers can be done in many conflicting, self-serving ways. If we see the number of alerts the product is triggering going down month by month, it is not possible to say definitively if that is a good trend or not. Are there fewer malicious behaviors? Is the product getting less effective? Have we already been breached and we just don’t know about it yet? Each of these is possible, and all of them could be true at once. Product management thrives on the ability to identify, understand, and explain trends; cybersecurity as it stands cannot be quantified and rationalized as easily. For product managers, it is often hard to have a deep, transparent discovery session with someone who is not yet a customer or a trusted partner. The questions a product manager would be asking a security practitioner about their organization, the tools they use, and the problems they have, are the same questions that an adversary would ask so they are right to be wary. A customer discovery call in the language of security practitioners may as well be called a vulnerability scan. At the same time, when a product manager can only talk to people who are already using their software, they naturally get a skewed perspective of reality and their role in the market. Learning about customers in cybersecurity is hard as security professionals are notorious for not sharing any information about themselves in public sources and sometimes - for avoiding things like social media altogether. For example, let’s say a product manager observes that their product tends to get great traction with customers that have between ten and twenty-five security professionals on their team. The value of this understanding may be limited by the fact that a good security team is not likely to have all of their employees listed on LinkedIn, so even identifying what companies meet that criteria can be hard. For many people in the industry, it is hard to talk about security conceptually, from a higher level view. This is because too many practitioners still see security as a tool problem (it’s worth noting that this has started to actively change with the ). Once people get too focused on tools and industry abbreviations, like EDR, XDR, MDR, NDR, and SOAR, to name a few, the conversation shifts from the problems users are looking to solve to the tools and their features, existing and missing. This “feature-by-feature” comparison is not as useful for companies looking to find better ways to do security instead of creating a “slightly better EDR”. move from promise-based to evidence-based security People who excel at security are commonly deeply technical. This is no surprise as to understand what makes an IoT device vulnerable, or to monitor Windows Event Logs, you do need to be technical. The technology alone is, however, often insufficient to understand the business side of security. Maxims such as that not every risk is worth eliminating, or that every decision to build something has a trade-off and opportunity cost, may not be as familiar to some practitioners who can get overly focused on some technical functionality without looking at the bigger picture. To their credit, it is not easy to gloss over any issue however small it may look from the outside as even the most insignificant gap can be exploited with grave consequences to the business. The buying journey in cybersecurity is complex and requires multiple steps, depending on the sub-segment the product is targeting. Economical buyers (CISOs and security leaders) involve technical people from their teams to do product evaluation and review. As a part of making the buying decision about incorporating a tool to strengthen the customer’s security posture, the prospect’s security team will interrogate the vendor’s own security posture. This is a very uncommon loop as, for example, no company buying accounting software will be given the chance to review the vendor’s own accounting practices. Because security requires deep technical expertise, most founders in the space come from the industry after having accumulated many years of security experience. The same is true for product managers as I have observed that most cybersecurity product managers are former practitioners from their industry - much more than in any other field I have worked in. A big part of building a product is embracing that you don’t have all the answers, and approaching the problem from a curiosity standpoint; some people refer to this as “having the beginner’s mindset”. This can be hard for some security professionals who have previously achieved growth precisely because of their ability to predict, anticipate, and have the answers. Some areas of security are so new that their ownership is still unclear. For example, AI security lives somewhere between security and data science teams, while code security - is somewhere between software engineering and security teams. This can make it harder to understand whom to target but it also presents an opportunity to experiment with different go-to-market strategies. Overcoming the challenges of building products in cybersecurity Many challenges of building cybersecurity products are inherent to the space. However, product leaders have the power to take steps that can minimize (and in select cases even eliminate) some of the problems. In the section that follows, I will discuss what founders and product managers can do to make it happen. Get clear about your ideal customer To build a security product that solves a compelling problem, it is critical to understand who the ideal customer for the product is. Too many cybersecurity founders and product people don’t go deep enough, defining their target as “enterprise companies” or “managed security service providers”. These broad definitions are of little use unless they are specific enough to help in day-to-day prioritization and make it easy to know where to find the people the product is targeting. Most importantly, categories of customers are rarely as homogenous as we sometimes want them to be. There are, for instance, different “enterprises” - from cloud-native venture-funded companies to traditional manufacturing firms and everything in between. Each of these has different levels of security maturity, different needs, and different places where they can be approached. To get clarity about the ideal customer, it is not enough to simply think about it. Product teams should become experts on their market, document their observations, get alignment across the organization, and find ways to test their hypotheses. Look to broaden the sample size for feedback & build trust Cybersecurity startups may not have thousands or even hundreds of paying customers to talk to. And, when founders and product people reach out to people in the industry who are not yet customers, they commonly run into situations when people don’t want to share their problems with strangers. One way to overcome this limitation is to build trust through events and community initiatives. Attending conferences can be a great way to talk to people who are not currently using your tool; not to sell, but to learn how to solve their problems and build better products. I have personally found smaller conferences for practitioners like BSides and Blue Team Con to be great places to ask questions and solidify your understanding of the problem space. People at these events are generally quite open to chatting, especially if you make it fun and non-sales-y and if you approach them without any hidden agenda. Most people in security are happy to help when they see someone show genuine interest in their work. Get people from across the company to help with customer discovery As a product manager, you are mining for gold, but you are not the only person in the company doing that. Sales, customer support, sales engineering, and marketing, - they all talk to customers and learn what is important to them. The challenge is that quite often, these golden nuggets of insights and feedback do not make it to product managers who can aggregate, organize, and use them as input in prioritization and planning the go-to-market strategy. Product leaders should look for ways to build systems and processes that encourage everyone in the company to share their discoveries and have them captured in the central repository. To get started, they can include a question about customer feedback (“What are people telling you? What have you learned?”) in their regular one-on-ones with sales, marketing, sales engineering, and other folks. It doesn’t have to be done formally, especially at an early-stage startup when the team is still small. Another way to get exposure to users’ feedback is by shadowing people from departments that have existing relationships with customers. Being a “fly on the wall” on a sales call can often give product leaders more insights into the customer's needs than sifting through pages of written feedback and call transcripts. Build scalable systems to aggregate product feedback Customers share their feedback all around - in sales conversations, in Slack, over email, and in conversations with support. Unless aggregated in one place, triaged, and organized, they are just a cacophony of ideas and perspectives. There are many great tools out there that help make sense of customer feedback; I use ProductBoard. Whatever tool you choose (tools are just that - tools), what matters is the ability to group the notes, see trends over time, spot patterns, and use these insights to prioritize product development efforts. Build trust by delivering on your promises An easy way to make sure your customers will lose any interest in talking to product managers is to learn about their pain points and do nothing about them. Now, product management is not about order taking - you have to make decisions to grow the business and consider all factors impacting your company, not simply take directions from the loudest customers. However, to build trust with your users, you will need to show that the feedback calls and problem discovery sessions you are having translate into enhancements, new features, and bug fixes. The whole point of having customer calls is to better understand their pain points and find ways to improve the product. Look for different ways to become an expert on the problem space Talking to customers is important but it’s not the only way to become an expert on the problem space. I found that many people in security are much more open to sharing their feedback in a survey or via email rather than in a video call. To get people to open up, meet them where they are, using the channels they prefer. Attending events, volunteering in the community, helping organize capture the flag (CTF) competitions and conferences, advising founders, and other ways to give back are not only the right thing to do but also great ways to learn by doing and becoming a member of the community. Embrace uncertainty and learn to ask powerful questions I have found that very few people understand the importance of asking powerful questions. Most either ask leading questions that force people to agree with what is proposed or even worse - ask questions in a way that makes everyone lie to them. I have as one of the must-read books for any founder; I also think it is a must-read for every product leader. This book will teach you how to stop asking questions like “Would you like to have the ability to do X?” (most people will say “yes”), or “Would you use X if we built it?” (most people will say “yes” as well). Instead, it will help you frame questions to learn what people actually think and do. For example, previously recommended The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you Explain your workflow to me. What is hard about it? What problems did you run into? How did you try to solve these problems when you ran into them last time? What worked, and what didn’t? I call these questions “powerful” as they help founders and product leaders learn what is happening, and identify and solve the most impactful problems. Be careful about building based on feedback from power users When you build a security product, you are working with experts who have well-formed strong opinions, and who will immediately say what they care about and what they don’t. This is a blessing and a curse of cybersecurity because every person comes with their own context, and in all cases that context is correct. Each organization's environment is different, and each organization’s workflow is unique, so what works for one customer may not work for another, and yet each has a legitimate need to do things their way. Security is not unique in this regard, but it is one of the few industries where the end user is more knowledgeable about the subject matter than the vendor. For comparison, a few Netflix users are experts in movie creation and machine learning algorithms. Even in IT, companies are selling to technical buyers whose expertise is typically very broad but somewhat shallow (they know a little about a lot), while the vendor’s expertise is narrow but deep in their respective area (say, storage). When security professionals get very loud about their needs, they can often pressure product teams into building functionality unique to their setup and not useful for other customers. This is especially the case with power users who tend to be more proactive, descriptive, and offer actionable ideas. Product teams tend to get excited talking to the power users as they seem to “get it”, and it always feels great to get the feedback product teams can act upon immediately, from someone who is using the product the way founders want it to be used. The challenge is that power users typically represent a small percentage of the customer base, and building products on their feedback will inevitably add more complexity, which in turn is likely to alienate the majority of less tech-savvy, casual users. Invest in maturing the organization's product practices There was a time when cybersecurity products were built by security professionals and software engineers based on the list of feature ideas provided by founders. We have now accumulated enough experience from other industries showing that the best products are built by empowered teams, where engineering, product, design, and domain experts work together to solve problems and push the company forward. The founder’s vision acts as a guiding vector, not a laundry list of features that “need to be built”. Product leaders in cybersecurity organizations should continuously look for ways to mature the company's product practices. This includes building a culture that encourages frequent iterations, data-informed decision-making, empowered teams, focus on delivering value, and obsession with customer experience. Find ways to complement technical expertise with expertise in user experience and business acumen It is not possible to build a great cybersecurity product without someone on the team having domain expertise. Having successfully worked across many other industries with no prior domain knowledge, I will be the first to admit that product managers cannot learn security by doing customer discovery calls. A winning combination is when someone with cybersecurity expertise is complemented by those that focus on business and user experience. This collaboration between people with different perspectives enables companies to build products that solve customer problems and grow the business while offering a great user experience. Conclusion Cybersecurity is a young field, and the product practices in the industry tend to be perceived as less mature compared to consumer space, developer tools, and other high-growing, established markets. To a degree, it is a fair take as cybersecurity companies are prone to building very complex products that can hardly be implemented without additional professional support. It is, however, important to understand and fully appreciate the layers of complexity impacting cybersecurity in unique ways. As consumer expectations are changing, people are increasingly looking for intuitive, easy-to-deploy products that can be tested without ever talking to a salesperson and understood without having to sift through libraries of documentation. The industry is getting more and more competitive, and companies built solely on the experiences of the founders, without a clear understanding of the market needs, are being displaced by those that listen, move quickly, learn fast, and most importantly - solve problems that matter. We are starting to see more and more to work together with product people who possess great domain knowledge, embracing new go-to-market strategies such as to complement their sales strategies, and continuing to form an understanding of what product management as a discipline can bring to cybersecurity. I think the next decade will present a great opportunity for savvy, customer-obsessed product leaders who are not afraid to learn about this complex space and get their hands dirty. The future of the industry is bright, and so is the future of product management. security companies hiring product managers from outside of security product-led growth It is important to keep in mind that product management in cybersecurity has a layer of complexity not seen in other industries. Product leaders in security are trying to delight users while fending off adversaries who want to harm them. This challenge is unique to security; while other industries are facing the socioeconomic, market, natural, and other risks, cybersecurity is dealing with a conscious, intelligent, creative person attempting to harm other individuals, corporations, critical infrastructure, entire countries, and the world order overall. The bad actors are invisible, unpredictable, and highly motivated, financially, and otherwise. We don’t want to think about it, but here is an interesting fact: in cybersecurity, any of the product demo requests could be a demo request from the adversary interested in getting an understanding of what parts of the product may be vulnerable. Every feature request can be from an adversary thinking many steps ahead. Every new developer hired to the company can be an implant sent by a nation-state to plant backdoors in the company’s software. This reality is hard to fully internalize but just because we don’t want to think about it, it does not become less true. Ultimately, product management is the art of delighting customers and growing business by always prioritizing the highest value work. Product leaders in cybersecurity have many more factors to consider compared to their counterparts in other industries which makes the job harder, but also so much more impactful. Also published . here