6 common challenges facing cybersecurity teams and how to overcome them

Image Credits: Esa Hiltula / Getty Images

Building products and companies in cybersecurity is not an easy task because in many ways, the industry behaves differently from others. To start, it is very crowded, with hundreds and thousands of undifferentiated solutions promising to solve all security problems and more often than not, falling short of their promises. Moreover, it is an incredibly dynamic space with the landscape sometimes shifting overnight.

As a product leader, I meet many entrepreneurs and startup founders and see over and over how the vast majority get slowed down by the same types of problems. In this post, I am looking at six challenges of building products in cybersecurity and ways to overcome them.

1. The challenge of customer discovery

In most industries, buyers and end users are open to talking to vendors because they recognize that software providers are there to identify their problems, pain points and inefficiencies, and build solutions that remove them. The same, unfortunately, cannot be said about cybersecurity where few leaders (Chief Information Security Officers or CISOs) or practitioners are open to having transparent conversations with strangers. There are several reasons why this is the case:

• Security teams are chronically overextended and understaffed, and therefore cannot prioritize talking to vendors over improving the security posture of their company.
• CISOs and practitioners alike are inundated by vendors who reach out from all fronts — calls, emails, social media messages and conferences, to name a few.
• Product managers and founders tend to ask the same types of questions that an adversary would (what products the company is using, where their gaps are, etc.) — questions that can only be answered if there is a level of trust between parties.

All this makes the lives of cybersecurity product leaders incredibly hard as it essentially makes them unable to do customer discovery, learn about pain points and brainstorm potential solutions. Here are some of the ways to address this:

• Build relationships with CISOs and security practitioners by attending events, workshops and webinars.
• Ask existing customers, VCs and design partners for introductions to people in their network.
• When PMs get an opportunity to talk to security people, use that time to ask questions and be curious, instead of pitching their products and solutions.

2. Using traditional product management frameworks

A lot of what is known as “product management best practices” comes from the hyper-growth experiences of consumer Silicon Valley companies such as Meta, Google, Instagram, and the like. The idea is that founders and product leaders can subsidize user growth, leverage referrals, growth loops and virality to scale the number of daily active users (DAU) quickly, and then figure out monetization. Although in theory this approach sounds quite compelling, it breaks down when one tries to apply it in cybersecurity. The vast majority of what we think of as cybersecurity is based on enterprise sales with long product evaluation, slow adoption cycles and a heavy reliance on trust for purchasing.

Although there are no easy ways to deal with this problem, I have found the following to be a useful mental model for thinking about solutions:

• Start with your ideal customer profile and build a deep understanding of their needs, pain points, use-cases they want to see addressed, ability to influence the buying process and so on,
• Assume that many of the so-called “best practices,” especially those that come from B2C space, are either not going to work or will have a different shape when implemented in security (this applies to things like growth loops, product-led growth and so on),
• Adopt an evidence-based approach that enables you to test and validate your hypothesis and find what works for your organization.

3. Over-optimizing technology and under-optimizing the business model

Because cybersecurity requires deep domain expertise, the vast majority of the founders and product leaders in the field tend to have a technical background. This, combined with the objective need to ensure that technology is well designed, optimized, and works as intended, tends to necessitate putting a lot of time and effort into building a good product. Since the time PMs have to tackle problems is finite, and conflicting priorities make it hard to do everything at once, the business side of the product tends to suffer.

In practical terms, this means that in some cases, the business model the company is trying to pursue is not viable from day one, while in others, the unit economics doesn’t leave any room for profitable margins, or the support costs are going to scale with the company reducing the customer lifetime value. Understanding the underlying business model and the economics of building a product or providing a service can help product leaders avoid costly mistakes.

Here are some of the ways to address this:

• Before building the product, use a simple spreadsheet to model metrics such as customer acquisition costs, customer lifetime value, average order size, cost of goods sold, and gross margin, to name a few, to make financial sense.
• Identify scenarios in which the actual performance under these metrics puts the business model of the company into question.
• State assumptions as to what each of these numbers will look like when the product is launched and actively used by the customers.
• Compare the actual metrics against the projections to validate (or invalidate) assumptions, identify red flags early and further optimize the business model.

4. Oversimplifying the buying journey

It is common, especially for inexperienced product managers and first-time founders, to oversimplify the buying journey for their product. Some companies think “we just need to convince a CISO that we are better than alternative options” while others go another route and talk about “just doing product-led growth and going bottom-up.” Unfortunately for both, neither is how security products are actually purchased. The mechanics will heavily depend on the specific product and a specific market segment, but it is common for hands-on practitioners, CISOs, compliance, finance and purchasing departments to evaluate new tools from their unique lenses. For some products, the list may include chief technology officers (CTOs), software developers and engineering managers, and others. Different parties will have different roles and levels of influence on the final decision depending on the organization’s size, structure, power dynamics and many other factors.

Although there are no easy ways to deal with this problem, I have found the following to be a useful mental model for thinking about solutions:

• Map the customer’s buying journey and identify who is involved in the purchasing process, what they care about, what their influence is and what angles they are looking at the problem from,
• Get all of this information in one place, and
• Understand what your product and the company need to offer to each party to satisfy their requirements.

5. Complex and custom-fit security for every organization

Every organization’s security environment is different, and therefore every company does security in its own way. This means that workflows, playbooks, risks, attack vectors, and what constitutes “suitable security coverage” will vary widely from one organization to another. This complexity and variability make the lives of product leaders quite hard: Every customer they talk to will inevitably bring their own “must have” feature requests. This can be overwhelming, especially because from the outside, many of these organizations with unique needs will fall under the same customer profile.

Building everything prospects ask is not possible. Not only would it result in Frankenstein products, but also no company has enough resources to do that. On the other hand, not responding to the needs customers are being vocal about can result in issues with adoption or high churn rates.

To address this dilemma, customers should:

• Look for ways to design their products as building blocks and make them extendable by using open APIs and the latest technical design principles.
• Understand the willingness and the ability of customers in this particular segment to tailor out-of-the-box products to their needs.
• Do thorough customer research to understand what is the 80% of product functionality needed by all customers, and what is the other 20% that users can do on their own (this assumes that there are ways for them to do it).

6. The inability to easily move up- and down-market and the resulting need to pick core focus early

Naturally, some types of problems are only seen in consumer or enterprise spaces, while others span all types of customers at once. For those that are common across consumer, small- and medium-sized businesses (SMBs), and enterprise clienteles, it is common that a company would penetrate one of the segments first, and then seek adoption across others. Think about productivity tools as an example: People, small businesses and large corporations all need to manage tasks and projects. While the scale and some nuances do vary, we often see that what distinguishes a consumer-focused task manager from an enterprise-focused one are multi-tenancy and multi-user support, rules-based access control, API access, single sign-on and access to audit logs.

Although everyone needs cybersecurity, what they see as “security” varies. People are notorious for not wanting to adopt (not to mention having to pay for) anything that introduces friction. Small- and medium-sized businesses only now are starting to realize that they do need security. For SMBs, security means having an “everything-in-one solution.” For enterprises, on the other hand, security is about advanced capabilities that are API-first and much more specialized than SMB-focused tools. A product that started in the consumer cannot typically move up the market, and vice versa. An enterprise solution for network detection and response (NDR), for example, cannot be simplified to the consumer level because consumers don’t need or care about an NDR.

To address this reality,

• Founders and product leaders need to understand their target market, and the kind of solutions they are looking for, and
• Startups need to commit to solving a problem for a segment of the market while realizing that with few exceptions, they cannot hope for cross-customer segment mobility.