Established enterprises as well as startups have much to consider when deciding how to build and launch a security solution that makes sense for their business and customers. While you can employ a variety of formal tech strategy frameworks, the following lightweight approach offers a reasonable starting point for defining security product plans by posing several fundamental questions. This common sense methodology is based on my experience of building infosec solutions, but it is broad enough to apply to other types of products.

Strategic Market Segmentation

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

Geographic segmentation recognizes that product requirements or go-to-market plans for customers in one country might be different from those in another. For instance, it's not unusual for a startup to begin by focusing on prospective clients in its own locale—be it a city, state or country that the firm's founders know well—for proof-of-concept deployments and then expand to a larger market, such as the United States.

Another way to segment the market is to look at different industries where prospective customers might reside. For example, a company that's building an anti-ransomware product might perceive the need for such a solution among hospitals or law firms and focus on this vertical.  Prospective clients in other verticals, say financial services firms, might value such a product differently and might seek different capabilities that would overextend the startup's limited resources.

Yet another approach to market segmentation involves considering the size of a customer, perhaps in terms of the number of endpoints, offices or employees that require protection. Small and mid-sized businesses (SMBs) tend to have different security needs and price expectations than more sophisticated enterprises. Not only does the size of the customer's' business influence the product's desired features, but also the expected deal size affects the ability to build and motivate a sales force that can reach prospective clients.

The questions to ask in relation to market segmentation include:

• What market segments are we targeting?
• How are they similar and different?
• How will we reach prospective customers?

Product Capabilities

Once you understand the type of customers the product will be targeting, it's time to dig deeper into understanding their needs, 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.

If the product focuses on better network defenses, what advantages does it compare to existing firewall or Unified Threat Management (UTM) technologies? If your firm's expertise is in security data analytics, why should customers value your approach over their existing Security Information and Event Management (SIEM) deployment? If you're proposing a new approach to fighting malware, how does your product fit with established anti-virus solutions?

You should also consider how your product plans compare to those of other security firms that might be competing with you. If you've spotted a customer need, there is a chance that other individuals and companies are also working feverishly to address it. Understand who your competitors might be and determine how your solution might be different than theirs.

Outline the scenarios where a competitor's product might offer more value than yours. Along the same lines, determine where your firm might have an advantage. Develop your plans to build upon your strengths. Decide whether you have the resources to close the gap in those scenarios where you competitors might be stronger, or whether you will focus on opportunities where you will most likely prevail.

In addition, consider what is the smallest set of features you need to build into your solution to attract your initial customers. The advantages of starting out with such a minimum viable product (MVP) include the ability to start generating revenue, earning early reference clients and receiving real-world feedback related to your business strategy and product roadmap.

Ask yourself questions such as:

• What are your solution's key benefits?
• How unique is the value proposition?
• What capabilities should form the initial release?

Sales Engagement

Your decisions related to market segmentation and product capabilities need to account for the reach, expertise and motivations of your sales force. Take the time to understand how the sales team is set up and, if applicable, contribute to the team's design on the basis of your understanding of the security market and its participants.

What can you learn about customers' product expectations or reception based on sales activities to date? In an established firm, such interactions could have been conducted by the formal sales team. In a startup, even if the sales team doesn't exist yet, informal sales conversations might have involved you, the company's founders or your other colleagues.

In large organizations, the product you're building might not have its own dedicated sales force. Instead, you could be sharing the sales team with other products, some of them potentially unrelated to security. This sometimes means that your product will be competing for sales people's attention with other solutions that your organization offers. Understand such internal dynamics and consider how you might be able to encourage sales folks to focus on the products important to you and to your company. Give thought to how the capabilities of your product might strengthen the value proposition of the other products your company has been selling.

If you're planning the go-to-market strategy for the product, consider whether you'll be able to reach prospective customers directly using your company's own sales force. A better approach in some situations might be to establish a sales channel that brings your solution to customers via a reseller or OEM model. Reaching consumers and SMB clients is especially difficult using a direct sales force due to the challenges of building and managing a large sales organization whose members tend to work on numerous, but relatively small deals.

If you can influence the choice of a salesperson who will be aligned to the product, consider what security knowledge he or she should possess. It might be hard to find a sales expert within the specific infosec niche that your product is targeting. 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.

Even before your product is released into the world, there is much to learn from sales discussions with prospective customers. These interactions validate assumptions regarding market segmentation and desired features. They also help identify early adopters that might be interested in testing early versions of your solution.

Seek to answer the following questions:

• In which markets has the sales force gotten traction so far?
• What's prospects' negative feedback regarding product ideas or prototypes?
• What capabilities get customers most excited?

The Pricing Model

Pricing your product properly is as essential as having the right set of features and being able to reach customers through a skilled sales force. You'll need to estimate how much your customers will value the benefits of your solution and determine what budgets might be available to them to fund the purchase. This can be very tricky.

Consider whether you're going to charge customers an initial one-time licensing fee with recurring maintenance fees, or whether you'll follow a subscription model. It often makes sense to align the timing of your expenses with the timing of your revenues. If your solution has recurring monthly costs (for instance associated with storing customer's data or hosting your application) then it makes sense to position your product as Software as a Service (SaaS) and charge predictable, monthly or annual fees. Even with recurring feels, you might need to charge initial installation or activation fees to cover the associated costs.

Of course, you'll need to account for customers' preferences and constraints when deciding whether to charge one-time or recurring fees. Some customers might have a fund for one-time costs that are considered capital expenses (CapEx), while others might not have the ability to put up a lot of money for the initial purchase and will need to pay monthly out of their operating expense (OpEx) budget.

Pricing the product requires a firm understanding of your initial and ongoing costs. You could take your costs, mark them up by the expected profit margin, and come up with a price. Be careful to consider this only your minimum price and use it as a sanity check on deals where discounts might need to be offered. Ultimately, the price should be based on how much the customer values the solution's benefits.

Price the product based on customer-perceived value, not on costs. For instance, the marginal cost of your anti-malware software might be a few cents per endpoint, but if the product addresses a significant pain point in a unique way, 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 return on investment (ROI) of the product, 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 needs to account for compensating them for their efforts. This is typically done by paying the sales person commission for a deal in a manner that aligns the person's interests with those of the company. Watch out for a potential mismatch in subscription products where the sales person's goals are focused on hitting quarterly revenue or profit targets, but your commission trickles in gradually on a monthly basis for years after the deal was closed.

Questions to ask of yourself:

• How much should you charge for the product?
• What are the associated initial and recurring costs?
• Is revenue aligned to costs and incentives?

Product Delivery and Operations

Understanding the intricacies of installing and supporting the product are critical to the success of the overall solution. For example, customers might prefer the ease of rolling out an agentless forensic analysis tool to the alternative that requires installing the software on every endpoint in the enterprise. On the other hand, the capabilities of the tool that runs locally on might surpass the agentless solution. Understand your customers' priorities and strike the right balance between functionality and ease-of-use when designing the product.

Furthermore, consider what effort is required on an ongoing basis to achieve the product's full potential. For instance, a change detection tool might need regular tuning to avoid alarms that arise after routine system maintenance. Customers need to understand what time they will need to devote to get the most value from your solution. You also need to determine what ongoing support or maintenance task your firm will need to provide (e.g., upgrading software, troubleshooting problems, updating signatures, etc.).

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 a simple as enrolling users via your spiffy web-based SaaS portal. More sophisticated products might demand a formal project on the customer's premises, for instance if you need to integrate your malware sandbox with the client's email and web gateways.

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 in a software company that doesn't have a strong services component, this might become your bottleneck to signing up clients. If that's the case, either plan to build the appropriate team, partner with another company to provide this service, or adjust product plans to avoid relying as much on the human element for deployment.

If your product includes back-end software that runs in a datacenter, consider whether these components will be hosted outside the customer's environment, or whether you will allow customers to deploy your software into their own data center. If you'll be doing the hosting, determine how each client's application instances or data will be separated from each other. Also understand what audits, certifications and security attestations for your infrastructure and application customers might require.

Some clients will welcome the ease of deploying a SaaS application hosted by you in an external cloud; others might demand their own dedicated instance. The more sensitive the data that your product is handling, the greater the need that an enterprise customer will want their own, local deployment.

Ask yourself these questions:

• What is product deployment like?
• What ongoing support is necessary?
• What are the staffing requirements?

Wrapping It Up

Building a product is a risky, stressful and ultimately fulfilling endeavor. The methodology above proposes some common-sense questions you should ask yourself, your colleagues and your customers when preparing to build a security solution. There is certainly more to be said about each aspect of this aspect of product management, but answering these questions offers a reasonable starting point for the project. The following diagram summarizes this approach. For additional guidance related to this framework, take a look at my Practical Tips for Creating and Managing New Information Technology Products.