Security builder & leader

A Practitioner's Guide to Creating Cybersecurity Products

Strong technology alone doesn't make a successful security product. This guide presents the strategic questions that security product managers and startup founders should answer early, covering market segmentation, AI advantages, go-to-market strategy, pricing, delivery, customer trust, and ecosystem positioning.

A Practitioner's Guide to Creating Cybersecurity Products - illustration

If you’re working to create or improve your security product strategy, this guide will help startups and teams in established organizations.

You can also download the accompanying template to apply this framework to your own plans, available in Microsoft Word and Markdown formats.

Strategic Market Segmentation

The idea of market segmentation stems from the notion that different customer types have distinct needs. How to group customers with similar needs depends on your vision for the company and its products:

Also consider who inside the customer’s organization will evaluate, champion, and use your product. A CISO evaluates risk reduction and vendor trust differently than a security engineer assessing daily workflow fit. Both differ from a developer evaluating friction in a deployment pipeline. Your product capabilities, messaging, and sales motion all shift depending on which persona you’re building for. This distinction becomes especially important if you pursue a bottom-up adoption model, which is discussed later in this guide.

Questions on market segmentation:

Product Capabilities

Once you understand the type of customers the product will target, dig deeper into their needs, and then map them to the product’s capabilities. Think beyond generic security requirements such as data protection, threat detection, or incident response. Be more specific to understand which gaps might exist in the products currently available to relieve infosec-related pain points.

AI and Data Advantages

If your product incorporates AI capabilities, what specific advantages does it offer over rule-based detection systems? Think about a scenario in which a company offering a frontier model adds capabilities similar to your solution. Make sure you provide unique value to customers even in that scenario. Also, if your product depends heavily on third-party AI models, understand your cost structure and how it might affect your burn rate and product pricing. Consider what percentage of your value proposition would survive if that scenario materialized. The most durable advantage is often workflow integration and proprietary operational data, not the AI model itself.

The most durable AI advantage in security products often comes from proprietary data that frontier model vendors lack. Raw telemetry is relatively easy to collect, but the real moat lies in labeled threat datasets, curated detection rules, and validated ground truth. A growing customer base can also create network effects, where each new deployment improves detection accuracy for everyone, provided your product architecture supports learning across customers.

Think carefully about which data assets your company can accumulate that others will find difficult to replicate. Be honest about whether your data advantage compounds or plateaus; data advantages exhibit diminishing returns after a threshold. The critical question is whether each new customer’s data meaningfully improves the product for all customers, or whether the incremental value flattens early. Data automatically captured from customer usage, tied to specific environments, and validated by actual incident outcomes tends to be more defensible than data assembled from publicly available threat feeds.

Building this data flywheel requires earning customers’ trust. As organizations become more cautious about how vendors use their telemetry, you should be transparent about what data you collect, how you train your AI models, and what controls customers have over their data.

CrowdStrike’s Threat Graph, which aggregates correlated telemetry from all Falcon agents, illustrates this dynamic. Its detection improves with every deployment because it correlates telemetry across its entire customer base. Each new customer adds behavioral patterns and threat data that sharpen detection for all the others. A general-purpose AI model can’t replicate that feedback loop on its own because the value comes from the data, not the model.

Questions on AI and data advantages:

Designing for AI Agents

Your product’s users will likely include AI agents, not just people. For example, a customer’s automated workflow might query your product’s API to check an asset’s risk posture, then feed that data into a decision engine that prioritizes remediation. Design your APIs and automation interfaces so that AI agents can interact with your product as effectively as a human analyst using the console. Consider the role your product will play in these automated workflows, and ensure your value proposition holds up when the AI “user” is software acting on behalf of a security team.

Designing for agent users raises questions that don’t arise when your product serves only human users. How will agents authenticate to your product, and how will customers govern what those agents are permitted to do? Most vendors today rely on API keys or service account tokens that struggle with granular scoping and audit trails that agent workflows will eventually require. Getting ahead of this challenge, even modestly, can differentiate your product. Enterprise buyers increasingly expect audit trails of agent actions, rollback capabilities for automated decisions, and controls that let customers define what agents can do autonomously versus what requires human approval.

Agent users also affect your pricing and competitive positioning. If customers meter their agent workflows by API call volume, your pricing model needs to accommodate that usage pattern. When an automated workflow chains your product with several others, your differentiation can become invisible to customers. Ensure your product delivers value that is apparent in the data it returns, not only in the experience of using its console.

Questions on designing for agents:

Competitive Positioning

If you’ve spotted a customer need, others may be racing to address it. Understand who your competitors are and be realistic about your moat. Your differentiation might lie in expertise, product capabilities, or go-to-market abilities.

Outline where a competitor’s product offers more value than yours, and where you have an advantage. Decide whether you have the resources to close those gaps or whether you’ll focus on the opportunities where you’ll prevail.

Questions on competitive positioning:

Minimum Viable Product and Build Decisions

Enterprise security buyers are usually risk-averse about immature products. An MVP that works well for a design partner may still feel too raw for a formal procurement process. Design partners, mentioned in the Sales Engagement section below, can bridge this gap by validating your MVP in real environments before you bring it to the broader market.

Not everything in your product needs to be built from scratch. Focus your engineering resources on capabilities that differentiate your solution and consider integrating with established providers for commodity functions. For example, you might build your own detection engine but rely on an identity provider for authentication or an existing data platform for log ingestion. Deciding what to build, what to integrate, and what to partner on helps you ship faster without diluting your team’s focus.

Questions on MVP and build decisions:

Sales Engagement and Go-To-Market

Your decisions on market segmentation and product capabilities must account for your sales force’s reach, expertise, and motivations. In large organizations, your product might share a sales team with unrelated solutions, so consider how you’ll compete for attention and strengthen the company’s broader value proposition.

Direct Sales and Channel Strategy

If you’re planning the product’s go-to-market strategy, consider whether you can reach prospective customers directly through your company’s sales force. In some situations, a better approach might be to establish a sales channel that brings your solution to customers through a reseller. Reaching consumers and smaller clients is especially costly with a direct sales force. Building and managing a large sales organization whose members work on numerous, relatively small deals is a significant operational challenge.

If you can influence the choice of a salesperson aligned with the product, consider what security knowledge they should possess. It might be hard to find a sales expert in the specific niche your product targets. You could be better off working with a less specialized sales rep who has earned the trust of buyers through good work and relationship-building, and pair this person with a technical sales engineer.

Questions on sales and channel strategy:

Bottom-Up Adoption and Open Source

Not all security products reach customers through a traditional sales team. Some gain their first foothold when an individual user signs up for a free tier, integrates your tool into an existing workflow, or deploys an open-source component. This bottom-up adoption path can generate demand before your sales team even gets involved. The adopter might be a developer embedding your scanner into a build pipeline, a GRC analyst testing your compliance tool, or a security engineer evaluating your detection capabilities. Consider whether this model fits your solution, and how you will measure adoption using usage-oriented metrics, such as active integrations or API calls, rather than traditional pipeline stages.

Snyk demonstrated bottom-up adoption in application security. The company offered a free CLI tool that developers could integrate into their pipelines without a sales conversation. Once the tool gained traction inside organizations, Snyk’s sales team had an opening to approach enterprise buyers with proof that developers were already deriving value from the product.

If you are considering open-source as part of your go-to-market strategy, think carefully about what to open and what to keep proprietary. Open-sourcing a component can accelerate adoption by letting developers evaluate your technology without a sales conversation. However, if you give away too much in the open source version, you’ll struggle to monetize. Give away too little and the open-source project won’t attract the community you need.

HashiCorp’s experience with Terraform illustrates the tension. After years under an open-source license, HashiCorp switched to a more restrictive Business Source License, arguing that competitors were commercializing its code without contributing back. The community responded by forking the project into OpenTofu. The episode showed how difficult it is to change licensing terms once a community has built around your project.

Questions on bottom-up adoption and open source:

Design Partners and Proof of Concept

Even before your product formally enters the world, there is much to learn from discussions with prospective customers. These interactions validate assumptions regarding market segmentation and desired features. They also help identify early adopters who might be interested in testing early versions of your solution. Design partners are particularly valuable at this stage. These are companies willing to deploy early versions of your product at no cost in exchange for candid feedback on what works and what doesn’t.

Once you move beyond design partners into formal evaluations, structure your proof-of-concept engagements thoughtfully. Define success criteria upfront with the prospect and time-box the evaluation to prevent it from becoming an unpaid deployment. Ensure the POC tests your differentiated capabilities rather than generic features that your competitors also offer. A well-structured POC demonstrates value on your terms, while a poorly scoped one drains engineering resources and extends the sales process.

Questions on design partners and POCs:

The Pricing Model

Pricing your product correctly is as essential as having the right set of features and reaching customers through a skilled sales force. You need to estimate how much your customers will value the benefits of your solution and determine which budgets they have available to fund the purchase. This can be very tricky.

Consider whether consumption-based pricing aligns better with customer value than seat-based models. Will you price based on data volume processed, events analyzed, resources protected, or security outcomes delivered? How will customers predict and control costs during security incidents when usage naturally spikes?

Consumption pricing requires careful design to align revenue with customer success. If your solution reduces security incidents, does your pricing model reward that outcome or penalize it through reduced usage fees? Consider implementing cost-spike protections during incident response periods to maintain customer trust when they need your product most.

Splunk’s experience with data-volume pricing illustrates the risk. The company charged by daily ingestion volume, and Splunk acknowledged in an SEC filing that the model could push customers to limit their usage to stay within license limits. Splunk eventually introduced workload-based and entity-based pricing alternatives, but the lesson for product teams is that pricing models can negatively effect customers’ use of the product.

Price the product based on customer-perceived value, not on costs. For instance, the marginal cost of your endpoint security software might be a few cents per device; however, if the product uniquely addresses a significant pain point, the customer might pay several dollars for it. Not only does your solution need to work well for this approach to work, but your sales team needs to be sufficiently mature to understand customer needs and position your product’s benefits. You can try explaining the product’s return on investment (ROI), but I’m not a fan of this approach in the context of information security.

For salespeople to be motivated to sell your product, your pricing model must account for their compensation. This typically involves paying the salesperson commission on a deal in a way that aligns the person’s interests with the company’s. Watch out for a potential mismatch in subscription products. The salesperson’s goals focus on hitting quarterly revenue or profit targets, while your commission trickles in gradually over the years after the deal was closed.

Agent users introduce pricing challenges that don’t arise with human users. AI agents don’t occupy seats or log in through portals, and a single automated workflow can generate API call volumes that dwarf human usage patterns. If customers meter their agent workflows by volume, your pricing model needs to accommodate consumption patterns that differ fundamentally from human use. Consider whether your value metric still aligns with customer-perceived value when the “user” is software acting autonomously on behalf of a security team.

Your pricing and product strategy should also account for what happens after the initial sale. In subscription security products, retaining and expanding within existing accounts is often more valuable than acquiring new ones. Design your product to deepen its role over time through broader coverage, additional use cases, or tighter workflow integration. Customers who embed your product into their daily operations are far less likely to churn, and expansion revenue from those accounts can become a significant growth driver.

Pay attention to whether existing accounts spend more over time. Growth driven by customers discovering new uses for your product is healthy. Growth driven by switching costs that make it hard to leave is fragile, even if the revenue numbers look the same on a spreadsheet.

Questions on pricing:

Product Delivery and Operations

If you’re pursuing enterprise customers, they’ll likely have software development workflows that need to interact with or integrate with your product. In such cases, understand how deeply your product will integrate with customers’ CI/CD pipelines or DevOps processes and how best to support these requirements.

Consider how much effort it will take to deploy and maintain your product securely, while aligning with customers’ software management practices. Customers will be hesitant to commit to a product that requires complex configuration or imposes significant overhead. Implement reasonable, secure defaults, allowing customers who need more extensive customization to perform them when necessary.

Enterprise buyers increasingly expect to deploy and configure security products entirely through infrastructure-as-code tools and APIs, without relying on manual console steps. Full API coverage, where every action available in the product’s interface is also available programmatically, has become a procurement expectation for teams that manage infrastructure through automated pipelines. Similarly, many enterprises now manage security policies through version-controlled, declarative code. If your product supports these workflows, it can integrate naturally into how modern teams operate. If it requires manual configuration via a web interface, it may encounter resistance.

Understand the initial and ongoing effort needed to achieve the product’s full potential. For instance, an AI guardrails tool that needs frequent tuning when customers add new data sources will introduce unwelcome friction. Customers need to understand what time they will need to devote to get the most value from your solution. You also need to determine which ongoing support or maintenance tasks your firm will need to provide (e.g., software upgrades, troubleshooting, performance tuning, and so on).

You should also determine what tasks your company’s staff will need to perform when deploying the product for a new customer. With some solutions, this is as simple as enrolling users via your spiffy web-based SaaS portal or, better yet, enabling SAML and SCIM support for user provisioning. More sophisticated products might demand a formal project, for instance, if you need to integrate a malware sandbox with the client’s gateways and devices.

Security products that require complex integration will need to be deployed by a well-staffed team of skilled consultants or implementation specialists. If you’re working at a software company without a strong services component, this might become a bottleneck for signing clients. If that’s the case, either build the appropriate team, partner with another company to provide this service, or adjust product plans to rely less on the human element for deployment.

Consider where and how your product will be hosted. Enterprise customers may need deployment within specific geographic regions for data residency or within their own environments for sensitive workloads. Determine how each client’s data and application instances will be isolated. Some clients will welcome the ease of a SaaS deployment; others will demand a dedicated instance or on-premises installation. The more sensitive the data your product handles, the greater the likelihood that a customer will insist on controlling where it resides.

Questions on delivery and operations:

Earning Customers’ Trust

Companies purchasing cybersecurity products hold their vendors to a higher security standard than most other suppliers. Buyers expect that you practice what you preach, and their third-party risk management processes will scrutinize your security posture before a deal can close. Understanding these purchasing workflows early will help you remove friction from the sales cycle, especially if you are a young company without an established reputation.

Determine the security program you need to build and calibrate it to your customers’ expectations and your ability to fund it. For a startup, this might mean using compliance automation platforms to accelerate initial audit readiness or engaging a fractional security leader to stand up foundational controls. As your company grows, your program should mature alongside your customers’ expectations.

A SOC 2 report has become table stakes for selling to enterprises. Beyond that baseline, consider which additional frameworks are relevant to your target market and product:

If you plan to sell to customers in the EU or in regulated industries globally, prepare for an expanding regulatory landscape. The EU AI Act imposes documentation and governance requirements on AI systems. DORA mandates operational resilience testing for vendors serving the EU financial sector. NIS2 requires incident notification within a specific timeline and extends supply chain security obligations. Data sovereignty has also shifted from a preference to a requirement in financial services, healthcare, and government sectors, where buyers may require customer-managed encryption keys and deployment options that prevent vendor access to plaintext data.

Buyers of security products will also scrutinize how you build and ship your own software. Be prepared to provide:

The SolarWinds Orion compromise illustrates why buyers now treat supply chain security as a requirement rather than an aspiration. Attackers infiltrated the vendor’s build pipeline and inserted malicious code that shipped to roughly 18,000 organizations through legitimate software updates. The incident prompted Executive Order 14028, which mandates SBOMs and secure development attestations from vendors selling software to the US federal government.

Publishing a vulnerability disclosure policy signals maturity and openness to the security community. As your company grows, a bug bounty program can further demonstrate confidence in your product’s security posture.

Questions on earning customers’ trust:

Platform Strategy and Ecosystem Positioning

Will your solution integrate with existing security platforms, or do you plan to become a platform that other tools integrate with? Becoming a platform is highly attractive because it creates a sustainable competitive advantage, but getting there is rare. Be realistic about your capabilities and consider whether you can provide more value as a best-of-breed point solution or as a component in another vendor’s platform.

Your integration strategy affects your go-to-market strategy. Enterprise buyers often prefer to procure security products through cloud marketplaces, where purchases can draw down existing cloud spending commitments. Listing on these marketplaces can provide access to committed cloud budgets that customers need to spend, making marketplace presence a structural advantage rather than merely a convenience. Beyond marketplace presence, customers expect your product to work with the tools their teams already depend on, such as:

Platform vendors are embedding capabilities such as automated triage and investigation into their core offerings. This raises the bar for what a standalone product must deliver to justify its place in the tech stack.

Palo Alto Networks’ platformization strategy illustrates the scale of this challenge. The company has acquired more than two dozen security firms and consolidated them into unified platform pillars covering network security, cloud security, and security operations. Its CEO stated that point-solution vendors will be subsumed by platform plays over the next decade. When a single vendor offers network security, cloud security, and security operations under one contract, a startup competing in any one of those categories needs a clear answer for why its standalone product justifies a separate purchase.

Some startups respond to this pressure by integrating with a major platform rather than competing against one. This path isn’t without its own risks. Integration gives you distribution and credibility with that vendor’s customer base, but it also creates dependency. The platform vendor may eventually build your capability natively or acquire a competitor to fill the same gap.

Elastic’s experience with AWS shows how quickly a platform partner can become a competitor. After Elastic changed its license to prevent AWS from offering a competing managed Elasticsearch service, AWS forked the project into OpenSearch and integrated it tightly with its cloud platform. AWS’s distribution advantage split the customer base.

Questions on platform strategy and ecosystem:

Team and Execution Capability

Your strategy is only as strong as your team’s ability to execute it. Customers, investors, and design partners evaluate the people behind a product, especially at earlier stages if the startup. Understanding where your team is strong and where it has gaps helps you make realistic commitments and hire intentionally.

Your team’s expertise needs to map to your product’s value proposition and the buyers you’re trying to reach. A founder who built detection systems at a major platform brings different credibility than one with 20 years of enterprise sales experience, and your product strategy likely needs elements of both.

Map your strategy’s requirements against your team’s current capabilities. If your plan calls for enterprise sales motion but your team is engineering-heavy, you need a plan to close that gap through hiring, advising, or partnering. If you need ML pipeline expertise but have mostly backend engineers, that affects your roadmap and your timeline.

Questions on team and execution capability:

Bringing It All Together

Building a security product requires you to think simultaneously about technology, customers, sales dynamics, pricing, trust, and ecosystem positioning. No single person will have all the answers, which is why the questions throughout this guide are designed for conversations with your colleagues, your sales team, and your prospective customers. The best product strategies I’ve seen came from teams that were honest about what they didn’t yet know and used that openness to learn faster than their competitors.

To see how these decisions flow from market selection through ecosystem positioning, refer to the diagram below. If you’d like a condensed reference you can keep nearby while applying this framework, the Practical Tips for Creating and Managing Security Products cheat sheet distills the essential guidance into a single page. You can also download the accompanying template to apply this framework to your own plans, available in Microsoft Word and Markdown formats.

Security Product Decision Cascade

More on
Product ManagementArtificial Intelligence
After 6+ years building the security program at Axonius from startup to scale, I'm exploring what's next. As I work on independent projects, I'm open to CISO or security product leadership roles where technical depth enables business growth. To talk, reach out on LinkedIn or email me at my first name at my last name dot com.
20 min to read
March 4, 2026

About the Author

Lenny Zeltser is a cybersecurity executive with deep technical roots, product management experience, and a business mindset. He has built security products and programs from early stage to enterprise scale. He is also a Faculty Fellow at SANS Institute and the creator of REMnux, a popular Linux toolkit for malware analysis. Lenny shares his perspectives on security leadership and technology at zeltser.com.

Learn more →