--- # Security Product Strategy Guidelines for AI Assistants # # Author: Lenny Zeltser # Copyright (c) 2026 Lenny Zeltser. This copyright covers the guidance in this file; # any content you create using this guidance is entirely yours. # # This file encodes strategic knowledge for evaluating and creating # cybersecurity products, derived from Lenny Zeltser's articles on # https://zeltser.com. # # URL PATHS: All paths in this file are relative to baseUrl. # Example: "/media/archive/file.md" resolves to "https://zeltser.com/media/archive/file.md" title: "Security Product Strategy Guidelines for AI Assistants" version: "1.1.0" author: "Lenny Zeltser" date: "2026-04-13" license: "Copyright (c) 2026 Lenny Zeltser" baseUrl: "https://zeltser.com" articleUrls: - "/security-product-creation-framework" - "/smb-security-product-strategy" - "/endpoint-security-startup-questions" - "/new-product-management-tips" - "/security-product-management-large-companies-vs-startups" - "/what-is-security-product-manager" - "/low-price-as-a-security-product-differentiator" - "/designing-for-humans-and-ai" - "/security-startups-first-impression" - "/securing-software-products" - "/what-platform-means-cybersecurity" # Template metadata # From the template's "About this Document" section: # "This security product planning template was created by Lenny Zeltser... # Copyright (c) 2026 Lenny Zeltser. This copyright covers the template itself. # Any content you create using this template is entirely yours." template: title: "Template for Planning a Strategy for a New Cybersecurity Product" author: "Lenny Zeltser" license: "Copyright (c) 2026 Lenny Zeltser" downloadUrl: "/media/archive/security-product-strategy-template.md" wordTemplateUrl: "/media/archive/security-product-strategy-template.docx" # MCP Server Metadata mcp: toolPrefix: "product" privacyStatement: > These tools return strategic guidelines to your AI for local analysis. Your product plans are never sent to this server. fallbackUrl: "https://zeltser.com/security-product-creation-framework" # ============================================================================ # Framework Sections # Each maps to a template section with principles, strategic questions, # pitfalls, and examples extracted from the articles. # ============================================================================ framework: sections: - id: "market_segmentation" name: "Strategic Market Segmentation" purpose: "Define target segments and customer personas" source: "/security-product-creation-framework" principles: - "Segment by geography, industry, and size to prioritize where to compete first" - "Identify the personas who evaluate, champion, and use the product" - "Deal size determines the viable sales model — low deal sizes cannot support expensive direct sales" - "Different segments have different security needs and price expectations" - "Reaching consumers and smaller clients through a direct sales force is costly" strategicQuestions: - "Which geographic, industry, and size-based segments will you target first?" - "How do security needs and price expectations differ across those segments?" - "Does your expected deal size support the sales force needed to reach those customers?" - "Which personas will evaluate, champion, and use your product, and how do their priorities differ?" - "How will you reach prospective customers in each market segment?" pitfalls: - "Trying to serve every segment at once instead of focusing on a beachhead" - "Ignoring how deal size constrains viable sales models" - "Treating all personas the same when CISOs, engineers, and developers have different priorities" - "Assuming enterprise needs scale down to SMB without fundamental changes" - id: "product_capabilities" name: "Product Capabilities" purpose: "Define what to build, how AI creates advantage, and competitive positioning" source: "/security-product-creation-framework" principles: - "Focus engineering resources on capabilities that differentiate your solution" - "Enterprise security buyers are risk-averse about immature products" - "The smallest feature set that attracts initial customers must still meet enterprise confidence thresholds" - "Integrate or partner for commodity functions rather than building everything" strategicQuestions: - "What specific pain points does our product address that current solutions miss?" - "What is the smallest feature set that will attract initial customers?" - "Which capabilities will we build ourselves, and where will we integrate or partner?" pitfalls: - "Building too many features before validating core value with real customers" - "Trying to build everything in-house rather than integrating commodity functions" - "Confusing technical novelty with customer value" subsections: - id: "ai_data_advantages" name: "AI and Data Advantages" principles: - "The most durable AI advantage often comes from proprietary data that frontier model vendors lack" - "Data moats compound with each customer when architecture supports learning across deployments" - "Early data advantages can exhibit diminishing returns — be honest about whether your data advantage compounds or plateaus" - "Data automatically captured through customer usage is more defensible than data assembled from public feeds" - "If a frontier model vendor adds similar capabilities, workflow integration and proprietary operational data provide the most durable value" strategicQuestions: - "How does our AI advantage hold up if a frontier model vendor adds similar capabilities?" - "What proprietary data can we accumulate that others will find difficult to replicate?" - "What percentage of our value proposition survives if a major AI vendor builds similar features?" pitfalls: - "Depending entirely on third-party AI models without proprietary data differentiation" - "Overestimating the defensibility of model fine-tuning without unique data" - "Ignoring the cost structure implications of dependency on third-party AI models" examples: - point: "CrowdStrike's Threat Graph correlates telemetry across its entire customer base — each new deployment adds behavioral patterns that sharpen detection for all others, a feedback loop a general-purpose AI model cannot replicate on its own" source: "/security-product-creation-framework" - id: "ai_agent_design" name: "Designing for AI Agents" principles: - "Products will increasingly be consumed by AI agents, not just people" - "APIs and automation interfaces should be designed so agents can interact effectively" - "Dedicated agent interfaces outperform repurposed REST APIs, which impose overhead through verbose schemas, unnecessary response fields, and multi-call workflows that agents must chain for simple tasks" - "Agent authentication requires moving beyond API keys to granular scoping and audit trails" - "Enterprise buyers expect audit trails of agent actions and rollback capabilities" - "Agent usage patterns differ from human users and affect pricing model design" strategicQuestions: - "Can AI agents interact with our product as effectively as human analysts?" - "How will agents authenticate, and how will customers govern what they can do?" - "Does our pricing model accommodate agent consumption patterns?" pitfalls: - "Designing only for human users and treating agent access as an afterthought" - "Relying on API keys without granular scoping for agent workflows" - "Ignoring that agent users affect pricing models" - "Exposing an existing REST API and calling it agent-ready when agents need purpose-built interfaces with fewer calls and selective response fields" - id: "competitive_positioning" name: "Competitive Positioning" principles: - "Be realistic about your moat — differentiation may lie in expertise, product capabilities, or go-to-market abilities" - "Decide whether you have the resources to close competitive gaps or should focus where you will prevail" - "Honest gap analysis is more valuable than optimistic assessments" strategicQuestions: - "Where does a competitor offer more value, and where do we have an advantage?" - "What specific pain points does our product address that current solutions miss?" pitfalls: - "Overestimating your moat" - "Ignoring adjacent competitors who could expand into your space" - "Focusing on feature lists instead of customer outcomes" - id: "usability" name: "Ease of Use as Differentiator" principles: - "Prompting the user should be the last resort — ideally the user forgets the product is installed" - "Intuitive design makes products usable without a manual and reduces time to value" - "Intelligent defaults let the product make informed decisions on the user's behalf whenever practical" - "Unobtrusive design integrates security into existing workflows rather than creating new ones" - "Ease of use becomes a competitive advantage when incumbents are complex by design" - "AI coding assistants commoditize visual polish, so usability differentiation depends on how well the interface fits each persona's workflow" - "Products that present the right interface to each persona create a defensive moat because a competitor must win over every role simultaneously to displace them" strategicQuestions: - "Can a new user achieve value within their first session without extensive training?" - "Have we designed for the busiest user, not the most technical one?" - "Do our defaults work for the common case while remaining configurable for edge cases?" pitfalls: - "Equating simplicity with fewer features rather than better design" - "Designing for power users and assuming others will adapt" - "Adding configuration options instead of making intelligent default decisions" examples: - point: "When a security product makes informed decisions on the user's behalf, naive users are prevented from weakening security, and all users are encouraged to keep the product active" source: "/designing-for-humans-and-ai" - id: "sales_gtm" name: "Sales Engagement and Go-To-Market" purpose: "Plan how to reach and convert customers" source: "/security-product-creation-framework" principles: - "Sales model must match deal size — small deals cannot support expensive direct sales teams" - "Understanding past traction helps identify repeatable sales patterns" - "Channel partners may be more effective than direct sales for smaller deal sizes" strategicQuestions: - "Where has our sales team gained traction, and what drove those wins?" - "Can we reach customers directly, or is a channel partner more effective for our deal size?" pitfalls: - "Hiring an expensive enterprise sales team before validating product-market fit" - "Expecting channel partners to sell without enablement and support" subsections: - id: "bottom_up" name: "Bottom-Up Adoption and Open Source" principles: - "Some products gain their first foothold through free tiers or open-source components" - "Measure adoption using usage-oriented metrics such as active integrations or API calls" - "Open-sourcing can accelerate adoption, but giving away too much undermines monetization" strategicQuestions: - "Does a bottom-up adoption model fit our solution, and how will we measure organic usage?" - "If we open-source a component, what will we keep proprietary to sustain monetization?" pitfalls: - "Open-sourcing so much that there is nothing left to monetize" - "Measuring downloads instead of active usage" - id: "design_partners" name: "Design Partners and Proof of Concept" principles: - "Discussions with prospective customers validate assumptions about segmentation and features" - "Define success criteria upfront and time-box evaluations" - "Ensure POCs test differentiated capabilities rather than generic features" strategicQuestions: - "What objections or concerns have prospects raised about our product ideas?" - "How will we structure POCs to demonstrate differentiated value within a defined timeframe?" pitfalls: - "Running POCs without defined success criteria" - "Letting POCs test generic features that competitors also offer" - id: "first_impressions" name: "First Impressions and Credibility" principles: - "Security buyers default to skepticism — establishing credibility takes deliberate effort" - "Research prospects before initial contact to demonstrate that the relationship matters" - "Signal relevant domain experience early to give the listener a reason to take you seriously" - "Customize elevator pitches to the listener's specific needs rather than delivering a generic statement" - "Clarify the nature of your product and how it differs from similar solutions the listener may know" strategicQuestions: - "Can you articulate your product's value in terms specific to this prospect's situation?" - "What credibility signals can you lead with — relevant experience, shared connections, industry reputation?" - "Does your elevator pitch explain what your product does and does not do, rather than relying on vague claims?" pitfalls: - "Opening with 'Tell us about yourself' instead of demonstrating you prepared for the conversation" - "Attempting to educate the prospect about industry-wide threats they already understand" - "Using generic buzzwords ('AI-powered', 'next-gen') instead of explaining specific capabilities" examples: - point: "Briefly touching upon relevant strengths and experience at the start of a conversation sets the tone for the rest of the discussion" source: "/security-startups-first-impression" - id: "pricing" name: "The Pricing Model" purpose: "Price based on customer-perceived value, not costs" source: "/security-product-creation-framework" principles: - "Price based on customer-perceived value, not marginal cost" - "Consumption-based pricing may align better with customer value than seat-based models" - "Products that reduce security incidents must ensure pricing does not penalize that outcome" - "Cost-spike protections during incident response maintain customer trust" - "Pricing structure must support sales compensation that motivates the team" - "Agent consumption patterns differ from human users and require pricing adaptation" - "Retaining and expanding within existing accounts is often more valuable than new acquisition" strategicQuestions: - "Does our pricing model reward customers when our product reduces their risk?" - "How will customers predict and control their costs, especially during incidents?" - "Are we pricing based on customer-perceived value, not just our costs?" - "Does our pricing structure support sales compensation that motivates our team?" - "How does our pricing model work when AI agents are consuming our product?" - "How will we retain existing customers and expand within their accounts over time?" pitfalls: - "Pricing so low that it signals low quality or inability to sustain the business" - "Seat-based pricing that penalizes customers for successful security outcomes" - "Consumption pricing without cost-spike protections during incidents" - "Mismatched subscription pricing and sales compensation timelines" subsections: - id: "agent_pricing" name: "Pricing for AI Agent Consumption" principles: - "Agent consumption patterns differ from human usage in both volume and pattern, not just in scale" - "When automated workflows chain multiple products, differentiation can become invisible to the customer who pays the bill" - "Value must be apparent in the data returned, not only in the console experience that agents never see" - "The value metric should still align with customer-perceived value when the user is software, not a person" strategicQuestions: - "How does a single automated workflow's API call volume compare to typical human usage, and does our pricing account for that difference?" - "If an agent consumes our product as one step in a larger workflow, what makes our contribution visible and valued?" - "Does our value metric still make sense when the 'user' is an AI agent that never logs into a dashboard?" - "How will customers predict costs when agent-driven usage patterns are less predictable than human ones?" pitfalls: - "Applying human-usage pricing assumptions to agent workloads without modeling actual consumption patterns" - "Charging per seat when agents do not occupy seats" - "Assuming differentiation visible in a UI will also be visible through an API" examples: - point: "Low price can be a deliberate strategy (loss leader, freemium, good-enough tier) but must be sustainable and not signal poor quality" source: "/low-price-as-a-security-product-differentiator" - id: "delivery" name: "Product Delivery and Operations" purpose: "Plan integration, deployment, hosting, and support" source: "/security-product-creation-framework" principles: - "Products must fit into existing CI/CD and DevOps workflows without adding friction" - "Complex configuration and significant overhead deter customer commitment" - "Reasonable, secure defaults reduce deployment friction" - "Infrastructure-as-code support and full API coverage are increasingly procurement prerequisites" - "Policy-as-code workflows let customers manage security policies through version-controlled code" - "Data residency requirements may dictate deployment options and customer isolation" - "Clear delineation of support responsibilities prevents post-sale friction" strategicQuestions: - "How deeply will our product integrate with customers' CI/CD and DevOps workflows?" - "What effort is needed to deploy, configure, and maintain our product over time?" - "Do we have the staff to handle complex customer implementations at scale?" - "Can we offer hosting options that meet customers' data residency requirements?" - "Can customers deploy and configure entirely through infrastructure-as-code and APIs?" - "Does our product support policy-as-code workflows?" - "What are the responsibilities between our team and the customer for monitoring, upgrades, and support?" pitfalls: - "Requiring manual console steps when enterprises expect IaC support" - "GUI-only policy management viewed as operational risk by code-first teams" - "Underestimating the staffing needed for complex customer implementations" - id: "trust" name: "Earning Customers' Trust" purpose: "Build security credibility and compliance posture" source: "/security-product-creation-framework" principles: - "Security vendors are held to higher security standards than most other suppliers" - "Buyers expect you practice what you preach — third-party risk management will scrutinize your posture" - "SOC 2 has become table stakes for enterprise security vendors" - "AI governance, data privacy regulations, and industry-specific certifications provide differentiation" - "SBOMs, signed build artifacts, and secure development practices reduce sales cycle friction" - "Vulnerability disclosure policies signal maturity and openness" - "Data sovereignty has shifted from preferred to mandatory in regulated sectors" strategicQuestions: - "What security assurances will buyers require when purchasing our product?" - "How will our security program scale as our customer base grows?" - "Which compliance frameworks are table stakes, and which provide differentiation?" - "How will we reduce third-party risk management friction in the sales cycle?" - "How will we address data sovereignty and applicable regulations like EU AI Act, NIS2, and DORA?" - "Have we secured our own software supply chain and published a vulnerability disclosure policy?" pitfalls: - "Treating compliance as a checkbox exercise rather than a trust-building investment" - "Delaying SOC 2 until a deal requires it, then scrambling" - "Ignoring data sovereignty requirements in product architecture decisions" - "Promising compliance without the operational infrastructure to maintain it" - id: "platform" name: "Platform Strategy and Ecosystem Positioning" purpose: "Evaluate platform vs. suite dynamics and navigate ecosystem positioning" source: "/security-product-creation-framework, /what-platform-means-cybersecurity" principles: - "Becoming a platform creates sustainable competitive advantage, but getting there is rare" - "Be realistic about whether you provide more value as a point solution or platform component" - "Enterprise buyers prefer procuring through cloud marketplaces to draw down existing commitments" - "Integration gives distribution and credibility but creates dependency" - "Platform vendors may eventually build your capability natively" - "When a single vendor offers bundled security, standalone products must clearly justify separate purchase" - "Suites add fixed increments of value through consolidation, while platforms create compounding value where each addition reinforces everything else" - "Platform dynamics emerge from architectural decisions and sustained investment in shared foundations, not from declaring yourself a platform" - "In cybersecurity, shared data creates especially powerful platform dynamics because telemetry from multiple products enriches AI models in ways that competitors with separate data silos can't replicate" - "Suite and platform dynamics can coexist in the same portfolio, so recognize which parts exhibit which and fund each appropriately" - "When buyers prioritize operational simplicity over extensibility, a well-integrated suite delivers more practical value than ecosystem infrastructure" - "Most platform attempts fail within five years, often because they can't attract participants to both sides simultaneously" strategicQuestions: - "Should we aim to build a comprehensive platform or integrate with existing ones?" - "Which integrations are essential to reach our customers' procurement workflows?" - "How do we balance ecosystem participation with competitive differentiation?" - "If a platform vendor builds our capability natively, how will we stand out?" - "How will we help customers justify our product when they already pay for a platform with similar capabilities?" - "Does each new product or module gain meaningful advantage from what's already in our foundation, or is it essentially standalone work under a shared brand?" - "Are we investing in shared architectural foundations such as a common data layer, identity, and distribution that create compounding value, or are we consolidating products under one vendor?" - "Which parts of our portfolio exhibit suite dynamics and which exhibit platform dynamics, and are we funding each appropriately?" - "If we're building a suite, are we investing in integration depth and operational simplicity rather than ecosystem infrastructure we can't support?" pitfalls: - "Overestimating ability to become a platform when point solution economics are more realistic" - "Depending too heavily on a single platform partner for distribution" - "Ignoring cloud marketplace requirements until deep in the sales cycle" - "Failing to plan for the scenario where a platform vendor bundles your capability" - "Calling your product a platform when it's actually a suite, leading to misallocated investment in ecosystem infrastructure the architecture can't support" - "Investing in partner ecosystems and marketplace features before proving shared foundations work for your own product expansion" - "Starving the integration work that differentiates a good suite in favor of ecosystem aspirations the architecture doesn't support" subsections: - id: "platform_vs_suite" name: "Platform vs. Suite Diagnostic" principles: - "A suite consolidates capabilities under one vendor, and each module adds a fixed increment of value" - "A platform creates compounding value because each addition makes everything else on it more valuable" - "The distinction determines how value scales and what strategy needs to support it" - "Shared data layers, shared identity, and shared distribution are architectural markers of platform dynamics" - "One test of a genuine platform is whether the economic value of everyone who builds on it exceeds the value of the company that created it" strategicQuestions: - "When we add a new module, does it draw on shared telemetry, identity, or data that makes existing capabilities more valuable?" - "Are we building shared architectural foundations like a unified data layer, single agent, and common identity, or integrating separate products under a shared console?" - "Would our next product launch be meaningfully faster or better because of what we've already built, or would it start essentially from scratch?" - "Do we have, or are we building toward, a foundation that third parties could build on?" pitfalls: - "Using industry definitions of 'platform' that actually describe suites to justify platform-level investment without platform-level architecture" - "Treating integration count as evidence of platform dynamics when most integrations follow the same pattern and don't reinforce each other" - "Assuming a shared console or single sign-on constitutes platform architecture" examples: - point: "CrowdStrike built a single-agent architecture with a unified data layer where cloud security and identity protection modules run on the same sensor and share telemetry, giving each new module advantages that standalone competitors can't match" source: "/what-platform-means-cybersecurity" - point: "Palo Alto Networks shows how suite and platform dynamics coexist in one company, with acquisition-driven portfolio consolidation as suite behavior and Cortex XSIAM's cross-domain telemetry correlation as platform behavior" source: "/what-platform-means-cybersecurity" - point: "Okta's Integration Network connects thousands of applications through standardized SSO connectors, but adding one more does not strengthen existing integrations. The platform dynamic comes from the shared identity data layer, where each identity capability reinforces the others" source: "/what-platform-means-cybersecurity" - id: "team" name: "Team and Execution Capability" purpose: "Assess team strengths, gaps, and credibility" source: "/security-product-creation-framework" principles: - "Strategy is only as strong as the team's ability to execute it" - "Security buyers evaluate the people behind a product, especially at earlier stages" - "Domain expertise mapping directly to the product's value proposition is more credible than adjacent experience" - "Prior roles, published work, and community reputation directly affect sales cycles" - "Team gaps require specific plans — hiring, advising, or partnering" strategicQuestions: - "What domain expertise does our team bring that competitors lack?" - "Where does our team lack the skills or experience our strategy requires, and how will we close those gaps?" - "Do our backgrounds give us credibility with the buyers we are targeting?" pitfalls: - "Assuming technical strength compensates for go-to-market inexperience" - "Leaving team gaps unaddressed until they become blocking issues" - "Overweighting pedigree over relevant domain experience" - id: "competitive_landscape" name: "Competitive Landscape" purpose: "Map competitors and differentiation" source: "/security-product-creation-framework, /endpoint-security-startup-questions" principles: - "Map where competitors are strong, where they are weak, and where your product offers distinct value" - "Adjacent category players may converge into your space" - "Incumbent retention remains high even after incidents due to switching costs" strategicQuestions: - "Who are our direct competitors and what are their specific strengths and weaknesses?" - "Which adjacent-category vendors could expand into our space?" - "What switching costs keep customers with incumbents?" pitfalls: - "Defining competition too narrowly and missing adjacent threats" - "Assuming incumbent weakness creates easy opportunity without considering switching costs" - "Focusing competitive analysis on features rather than customer outcomes" - id: "integration_priorities" name: "Integration Priorities" purpose: "Prioritize platform and tool integrations" source: "/security-product-creation-framework" principles: - "Integration priorities should flow from target segment requirements" - "SIEM, ticketing, identity provider, and cloud security tooling integrations are commonly expected" - "Cloud marketplace listings enable procurement through existing spending commitments" strategicQuestions: - "Which platform and tool integrations are essential to reach our target customers?" - "Which marketplace listings would materially improve procurement access?" - "What is our integration priority based on customer segment needs?" pitfalls: - "Building integrations before validating which ones customers actually need" - "Treating all integrations as equal priority instead of ranking by segment impact" # ============================================================================ # Context-Dependent Guidance # Advantages and challenges from: /security-product-management-large-companies-vs-startups # Tips synthesized from across the article set # ============================================================================ contextGuidance: startup: advantages: - "Clean slate, no legacy constraints or conflicting product lines" - "Fast iteration, can pivot quickly based on customer feedback" - "Direct customer access, founders often talk to customers directly" - "Focused team, everyone aligned on a single product mission" challenges: - "Harder to reach customers without an established sales force or brand" - "Fewer resources, every hire and feature decision has outsized impact" - "Higher failure cost, limited runway means mistakes are expensive" - "Must build credibility from scratch with risk-averse security buyers" tips: - "Use founder domain expertise as a credibility signal" - "Use design partners to validate assumptions before committing resources" - "Invest early in security posture to avoid trust gaps in sales cycles" - "Focus on a single segment rather than trying to address the entire market" stageGuidance: preSeed: description: "Validating that the problem exists and is worth solving" emphasize: - "market_segmentation" - "product_capabilities" - "team" priorities: - "Validate the problem with potential customers before building" - "Identify 2-3 design partners willing to test early prototypes" - "Team credibility and domain expertise are the primary assets" - "Define the narrowest viable market segment to start" seed: description: "Building the first product and proving initial traction" emphasize: - "market_segmentation" - "product_capabilities" - "pricing" - "trust" priorities: - "Ship an MVP that solves one problem well for a specific persona" - "Establish initial pricing based on early customer conversations" - "Begin building compliance foundations that enterprise buyers expect" - "Collect evidence from design partners to validate positioning" seriesA: description: "Proving repeatable sales and scaling go-to-market" emphasize: - "sales_gtm" - "pricing" - "competitive_landscape" - "integration_priorities" priorities: - "Define a repeatable sales motion that matches deal size and buyer persona" - "Refine pricing based on actual sales cycles, not assumptions" - "Build integrations that reduce friction in the most common deployment environments" - "Establish competitive positioning with specific, evidence-backed differentiation" seriesB: description: "Scaling go-to-market and expanding the customer base" emphasize: - "sales_gtm" - "pricing" - "competitive_landscape" - "team" priorities: - "Scale the sales organization while maintaining deal quality and customer fit" - "Expand into adjacent segments once the beachhead is established" - "Hire experienced leaders who have scaled security companies before" - "Invest in customer success to drive retention and expansion revenue" growth: description: "Expanding product lines, entering new markets, and building toward market leadership" emphasize: - "platform" - "competitive_landscape" - "pricing" - "integration_priorities" priorities: - "Evaluate platform strategy: build a platform or deepen integrations with existing ones" - "Expand the product line to capture more of the customer's security budget" - "Enter international markets with localization and regional compliance support" - "Defend competitive position through data advantages, ecosystem effects, or switching costs" lateStage: description: "Preparing for public markets or strategic acquisition with mature operations" emphasize: - "platform" - "trust" - "team" - "competitive_landscape" priorities: - "Demonstrate predictable revenue growth and a credible path to profitability" - "Strengthen governance, financial controls, and regulatory compliance to meet public-market scrutiny" - "Build or acquire capabilities that complete the platform story for analysts and investors" - "Manage the tension between growth investments and profitability expectations" - "Ensure executive team has public-company or equivalent operational experience" - "Articulate a durable competitive moat that survives beyond the IPO window" largeFirm: advantages: - "Established sales force and existing customer relationships" - "Existing customer base creates cross-sell and upsell opportunities" - "Access to expertise, infrastructure, and resources for compliance" - "Brand recognition reduces initial trust barriers with buyers" challenges: - "Bureaucracy slows decision-making and iteration speed" - "Legacy constraints may limit product architecture choices" - "Conflicting priorities across product lines compete for resources" - "Internal politics can override customer-driven product decisions" tips: - "Protect the new product team from organizational inertia" - "Leverage existing customer relationships for early validation" - "Use the established sales force but train them on new product positioning" - "Set clear success metrics that differ from mature product expectations" # ============================================================================ # Product Manager Role # From: /what-is-security-product-manager # ============================================================================ productManagerRole: coreResponsibilities: - "Define product vision and strategy aligned with market needs" - "Prioritize features based on customer value and business impact" - "Translate security domain expertise into product requirements" - "Bridge communication between engineering, sales, and customers" - "Make trade-off decisions balancing security effectiveness, usability, and business viability" primaryObjectives: - "Ensure the product addresses real security pain points, not just interesting technical problems" - "Balance short-term customer demands with long-term strategic direction" - "Build products that security practitioners actually want to use" securityPMQuestions: - "What measures are prospective customers employing today to address the risks that the product tackles?" - "How will the product's capabilities handle the ever-evolving threat and regulatory landscape?" - "To what extent does the product offer meaningful, rather than merely incremental, security benefits?" - "How do the product's operational burdens compare to its security value proposition?" - "Which security, compliance, audit, or other roles within the organization will benefit from the product the most?" - "How does the product leverage automation or AI to scale protection without increasing operational burden?" # ============================================================================ # SMB Market Module # From: /smb-security-product-strategy # ============================================================================ smbGuidance: overview: "SMBs are fundamentally different from enterprises. Vendors who merely repackage enterprise solutions at a lower price point struggle. Distribution channels, buying triggers, and platform dynamics require distinct strategies." distributionChannels: - channel: "MSP" customerSize: "Smaller organizations (typically under ~100 employees)" model: "Multi-tenant at scale, wholesale pricing" requirements: - "Rapid deployment across many clients" - "No per-client customization" - "Multi-tenant management console" - channel: "VAR" customerSize: "Mid-size organizations (typically 100-500 employees)" model: "Help with selection and integration" requirements: - "Clear value proposition for resale" - "Integration flexibility" - channel: "Direct" customerSize: "Any" model: "Self-service, low-touch" requirements: - "Self-service pricing below typical sales-assisted threshold" - "Automated onboarding" - "Minimal support requirements" buyingTriggers: - "Cyber insurance requirements increasingly mandate specific controls (MFA, EDR, encrypted backups, incident response plans)" - "Supply chain compliance cascades from regulations and enterprise customer requirements" - "High-profile breaches in similar organizations create urgency" - "Regulatory requirements expanding to smaller organizations" readinessChecklist: - factor: "Deployment" smbReady: "Self-service or MSP-deployed at scale" needsWork: "Light integration per customer" poorFit: "On-site implementation required" - factor: "Sales cycle" smbReady: "Self-service activation" needsWork: "Weeks" poorFit: "1+ months" - factor: "Price point" smbReady: "Sells without a sales team" needsWork: "Requires sales assist to close" poorFit: "Requires dedicated sales rep per deal" - factor: "Customization" smbReady: "None or template-based" needsWork: "Light per-customer config" poorFit: "Significant per-customer work" - factor: "Support" smbReady: "Self-service or MSP-managed" needsWork: "Periodic check-ins" poorFit: "Dedicated account team" channelConcentrationRisk: - "A small number of RMM/PSA platforms control a large share of MSP workflows" - "A single channel partner can represent a disproportionate share of revenue" - "Losing one MSP partner can cascade to loss of dozens of underlying SMB customers" - "Channel dependency creates vulnerability to partner pricing and policy changes" platformConsolidationThreat: - "SMBs strongly prefer integrated platforms over point solutions" - "Major vendors bundle security into broader offerings, making standalone products invisible to end customers" - "MSPs increasingly bundle security stacks that individual SMB customers never see or choose" - "Platform consolidation reduces the number of purchasing decisions SMBs make independently" aiImpact: - "AI could reduce MSP per-client costs through alert triage and workflow automation" - "Operational complexity of deploying AI has tempered initial enthusiasm" - "Opportunity exists for pre-packaged AI capabilities designed for MSP workflows" - "AI-enabled products for SMBs should focus on being easier to operate and cheaper to deliver" # ============================================================================ # Endpoint Security Module # From: /endpoint-security-startup-questions # ============================================================================ endpointGuidance: overview: "Platform incumbents dominate endpoint security through data moats, budget lock-in, and distribution advantages. Startups must find gaps that platforms have not yet covered and build defensible positions before incumbents respond." platformEntrapment: - "Prevention and detection are table stakes, not differentiators" - "Incumbent retention remains high even after major incidents, due to switching costs and compliance requirements" - "Cyber insurance and compliance requirements reinforce incumbent lock-in" - "Bundled platform economics make standalone point solutions harder to justify" defensibilityRubric: - factor: "Differentiation" defensible: "Addresses gap platforms have not covered" vulnerable: "Incremental improvement over existing" needsRethinking: "Feature platforms will bundle" - factor: "Technical depth" defensible: "Hard to replicate (novel research, unique data)" vulnerable: "Moderate complexity" needsRethinking: "Commodity technology" - factor: "Platform relationship" defensible: "Complementary; platforms want to acquire" vulnerable: "Ambiguous; could coexist or conflict" needsRethinking: "Directly competitive with bundled feature" - factor: "Independent evidence" defensible: "Validated by MITRE, AV-Comparatives, or incidents" vulnerable: "Supported by analyst coverage" needsRethinking: "Supported only by marketing" - factor: "AI and data advantage" defensible: "Proprietary data flywheel that compounds with customers" vulnerable: "Dependent on third-party models or public data" needsRethinking: "No data advantage over platforms" - factor: "Acquirer interest" defensible: "Multiple platforms bidding for the capability" vulnerable: "Niche interest" needsRethinking: "No clear acquirer" - factor: "Founding team" defensible: "Shipped endpoint security products before" vulnerable: "Adjacent security experience" needsRethinking: "No relevant domain experience" whereStartupsCanWin: - area: "Agentic AI security" pattern: "New attack surface that established platforms have not yet addressed" - area: "Browser security" pattern: "Enterprise browser as a security control point for distributed workforces" - area: "Specialized threat types" pattern: "Deep focus on a single attack type can create defensible data advantages that generalist platforms lack" - area: "Compliance automation" pattern: "Reducing friction between security requirements and operational reality" - area: "Identity and access for non-human entities" pattern: "Service accounts, API keys, and agent credentials as an expanding attack surface" adjacentCategoryConvergence: - "Device management vendors expanding into security capabilities" - "Patch management platforms adding detection capabilities" - "DNS filtering tools broadening scope into endpoint protection" - "Enterprise browsers as a converging security layer" - "Identity platforms expanding into endpoint posture assessment" exitReality: - pattern: "Several well-funded endpoint security startups have seen dramatic value declines post-acquisition or at exit, suggesting the conditions that enabled earlier independent successes may no longer exist" - principle: "For most founders: position for strategic acquisition with enough differentiation to negotiate favorable terms" # ============================================================================ # Team Collaboration # From: /securing-software-products # ============================================================================ teamCollaboration: balancingResponsibilities: - "Security and engineering teams must collaborate constructively, not adversarially" - "Security requirements should be integrated into the development process, not bolted on at the end" - "Product managers bridge security needs with engineering capacity and business priorities" - "Shared ownership of security outcomes reduces finger-pointing and increases effectiveness" constructivePressure: - "Security teams should provide guidance and tools, not just requirements and audits" - "Engineering teams should view security input as improving product quality, not blocking progress" - "Constructive tension between security thoroughness and engineering velocity produces better outcomes than either extreme" vulnerabilityPrioritization: - "Prioritize vulnerabilities based on exploitability and business impact, not just severity scores" - "Not all vulnerabilities require immediate fixes — risk-based prioritization prevents alert fatigue" - "Transparent communication about vulnerability status builds trust with customers" - "A clear vulnerability disclosure policy demonstrates maturity" # ============================================================================ # Review Guidance # For product_review_plan tool # ============================================================================ reviewGuidance: purpose: "Guidance for constructive critique of product strategy plans" feedbackStructure: - "Start with what the plan does well — identify specific strategic strengths" - "Identify gaps or weak assumptions with concrete, actionable suggestions" - "Reference specific sections and evidence levels when providing feedback" - "Offer alternative strategic approaches, not just criticisms" reviewerMindset: - "You are helping strengthen the strategy, not judging the team" - "Assume good intent — gaps may reflect early-stage uncertainty" - "Distinguish between validated evidence and untested assumptions" - "Early-stage plans naturally have more assumptions than established ones" feedbackTone: - "Use collaborative language ('consider', 'you might explore', 'this could be strengthened by')" - "Avoid judgmental phrases ('you failed to consider', 'this is naive')" - "Frame gaps as opportunities for validation" - "Acknowledge the difficulty of strategic decisions under uncertainty" # ============================================================================ # Section-Specific Review Criteria # One per framework section # ============================================================================ sectionReviewCriteria: market_segmentation: checkFor: - "Specific segment definition (not just 'enterprises' or 'SMBs')" - "Persona identification with distinct priorities for each" - "Deal size aligned with intended sales model" - "Evidence basis noted for each answer" - "Channel strategy appropriate for target segments" commonIssues: - "Vague segmentation ('all industries', 'any size')" - "Missing persona analysis — treating all buyers as identical" - "Deal size that cannot support the intended sales model" - "No evidence distinction between validated and assumed" product_capabilities: checkFor: - "Clear articulation of specific pain points addressed" - "Honest assessment of AI data advantages and their durability" - "Agent interaction design considered" - "Build vs. integrate decisions justified" - "MVP scope defined and realistic for target buyers" commonIssues: - "Vague differentiation ('better AI', 'more advanced')" - "No assessment of frontier model vendor risk" - "Agent design treated as afterthought" - "MVP scope too broad for available resources" sales_gtm: checkFor: - "Sales model matched to deal size and segment" - "Channel strategy appropriate for target market" - "POC structure with defined success criteria" - "First impression and credibility plan" commonIssues: - "Enterprise sales team planned for SMB deal sizes" - "No channel strategy for indirect segments" - "POCs without success criteria or time bounds" pricing: checkFor: - "Value-based pricing rationale (not cost-plus)" - "Agent consumption pricing considered" - "Cost-spike protections for incident scenarios" - "Retention and expansion strategy" - "Sales compensation alignment" commonIssues: - "Cost-based pricing that undervalues the product" - "No plan for agent pricing" - "Consumption pricing without cost protections" - "Subscription timing mismatched with sales comp" delivery: checkFor: - "CI/CD and DevOps integration plan" - "IaC and API-first deployment support" - "Data residency requirements addressed" - "Support responsibility matrix defined" commonIssues: - "Manual console-only deployment" - "Data residency requirements not considered" - "No clear support RACI" trust: checkFor: - "Compliance roadmap with timeline" - "Supply chain security practices" - "Vulnerability disclosure policy" - "Regulatory awareness for target markets" commonIssues: - "Compliance treated as future work with no timeline" - "No supply chain security considerations" - "Missing vulnerability disclosure policy" platform: checkFor: - "Realistic assessment of platform vs. point solution positioning" - "Integration priorities ranked by segment impact" - "Platform vendor dependency risk assessed" - "Bundling response strategy" - "Suite vs. platform dynamics distinguished with architectural evidence" - "Investment aligned to the type of dynamics present (integration depth for suite, shared foundations for platform)" commonIssues: - "Unrealistic platform ambitions" - "No plan for platform vendor building similar capability" - "Integrations not prioritized" - "Labeling a suite as a platform without identifying shared architectural foundations" - "Investing in ecosystem infrastructure before proving shared foundations work for internal expansion" team: checkFor: - "Domain expertise mapped to value proposition" - "Skill gaps identified with specific closing plans" - "Team credibility with target buyers assessed" commonIssues: - "Skill gaps acknowledged but no closing plan" - "Credibility not assessed from buyer perspective" - "Team composition mismatched with strategy requirements" competitive_landscape: checkFor: - "Direct and adjacent competitors identified" - "Honest assessment of competitor strengths" - "Switching cost analysis" - "Specific differentiation articulated" commonIssues: - "Competition defined too narrowly" - "Competitor strengths underestimated" - "No switching cost consideration" integration_priorities: checkFor: - "Integration priorities driven by segment requirements" - "Marketplace listings considered" - "Integration effort estimated" commonIssues: - "Integrations listed without prioritization" - "No connection between integrations and target segments" # ============================================================================ # Cross-Cutting Quality Criteria # ============================================================================ crossCuttingCriteria: strategicCoherence: description: "Decisions across sections should reinforce each other" checkFor: - "Market selection drives capability prioritization" - "Pricing aligns with target segment's budget reality" - "Go-to-market approach matches deal size and team capabilities" - "Integration priorities follow from target segment needs" - "Team composition supports the chosen strategy" evidenceBasis: description: "Distinguish validated knowledge from assumptions" checkFor: - "Each answer notes whether it is validated, informed assumption, or untested" - "Untested assumptions have validation plans" - "Critical strategic decisions are backed by customer conversations or market data" - "The plan distinguishes between what the team knows and what it believes" - "Company marketing claims are identified as claims, not stated as facts" - "Self-described superlatives ('first,' 'only,' 'most advanced') are treated as unverified until independently confirmed" - "Third-party evidence (analyst reports, customer testimonials, independent benchmarks) is distinguished from company-sourced evidence" - "When evidence comes only from the company itself, that limitation is noted" - "Product descriptions are assessed for specificity: do they explain concrete capabilities or rely on vague positioning?" - "The same honest gap analysis standard applied to your own product is applied when evaluating competitors" executionRealism: description: "Strategy must be achievable with available resources" checkFor: - "Team gaps identified with realistic closing plans and timelines" - "Timeline accounts for compliance requirements" - "Resource requirements match available funding and team size" - "Dependencies between sections are acknowledged" # ============================================================================ # Category Creation Guidance # Original content — not directly from a single published article, but # consistent with published positions on honest positioning, realistic moats, # and skepticism toward vague claims. # ============================================================================ categoryCreation: overview: "Creating a new product category can be a legitimate strategy when existing categories do not describe the problem your product solves. It also carries significant risks. Category creators must teach the market that the problem exists before they can sell the solution." principles: - "Category creation makes sense when the problem is real but existing categories do not describe the solution" - "If buyers cannot explain your category to their boss, they cannot get budget for it" - "Category creators bear the full cost of market education. You must teach the market the problem exists before you can sell a fix" - "Analysts and journalists are skeptical of new categories. They will ask whether this is genuinely new or a rebrand of something familiar" - "Larger vendors can co-opt a category name once the market education is done. The creator does not always win the category they defined" - "A category name that resonates with practitioners but confuses procurement is a liability, not an asset" - "Most startups that claim to be creating a category are not. Positioning as a category creator can signal ambition to investors, but your strategy should not depend on it succeeding" - "Premature category creation, when the problem is not widely recognized, forces you to sell the problem and the solution simultaneously" strategicQuestions: - "Is the problem we address genuinely unserved by existing categories, or are we reframing a known problem for differentiation?" - "Can our target buyer explain this category to a colleague who has never heard of it, in one sentence?" - "How much of our sales cycle is spent educating the buyer about the problem vs. demonstrating our solution?" - "What happens when a platform vendor adopts our category name and bundles a competing capability?" - "Do industry analysts recognize the category, or do they classify us under an existing one?" - "Have we tested the category name with actual buyers, or only with our own team and investors?" risks: - "Budget allocation. New categories often lack dedicated budget lines in buyer organizations" - "Analyst skepticism. Analysts may classify you under an adjacent existing category rather than endorsing a new one" - "Competitor co-option. A vendor with larger distribution can adopt your category name and outspend you on awareness" - "Market timing. If the problem is not widely felt, you will exhaust resources on education before generating revenue" - "Naming confusion. A category name that is technically precise but commercially unclear slows adoption" # ============================================================================ # External Analysis Guidance # For evaluating another company's product strategy from outside # ============================================================================ externalAnalysisGuidance: overview: "When evaluating a company from the outside, the framework's strategic dimensions still apply, but questions must be reframed and evidence standards adjusted. Some sections will be unanswerable from public information alone." evidenceTiers: - tier: "confirmed" description: "Stated in public sources such as press releases, documentation, analyst reports, or verified customer testimonials" - tier: "inferred" description: "Reasonable conclusion drawn from public signals such as job postings, partnership announcements, pricing pages, or product documentation" - tier: "not_disclosed" description: "Cannot be determined from available public sources. Note the gap rather than guessing" reframedQuestions: market_segmentation: - "What specific customer segments does this company target based on their messaging, case studies, and pricing?" - "How do their stated target personas compare to the personas they appear to serve?" product_capabilities: - "What specific pain points does this company claim to address?" - "What capabilities are demonstrated in documentation or product trials vs. only described in marketing?" sales_gtm: - "What go-to-market motion does the company appear to use (self-service, sales-assisted, enterprise)?" - "What channel partnerships or integrations suggest their distribution strategy?" pricing: - "What pricing model is publicly visible, and what does it suggest about their target deal size?" - "How does their pricing compare to alternatives in the same space?" trust: - "What compliance certifications and security practices does the company publicly claim?" - "How mature does their security posture appear from public signals?" competitive_landscape: - "Who are this company's direct and adjacent competitors based on market positioning?" - "Where does a competitor appear to offer more value, and where does this company differentiate?" delivery: - "What deployment model do documentation, integrations pages, and customer references indicate?" - "What does the company's API documentation and developer resources suggest about deployment complexity?" platform: - "What integration ecosystem, API surface, and partnership announcements suggest about platform ambitions?" - "Does the company position itself as a platform or a point solution based on public messaging?" team: - "What do LinkedIn profiles, press releases, and prior exits reveal about team capability and gaps?" - "Does the founding team have domain expertise in the problem space they are addressing?" integration_priorities: - "What integrations has the company announced, documented, or listed on its website?" - "Which integration partners suggest the company's target deployment environment?" ai_data_advantages: - "What data advantages does the company claim, and are they supported by evidence of unique data access?" - "How does the company describe its AI capabilities: specific technical claims or marketing language?" competitive_positioning: - "How does this company position itself against named competitors in public materials?" - "What does the company claim as its primary differentiation, and is that claim supported by evidence?" bottom_up: - "Is there evidence of developer or practitioner adoption independent of top-down enterprise sales?" - "Does the company offer a free tier, open source component, or community edition?" design_partners: - "Are design partners or early customers identifiable from case studies, press releases, or conference talks?" agent_pricing: - "If the product involves AI agents, how does the pricing account for variable compute costs?" typicallyUnanswerable: - "Internal POC conversion rates and sales cycle details" - "Specific revenue figures unless publicly disclosed" - "Design partner identities and feedback" - "Internal team compensation and retention" - "Detailed product roadmap beyond public announcements" - "Unit economics and margin structure" informationAsymmetry: overview: "External analysis relies on public information. Other audiences, including investors, customers, judges, and board members, see private data. Account for this gap rather than treating public disclosure as a proxy for actual performance." principles: - "Distinguish absence of evidence from evidence of absence. A company that discloses no customers publicly may have many customers privately. A company that discloses nothing after being asked directly in interviews likely has few." - "Calibrate confidence by information type. Dimensions observable from public sources, such as team backgrounds, funding rounds, product features, and open-source metrics, can be assessed with higher confidence. Dimensions that depend on private data, such as revenue, customer pipeline, and deployment depth, should carry explicit uncertainty markers." - "Name who knows more. For any external assessment, identify the audiences that have access to private information and note where their view would differ from yours. Investors have seen the data room. Customers have seen the product. Judges may have received private briefings." - "Weight your predictions accordingly. When making forward-looking assessments, lean on publicly observable factors such as problem timing, team track record, technical novelty, and demo potential. Lean away from factors that depend on private disclosure such as revenue, customer count, and internal roadmap." commonMistakes: - "Scoring a company low on traction because it chose not to disclose publicly, rather than because it lacks traction" - "Treating public customer logos as the complete customer list rather than a curated subset" - "Assuming a company's website reflects its full product capability rather than its marketing choices" - "Penalizing recently launched companies for thin public evidence when private evidence may be strong" # ============================================================================ # Evaluation Perspectives # Different stakeholders emphasize different framework sections # ============================================================================ evaluationPerspectives: builder: description: "Product team planning or refining their own strategy" emphasize: - "market_segmentation" - "product_capabilities" - "pricing" - "delivery" - "team" keyQuestions: - "Is our market segmentation specific enough to guide feature prioritization?" - "Does our capability set address the pain points our target segment cares about most?" - "Can our team execute this strategy with current resources?" analyst: description: "Industry analyst evaluating market positioning and category fit" emphasize: - "market_segmentation" - "product_capabilities" - "competitive_landscape" - "platform" keyQuestions: - "Is the market positioning clear and differentiated from adjacent categories?" - "Does the competitive differentiation hold under scrutiny, or is it incremental?" - "How does this company's timing align with market readiness for their category?" investor: description: "Investor evaluating the business opportunity and team" emphasize: - "market_segmentation" - "team" - "competitive_landscape" - "pricing" keyQuestions: - "Is the market large enough and is the company targeting the right initial segment?" - "Does the team have the domain expertise and execution history to win?" - "Is the competitive advantage defensible as the market matures?" - "Does the pricing model support the unit economics needed for growth?" buyer: description: "Security practitioner evaluating whether to purchase" emphasize: - "product_capabilities" - "trust" - "pricing" - "integration_priorities" keyQuestions: - "Does this product solve a problem I actually have, with evidence beyond marketing claims?" - "How does integration complexity compare to the operational benefit?" - "What is the total cost of ownership, including deployment, training, and ongoing operations?" - "What are the switching costs if I need to replace this product later?" # ============================================================================ # Comparative Analysis Framework # For evaluating multiple companies side-by-side # ============================================================================ comparativeAnalysis: overview: "Comparing multiple companies requires consistent evaluation dimensions, honest overlap assessment, and awareness of how incumbents could absorb each company's value proposition." evaluationDimensions: - dimension: "Problem space" frameworkSection: "market_segmentation" compareOn: "Which customer pain points does each company target, and how much do those pain points overlap?" - dimension: "Capability depth" frameworkSection: "product_capabilities" compareOn: "How specific are each company's capabilities vs. relying on broad positioning claims?" - dimension: "Competitive positioning" frameworkSection: "competitive_landscape" compareOn: "Where does each company claim differentiation, and do those claims hold when compared directly?" - dimension: "Go-to-market motion" frameworkSection: "sales_gtm" compareOn: "What sales model does each company use, and how does it align with their target segment?" - dimension: "Pricing approach" frameworkSection: "pricing" compareOn: "How do pricing models compare, and what do they reveal about target deal size and buyer persona?" - dimension: "Trust readiness" frameworkSection: "trust" compareOn: "Which companies have compliance certifications, security practices, and customer evidence that reduce buyer risk?" - dimension: "Category clarity" frameworkSection: "market_segmentation" compareOn: "How clearly does each company define and own its category, and can buyers quickly place it in their security stack?" - dimension: "Incumbent threat exposure" frameworkSection: "competitive_landscape" compareOn: "How vulnerable is each company's value proposition to being absorbed as a feature by an existing platform vendor?" thematicClustering: purpose: "Group companies by the problem they solve rather than the technology they use" guidance: - "Companies that target the same buyer persona with different approaches belong in the same cluster" - "Companies that use similar technology for different buyer personas belong in separate clusters" - "A company may appear in multiple clusters if it serves multiple use cases" headToHeadOverlap: purpose: "Identify which companies compete directly vs. which are adjacent" guidance: - "Direct competitors target the same persona with the same problem framing" - "Adjacent competitors target the same persona but frame the problem differently" - "Potential future competitors are in adjacent categories that could expand into this space" incumbentThreatMapping: purpose: "Assess which established vendors could absorb each company's value proposition" guidance: - "For each company, identify which platform vendors already serve the same buyer persona" - "Assess whether the company's core capability could become a feature in an existing platform" - "Consider timeline: how long before a platform vendor could build or acquire equivalent capability?" - "Companies whose value is primarily integration or workflow automation are more vulnerable to platform absorption than those with deep technical differentiation" batchAnalysisWorkflow: - "Start with a consistent brief structure applied to each company" - "Use the compact detail level to keep individual analyses focused" - "After individual analyses, identify thematic clusters" - "Within each cluster, perform head-to-head overlap assessment" - "Map incumbent threats for each company" - "Synthesize cross-cutting themes and strategic observations" # ============================================================================ # AI Security Vertical Module # Follows the structural pattern of endpointGuidance # ============================================================================ aiSecurityGuidance: overview: "AI security is an emerging category where the threat landscape, buyer personas, and competitive dynamics differ from traditional security markets. Products must navigate rapid technology change, unclear budget ownership, buyer skepticism about AI-for-AI solutions, and a regulatory environment that is tightening on a fixed timeline." marketDynamics: - "Budget ownership for AI security is often unclear. ML platform teams, security teams, and application teams may each claim or avoid responsibility" - "Buyers are skeptical of 'AI security' as a category because many products use the term for marketing without delivering AI-specific capabilities. The SEC has made AI washing an enforcement priority" - "The threat surface includes model supply chains, prompt injection, data poisoning, memory poisoning, and agent autonomy. Each creates distinct product opportunities" - "Shadow AI is a growing risk. Enterprises average hundreds of unsanctioned AI applications, and breaches involving shadow AI cost significantly more than standard breaches" - "The EU AI Act becomes fully applicable for high-risk AI systems in August 2026. NIST AI RMF and ISO/IEC 42001 set operational baselines. Products that help organizations meet these requirements have a timing advantage" - "Agentic AI creates new attack surfaces. Gartner projects that 40% of enterprise applications will feature embedded agents by 2026. Agent security requires architectural thinking, not bolt-on scanning" buyerPersonaDifferences: - persona: "ML platform team" priorities: "Model lifecycle security, supply chain integrity, training data protection" buyingBehavior: "Evaluate based on integration with MLOps pipelines and developer experience" - persona: "Security team (CISO org)" priorities: "Visibility into AI usage, policy enforcement, risk assessment, compliance evidence" buyingBehavior: "Evaluate based on integration with existing security stack, compliance mapping, and audit readiness" - persona: "Application team" priorities: "Runtime protection, prompt injection defense, output safety" buyingBehavior: "Evaluate based on latency impact, ease of integration, and false positive rates" integrationPriorities: - "MLOps pipelines (model registries, experiment tracking, deployment automation)" - "Cloud AI services (Azure OpenAI, AWS Bedrock, Google Vertex AI)" - "Existing SIEM/SOAR platforms for security event correlation" - "CI/CD pipelines for model and application security scanning" - "AI governance platforms for policy enforcement and compliance reporting" competitiveLandscape: - "Platform AI vendors (cloud providers) are building native security features into their AI services" - "Traditional application security vendors are extending existing tools to cover AI workloads" - "AI governance and trust platforms (AI TRiSM) are converging with runtime security tools" - "Startups with narrow focus on specific AI threats compete against platform bundling" - "Open-source AI security tools (OWASP, MITRE ATLAS) set baseline expectations that commercial products must exceed" pricingConsiderations: - "Per-model or per-application pricing may align better with value than per-seat when security teams are small but model counts are large" - "Consumption-based pricing must account for the high variability in AI workload volumes" - "Buyers may resist paying for AI security separately if they expect it bundled with their AI platform" - "Compliance-driven buyers will pay for audit-ready evidence and documentation that satisfies EU AI Act and NIST AI RMF requirements" defensibilityFactors: - factor: "Threat intelligence" defensible: "Proprietary dataset of AI-specific threats that grows with customer base" vulnerable: "Dependent on public vulnerability databases and community research" - factor: "Integration depth" defensible: "Deep hooks into model lifecycle that are hard to replicate" vulnerable: "Wrapper around existing tools with thin AI-specific layer" - factor: "Category timing" defensible: "Solving problems buyers actively face today with production AI" vulnerable: "Solving problems that are theoretical or affect only early adopters" - factor: "Regulatory alignment" defensible: "Product directly maps to EU AI Act compliance requirements with audit-ready output" vulnerable: "Generic security tooling repositioned as AI compliance without specific regulatory mapping" # ============================================================================ # Evidence Tiering Framework # Classifies factual claims by source reliability # ============================================================================ evidenceTiering: overview: "Classify every factual claim by its source reliability. This prevents marketing language from being treated as fact and makes gaps in public information explicit." tiers: - tier: "confirmed" description: "Verifiable from public sources" subCategories: - "Third-party confirmed: stated in analyst reports, news coverage, regulatory filings, or independent reviews" - "Company claim (verifiable): specific, checkable facts from company materials such as funding amounts, certifications held, or named customers" - "Company claim (unverifiable): assertions from company materials that cannot be independently checked, such as accuracy percentages or internal metrics" - tier: "inferred" description: "Reasonable conclusion drawn from multiple public signals, not stated directly by any source" - tier: "not_disclosed" description: "Cannot be determined from available public sources. State the gap explicitly rather than guessing" decisionTree: - question: "Is the claim sourced from a third-party publication, regulatory filing, or independent review?" ifYes: "Confirmed (third-party)" ifNo: question: "Is it from the company's own materials (website, press releases, documentation)?" ifYes: question: "Is it a verifiable fact (funding amount, certification, named customer)?" ifYes: "Confirmed (company claim, verifiable)" ifNo: question: "Is it a marketing superlative (industry-leading, best-in-class, revolutionary)?" ifYes: "Label as marketing claim, not factual assertion" ifNo: "Confirmed (company claim, unverifiable)" ifNo: question: "Is it a reasonable inference from multiple public data points?" ifYes: "Inferred. Cite the data points that support it" ifNo: "Not publicly disclosed" distinctions: - category: "Confirmed facts" description: "Verifiable claims from credible sources" examples: - "Company press release stating '$20M Series A' = Confirmed (company claim, verifiable)" - "Gartner report listing the company as a representative vendor = Confirmed (third-party)" - "SOC 2 Type II badge on website = Confirmed (company claim, verifiable)" - category: "Company claims requiring qualification" description: "Statements from company materials that need sourcing context" examples: - "Website stating 'AI-powered detection' = Confirmed (company claim). Note it is the company's description" - "Website stating 'industry-leading accuracy' = Marketing claim. Do not treat as fact" - "Customer quote on website = Confirmed (company claim). The company selected which quotes to display" - category: "Inferences" description: "Conclusions drawn from indirect evidence" examples: - "Job posting for 'Sr. ML Engineer' = Confirmed data point. Inference that they are building ML capabilities = Inferred" - "Three enterprise case studies on website = Confirmed data points. Inference about enterprise readiness = Inferred" - category: "Gaps" description: "Information that cannot be determined" examples: - "No pricing page visible = Not publicly disclosed" - "No named customers outside case studies = Not publicly disclosed" # ============================================================================ # Scoring Rubric # Structured scoring for comparative analysis # ============================================================================ scoringRubric: overview: "Use this rubric for structured comparison across companies. Apply scores consistently using the anchor definitions. A score reflects evidence strength, not company quality. A company with limited public information scores lower because the evidence is weaker." scale: - score: 1 label: "Critical gap" description: "No evidence of capability or strategy in this dimension. Major risk or unknown." - score: 2 label: "Weak signals" description: "Early or minimal evidence. Significant gaps remain. Relies heavily on inference." - score: 3 label: "Adequate" description: "Meets baseline expectations. Evidence supports the claim but differentiation is unclear." - score: 4 label: "Strong" description: "Clear evidence of capability and differentiation. Well-supported by multiple data points." - score: 5 label: "Exceptional" description: "Category-defining strength. Multiple independent sources confirm differentiation that competitors cannot easily replicate." dimensions: - dimension: "Problem space clarity" criteria: "How precisely does the company define the problem it solves, and does public evidence support that the problem exists at the scale claimed?" - dimension: "Capability depth" criteria: "How specific are the company's technical capabilities, and is there evidence beyond marketing claims (documentation, demos, third-party validation)?" - dimension: "Market timing" criteria: "Is the company entering a market that is ready for its product, and does evidence suggest buyers are actively seeking solutions in this space?" - dimension: "Team credibility" criteria: "Does the team have demonstrated domain expertise, and do public signals (prior exits, publications, industry recognition) support execution capability?" - dimension: "Go-to-market proof" criteria: "Is there evidence of actual market traction (customers, revenue signals, partnerships) beyond stated intentions?" - dimension: "Funding efficiency" criteria: "Does the funding level match the go-to-market ambition, and are there signs of capital-efficient growth?" - dimension: "Category clarity" criteria: "Is the company creating or fitting into a recognizable category, and can buyers quickly understand where it fits in their security stack?" - dimension: "Incumbent threat exposure" criteria: "How vulnerable is the company's core value proposition to being absorbed as a feature by an established platform vendor?" # ============================================================================ # Related Articles # ============================================================================ relatedArticles: - url: "/security-product-creation-framework" title: "A Practitioner's Guide to Creating Cybersecurity Products" relevance: "Comprehensive strategic framework — primary source for all framework sections" - url: "/smb-security-product-strategy" title: "Building Security Products for SMBs" relevance: "SMB market dynamics — distribution, buying triggers, platform consolidation" - url: "/endpoint-security-startup-questions" title: "Competing in Endpoint Security: A Guide for Startups" relevance: "Endpoint viability assessment — platform entrapment, defensibility rubric" - url: "/new-product-management-tips" title: "Practical Tips for Creating and Managing Security Products" relevance: "Practical advice for new security product managers" - url: "/security-product-management-large-companies-vs-startups" title: "Security Product Management at Large Companies vs. Startups" relevance: "Context-specific guidance for startup vs. large company product managers" - url: "/what-is-security-product-manager" title: "What Does a Security Product Manager Do?" relevance: "Product manager role definition and key questions" - url: "/low-price-as-a-security-product-differentiator" title: "Low Price as a Differentiator for Cybersecurity Products" relevance: "Pricing strategies — loss leader, freemium, good-enough positioning" - url: "/designing-for-humans-and-ai" title: "Designing Security Products for Humans and AI Agents" relevance: "Usability as differentiator — persona-driven design, agent interfaces, intelligent defaults" - url: "/security-startups-first-impression" title: "First Impression Tips for Security Startups" relevance: "Credibility signals — research before contact, elevator pitches, domain expertise" - url: "/securing-software-products" title: "How Security Can Better Support Software Engineering Teams" relevance: "Security-engineering collaboration, vulnerability prioritization" - url: "/what-platform-means-cybersecurity" title: "Most Cybersecurity Products Aren't Platforms and It's OK" relevance: "Platform vs. suite distinction, shared data layers, architectural prerequisites, investment alignment" ---