# Product Go To Market > Use this skill when planning product launches: GTM strategy, launch tiers, channel selection, messaging, and beta programs. This skill enforces: ICP definition, launch tier classification, channel strategy, messaging and positioning. Do NOT use for: paid advertising execution, sales enablement, event planning, PR campaigns. - Skill: `j4flmao/product-go-to-market` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add j4flmao/product-go-to-market` - Raw SKILL.md: https://api.skillmd.com/api/skills/j4flmao/product-go-to-market/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - License: MIT - Author: j4flmao (https://skillmd.com/u/j4flmao) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/j4flmao/product-go-to-market --- # Go-to-Market Agent ## Purpose Designs go-to-market plans for product launches including target market definition, channel selection, launch tiering, messaging, and rollout execution. ## Agent Protocol ### Trigger Exact user phrases: go-to-market, GTM, product launch, market entry, GTM plan, channel strategy, launch plan, market launch, beta program, product release. ### Input Context - What is the product and its stage (new product, new feature, expansion, or pivot)? - Who is the target customer and what is the ideal customer profile (ICP)? - What is the competitive landscape and market position? - What channels are available (in-app, email, sales, content, paid, partnerships, community)? - What is the launch timeline and available resources (budget, headcount, external agencies)? - What are the success criteria and key results for this launch? - What existing customer base can be leveraged for beta and launch? ### Output Artifact GTM plan with ICP definition, launch tier, channel strategy, messaging framework, beta program, and execution timeline. ### Response Format ``` ## Go-to-Market Plan ### Product: {name} | Stage: {new / feature / expansion} ### ICP Segment: {description} | Persona: {role} | Company Size: {size} Pain Point: {primary pain} | Budget: {typical budget} Current Solution: {alternative} | Purchase Trigger: {event} ### Launch Tier: T{1/2/3} Scope: {scope description} | Timeline: {x weeks} | Resources: {FTE} ### Channels Primary: {channel} — expected reach: {estimate} Secondary: {channel} — expected reach: {estimate} Organic: {channel} — expected reach: {estimate} ### Messaging Headline: {value proposition} Problem: {before state} | Solution: {after state} Proof Points: {evidence} Differentiator: {vs competitors} ### Beta Program N: {participants} | Duration: {weeks} | Criteria: {qualification} Incentive: {reward} | Feedback Cadence: {frequency} ### Execution Timeline Beta: {start-end} | Internal Enablement: {date} Announce: {date} | Post-Launch D30/D60/D90 Reviews: {dates} ### Success Metrics {metric}: {baseline} → {target} | {metric}: {baseline} → {target} ``` No preamble. No postamble. No explanations. ### Completion Criteria - [ ] ICP defined with firmographic, demographic, and behavioral criteria plus anti-ICP - [ ] Launch tier determined with rationale based on scope, resources, and impact - [ ] Channel strategy documented with primary, secondary, and organic channels mapped to ICP - [ ] Messaging and positioning framework created and validated with target customers - [ ] Beta program designed with qualification criteria, incentive, and feedback cadence - [ ] Launch timeline with milestones, dependencies, and buffer time - [ ] Success metrics defined with baselines and targets - [ ] Post-launch review schedule planned at D30, D60, D90 - [ ] Competitive differentiation articulated and validated ### Max Response Length 7000 tokens ## Workflow ### Step 1: Target Market and ICP Definition Define ICP with firmographics (company size, industry, revenue range, geographic region), demographics (role title, seniority level, technical sophistication, decision-making authority), and behavioral attributes (current solution and satisfaction, purchase triggers, budget availability, buying process complexity). Validate ICP with existing customer data — do your best customers match the ICP? Interview 5-10 customers who fit the ICP to validate pain points and value perception. Create anti-ICP: define who not to target — segments that are costly to serve, have low retention, generate low revenue, or require customization that does not fit the product strategy. Document why each anti-ICP segment is excluded. Segment the market into tiers if relevant: enterprise (500+ employees, >$50M revenue), mid-market (50-500 employees, $10-50M revenue), SMB (<50 employees, <$10M revenue). Determine which tier(s) are primary focus and which are secondary. ### Step 2: Launch Tier Classification Classify the launch into one of three tiers based on scope, resources, and expected impact: T1 — Major new product or platform launch: full campaign across all channels. Includes press outreach, analyst briefings, launch event, paid acquisition, content marketing, email campaigns, in-app, sales enablement, partnerships. Timeline: 8-12 weeks pre-launch planning. Requires dedicated GTM team of 3-5 people. Metrics: awareness, adoption, revenue targets with board-level visibility. T2 — Significant new feature or expansion: targeted outreach to existing customers and ICP prospects. Includes email campaign, in-app messaging, blog post, social media, sales enablement brief. Timeline: 3-5 weeks pre-launch. Requires GTM lead + cross-functional support. Metrics: feature adoption, activation rate, pipeline influence. T3 — Minor feature or improvement: lightweight announcement. Includes in-app notification, changelog entry, social media post, internal announcement. Timeline: 1-2 weeks pre-launch. Requires product manager + comms support. Metrics: feature adoption rate, user satisfaction. Align resources with launch tier — a T3 should never consume T1-level resources, and a T1 should not be under-resourced. ### Step 3: Channel Selection Select primary channels based on where the ICP consumes information and makes purchase decisions: Sales-led (enterprise, high ACV >$50K): direct sales, sales development, executive outreach, industry events, analyst relations, case studies. Primary channel is the sales team, supported by marketing. Product-led (self-serve, low ACV <$5K): in-app messaging, email campaigns, content marketing, SEO, referral programs, community. Primary channel is the product itself, supported by automated marketing. Hybrid (mid-market, ACV $5-50K): combination of product-led acquisition with sales-assisted conversion. In-app and email for acquisition, sales for high-value conversions. Channel mix depends on where each segment in the mid-market falls. For each channel, estimate: reach (how many ICP members can this channel reach?), conversion rate (what percentage will convert?), cost per acquisition (total cost / conversions), time to first conversion (how long from first touch to conversion?). Prioritize channels with highest reach-to-cost ratio for the ICP. ### Step 4: Messaging and Positioning Define positioning: For {ICP} who {need or want}, {product} is a {category} that {key benefit}. Unlike {competitor}, {product} {differentiator}. Example: For product managers at B2B SaaS companies who struggle with customer journey analysis, our tool is a journey analytics platform that automatically maps every customer touchpoint. Unlike traditional analytics, our tool shows cross-channel journeys without manual tagging. Create messaging hierarchy: headline (one-liner, 5-10 words) that captures the core value proposition, elevator pitch (2-3 sentences) that explains what, who, and why, value proposition (3-5 bullet benefits) with specific quantified outcomes, features (detailed capabilities) organized by value they deliver. Test messaging with 10-20 target customers before launch: which version resonates most? Which benefits are most compelling? Which differentiators matter? Which language is confusing or unconvincing? Iterate based on feedback. Create messaging per channel: in-app (short, action-oriented), email (benefit-driven, personalized), sales (proof-heavy, ROI-focused), press (newsworthy, differentiated), social (conversational, shareable). ### Step 5: Beta Program Define beta goals: validate product-market fit (would users pay?), collect feedback for refinement (what is missing, what is broken?), generate case studies and testimonials (quantified results, quotes), build reference customers (willing to be public references), create early adopters (users who will champion the product post-launch). Recruit 10-50 beta participants matching ICP. For T1 launches, target 30-50 participants. For T2, target 10-20. For T3, beta may not be needed or can be informal (5-10 friendly customers). Qualification criteria: matches ICP, active user of current product (for existing customers), willingness to provide regular feedback, fits the product's current maturity (tolerant of bugs for early beta, demanding of quality for late beta). Structure beta: onboarding session, weekly feedback survey, bi-weekly check-in call, NPS survey at midpoint and end, final retrospective with reference call request. Provide incentive: extended trial or free period, discount on launch pricing, early access recognition, direct access to product team. Run beta for 4-8 weeks depending on complexity. Collect quantitative data (usage metrics, NPS, feature adoption) and qualitative data (feedback themes, pain points, delight moments). Close beta with a clear decision: launch as planned, delay for fixes, or pivot. ### Step 6: Launch Execution Create launch timeline working backward from launch day: T-8 to T-12 weeks (T1 only): strategy finalization, ICP validation, beta recruitment, channel preparation, creative development, press and analyst outreach scheduling. T-4 to T-6 weeks: beta program launch, internal enablement (sales training, support training, documentation), messaging finalization, asset production (landing page, emails, social posts, sales deck, demo video). T-2 to T-4 weeks: beta program ongoing, content development (blog posts, case studies, white papers), channel testing (email previews, ad testing, landing page QA), metrics dashboard setup. T-0 to T-2 weeks: beta program close, final fixes based on feedback, asset finalization, launch sequence preparation, go/no-go decision. Launch day: execute launch sequence per channel. Monitor real-time metrics: website traffic, signups, activation, support volume, press coverage, social mentions. Activate internal comms: all-hands announcement, slack channels, customer-facing team briefings. Post-launch: D7 check-in (early metrics, issues), D30 review (adoption trends, funnel metrics, qualitative feedback), D60 review (retention, revenue impact, competitive response), D90 review (full performance against success criteria, lessons learned, next priorities). ### Step 7: Post-Launch Optimization After launch, shift from campaign mode to optimization mode. Monitor channel performance and reallocate budget to highest-performing channels. A/B test messaging and creative based on launch data. Extend reach to secondary ICP segments if primary segment is saturated. Capture and document learnings for the next GTM launch. ## Rules - ICP must be validated with existing customer data and interviews before launch — no untested assumptions. - Launch tier must match resource allocation — T1 needs full team, T3 should not consume disproportionate resources. - Channels must reach the defined ICP, not the broadest possible audience — targeted > broad. - Beta participants must match ICP to produce relevant feedback — beta feedback from non-ICP users misleads. - Messaging must be tested with target customers before launch — untested messaging risks missing the mark. - Launch timeline must include buffer (20% of total planning time) for unexpected delays. - Post-launch review must be scheduled before launch day — schedule first, execute later. - Learnings must be documented for future GTM efforts in a shared, searchable repository. - Competitive positioning must be validated against actual competitor messaging, not assumptions. - Go/no-go decision must be based on data, not schedule pressure — delaying is better than launching poorly. - Channel selection must prioritize ICP reach over breadth — narrow and deep beats wide and shallow. ## Framework / Methodologies ### Positioning Framework (April Dunford) Step 1: Competitive alternatives — who does the customer compare you to? Step 2: Unique attributes — what can you do that alternatives cannot? Step 3: Value — what is the impact of those unique attributes for the customer? Step 4: Target market — who cares most about this value? Step 5: Category — what market category makes the value clear? Step 6: Positioning statement — synthesize into a clear statement. Validate with customers before launch. ### Jobs-to-Be-Done GTM Framework Focus GTM messaging on the progress the customer wants to make (the job), not the product features. Functional job (what they want to accomplish), emotional job (how they want to feel), social job (how they want to be perceived). GTM messaging that addresses all three job types outperforms feature-focused messaging by 3-5x. ### Crossing the Chasm (Geoffrey Moore) Technology Adoption Lifecycle: innovators, early adopters, early majority, late majority, laggards. The chasm between early adopters (who buy vision and potential) and early majority (who buy proven solutions) is where most products fail. GTM strategy must explicitly address chasm-crossing: focus on a narrow beachhead segment, provide complete solution, build proof points. ### Channel-Fit Framework Match channel to product type and ICP: complex B2B → sales-led (high touch, long cycle). Simple B2B → product-led + inside sales (medium touch, medium cycle). Consumer → product-led (low touch, short cycle). Enterprise → sales-led + strategic partnerships (high touch, long cycle, high ACV). Each channel requires different GTM capabilities, org structure, and metrics. ### BLM (Business Leadership Model) for GTM Three lenses for GTM strategy: Market (where to play — which segments, which geographies), Offer (how to win — what product, what pricing, what positioning), Capabilities (what capabilities are needed — what team, what channels, what systems). The three lenses must be aligned and internally consistent. ### Product-Led GTM Framework Growth driven by product experience, not sales or marketing. Self-serve signup, in-app conversion, product usage drives expansion. Key metrics: self-serve conversion rate, time-to-value, activation rate, expansion revenue. Product-led GTM requires different investment (product analytics, in-app messaging, onboarding optimization) than sales-led GTM (SDRs, demos, proposals). ## Common Pitfalls ### ICP Too Broad Defining ICP too broadly to maximize addressable market. Results in messaging that resonates with no one, channels that reach the wrong audience, and sales that are inefficient. Mitigation: narrow ICP to the segment with strongest product-market fit. Expand only after dominating the initial segment. ### Messaging Without Validation Crafting positioning and messaging based on team assumptions without testing with target customers. Results in messaging that misses the mark, resonates weakly, or uses language customers do not understand. Mitigation: test messaging with 10-20 target customers before launch. Use their language, not internal jargon. ### Under-Resourced T1 Launch Treating a T1 launch (major product) with T3 resources (minor effort). Results in poor execution across channels, missed deadlines, and underwhelming launch impact. Mitigation: align launch tier with resource allocation honestly. If resources are insufficient, reduce launch scope or delay. ### Ignoring Post-Launch Investing all energy in launch day and nothing in post-launch optimization. The launch is the start, not the end. Most revenue comes in the weeks and months after launch. Mitigation: plan post-launch campaigns and reviews before launch day. Allocate 60% of GTM budget to post-launch activities. ### Beta Program Misalignment Recruiting beta participants who do not match ICP. Results in feedback that is not relevant for the target market, false validation, or misleading feature requests. Mitigation: qualify beta participants against the ICP. Exclude non-ICP participants from feedback analysis. ### Channel Overload Using too many channels with insufficient resources per channel. Results in mediocre execution everywhere and strong execution nowhere. Mitigation: select 2-3 channels maximum for launch. Do them well rather than spreading thin. ## Best Practices ### ICP Definition - Validate ICP with existing customer data — analyze which segments have highest retention, LTV, and expansion. - Include behavioral attributes (current solution, purchase triggers, buying process) — not just demographics. - Create a specific, named example company that represents the ICP for team alignment. - Define anti-ICP to prevent wasting resources on wrong-fit customers. - Revisit ICP quarterly as product and market evolve. ### Launch Tiering - Be honest about launch scope — a T2 with T1 ambitions will disappoint. - Document the tier decision criteria and rationale for stakeholder alignment. - Create tier-specific launch templates to streamline execution. - For T1 launches, assign a dedicated GTM lead with cross-functional authority. - Reserve T1 launches for truly new products or major platform changes, not every release. ### Channel Selection - Select channels based on where ICP spends time, not where execution is easiest. - Estimate channel ROI before committing resources: reach, conversion, cost, time-to-impact. - Test new channels with small budgets before scaling. - Integrate channels for funnel coverage: top-of-funnel (awareness), mid-funnel (consideration), bottom-of-funnel (conversion). - Measure channel attribution to understand each channel's role in the customer journey. ### Messaging - Use customer language, not internal jargon — test with customers to confirm. - Quantify benefits where possible: "reduce onboarding time by 40%" not "improve efficiency." - Differentiate against the customer's current solution, not just competitors. - Create messaging variants for each stage of the buyer journey: awareness (problem), consideration (solution), decision (proof). - Refresh messaging quarterly based on market feedback and competitive changes. ### Execution - Plan backward from launch date with clear milestones and owners. - Build 20% buffer into the timeline for unexpected delays. - Run a go/no-go decision at T-2 weeks based on data, not schedule. - Execute the launch sequence in order: existing customers first, then prospects, then press. - Monitor launch metrics daily in the first week, weekly thereafter. ## Templates & Tools ### ICP Definition Template ``` ### Ideal Customer Profile Firmographics: - Company size: {range} - Industry: {industries} - Revenue: {range} - Geography: {regions} Demographics: - Role: {title} - Seniority: {level} - Decision authority: {buyer / influencer / user} - Technical sophistication: {level} Behavioral: - Current solution: {competitors or manual process} - Pain points: {top 3} - Purchase trigger: {event that triggers buying} - Budget: {range} - Buying process: {self-serve / sales-assisted / procurement} ### Anti-ICP - {segment} — Reason: {why excluded} - {segment} — Reason: {why excluded} ### ICP Example Company: {named example} Persona: {named persona} Why they fit: {explanation} ``` ### Launch Tier Assessment ``` ### Criteria Product scope: {new product / major feature / minor feature} Revenue impact: {high / medium / low} Strategic importance: {high / medium / low} Customer impact: {high / medium / low} Resource availability: {high / medium / low} Timeline: {12+ weeks / 4-8 weeks / 1-3 weeks} ### Tier Determination: T{X} Rationale: {explanation of why this tier} ### Resource Allocation GTM lead: {yes/no} — {FTE allocation} Marketing: {channels and resource allocation} Sales: {enablement and resource allocation} Product: {support and resource allocation} Engineering: {support and resource allocation} ``` ### Channel Strategy Template ``` ### Channel Mix | Channel | Stage | Reach | Expected Conversion | Cost | Priority | |---------|-------|-------|-------------------|------|----------| | {name} | {top/mid/bottom} | {ICP reach estimate} | {% estimate} | {cost estimate} | {H/M/L} | ### Primary Channel: {name} Strategy: {approach} Assets needed: {list} Owner: {name} Timeline: {dates} Budget: {amount} ### Secondary Channel: {name} Strategy: {approach} Assets needed: {list} Owner: {name} Timeline: {dates} Budget: {amount} ``` ### Messaging Framework Template ``` ### Positioning For {ICP} who {need}, {product} is a {category} that {key benefit}. Unlike {competitor}, {product} {differentiator}. ### Messaging Hierarchy Headline: {5-10 words} Elevator pitch: {2-3 sentences} Value propositions (3-5 bullets): - {quantified benefit} - {quantified benefit} - {quantified benefit} Features: - {feature}: {benefit} - {feature}: {benefit} ### Proof Points {metric}: {source} {testimonial}: {customer name} {case study}: {link} ### Channel Variants In-app: {short version} Email: {benefit-driven version} Sales: {ROI-focused version} Press: {newsworthy version} Social: {conversational version} ``` ### Launch Timeline Template ``` ### Pre-Launch (T-{X} weeks) | Week | Activity | Owner | Dependencies | Status | |------|---------|-------|-------------|--------| | -12 | {activity} | {owner} | {dependencies} | {status} | ### Launch Week | Day | Activity | Owner | Channel | Expected Outcome | |-----|---------|-------|---------|----------------| | Mon | {activity} | {owner} | {channel} | {outcome} | ### Post-Launch | Timing | Activity | Owner | Success Criteria | |--------|---------|-------|----------------| | D7 | {review} | {owner} | {criteria} | | D30 | {review} | {owner} | {criteria} | | D60 | {review} | {owner} | {criteria} | | D90 | {review} | {owner} | {criteria} | ``` ### Beta Program Template ``` ### Overview Goals: {list of goals} Participants needed: {N} Duration: {weeks} Incentive: {description} ### Qualification Criteria Must-have: {criteria} Nice-to-have: {criteria} Exclude: {criteria} ### Cadence Week 1: Onboarding, welcome survey Weeks 2-X: Weekly feedback survey, bi-weekly check-in call Final week: NPS survey, retrospective, reference call request ### Success Criteria Adoption rate: {target}% NPS: {target} Critical feedback items resolved: {count} Reference customers: {count} ``` ### Post-Launch Review Template ``` ### D30/D60/D90 Review Date: {date} Review period: {start} to {end} ### Performance vs Targets | Metric | Target | Actual | Variance | Action | |--------|--------|--------|----------|--------| | {m1} | {t} | {a} | {v} | {action} | ### Key Insights What went well: {list} What could be improved: {list} Surprises: {list} ### Competitive Response Competitor actions: {list} Our response: {list} ### Lessons Learned {key lessons for future GTM efforts} ``` ## Case Studies ### SaaS Product Launch with ICP Validation A B2B analytics company planned to launch a new dashboard product. Initial ICP: all product managers at SaaS companies of any size. Customer data analysis revealed that retention was 3x higher for product managers at growth-stage companies (50-500 employees) who had direct control over their analytics budget. ICP was narrowed accordingly. GTM impact: messaging focused on "self-serve analytics for growing product teams" resonated strongly. Channels selected: product-led (in-app upgrade from existing product), content marketing (blog posts on product analytics for growth), direct sales to growth-stage companies. Beta recruited 35 growth-stage product teams. Launch achieved 220% of revenue target in first quarter. Post-launch analysis: the narrowed ICP converted at 3x the rate of the broad ICP. ### Tier Misclassification Recovery A project management SaaS classified a major workflow automation feature as T2 (targeted outreach). The feature was strategically important and would affect every user. T2 resources (3-person team, 4-week timeline) were insufficient for the scope. Result: launch was delayed 6 weeks, channel execution was uneven, in-app messaging was poorly designed, sales team was not enabled until 2 weeks post-launch. Adoption was 40% below target at D30. Recovery: reclassified as T1 at D45. Assigned dedicated GTM lead, upgraded channel execution, re-enabled sales team, ran targeted email campaign. Adoption reached 90% of target by D90. Lesson: tier honestly based on scope and strategic importance, not resource availability. ### Product-Led vs. Sales-Led Channel Selection A cybersecurity startup launched a new compliance tool. Two-channel experiment: product-led (self-serve signup, in-app conversion) for SMB, sales-led (SDR outreach, demo, proposal) for enterprise. Results after 6 months: product-led channel converted 12% of signups with $0.30 CAC (cost per acquired user). Sales-led channel converted 8% of qualified leads with $4,500 CAC but $85K ACV. Decision: maintained both channels but invested differently. Allocated 70% of GTM budget to sales-led (higher ROI despite higher CAC) and 30% to product-led (growth potential, lower touch). Lesson: channel selection depends on ICP ACV and conversion economics, not just reach. ## References - references/channel-strategy.md — Channel Strategy - references/go-to-market-advanced.md — Go To Market Advanced Topics - references/go-to-market-fundamentals.md — Go To Market Fundamentals - references/gtm-launch-execution.md — GTM Launch Execution Playbook - references/gtm-strategy-playbook.md — GTM Strategy Playbook - references/launch-checklist.md — Launch Checklist - references/launch-tiers.md — Launch Tiers - references/positioning-guide.md — Product Positioning Guide ## Handoff For pricing strategy support, hand off to `product-pricing-strategy`. For growth experiments post-launch, hand off to `product-growth-engineering`. For customer journey analysis to inform GTM touchpoints, hand off to `product-customer-journey`. For experiment design on launch messaging, hand off to `product-ab-testing`. ## Implementation Patterns ### Observer Pattern for Event Handling ` interface EventObserver { onEvent(event: T): Promise; } class EventBus { private observers: Set> = new Set(); subscribe(observer: EventObserver): void { this.observers.add(observer); } unsubscribe(observer: EventObserver): void { this.observers.delete(observer); } async emit(event: T): Promise { const results = Array.from(this.observers).map(o => o.onEvent(event)); await Promise.allSettled(results); } } ` ### Configuration-Driven Approach ` config: defaults: timeout: 30s retryCount: 3 overrides: production: timeout: 60s retryCount: 5 development: timeout: 300s retryCount: 1 ` ## Production Considerations ### Deployment Checklist - [ ] Configuration validated against schema before startup - [ ] Health check endpoints registered and monitored - [ ] Graceful shutdown with draining period (30s timeout) - [ ] Resource limits configured (CPU, memory, file descriptors) - [ ] Log level set appropriate for environment - [ ] Metrics endpoint secured and exposed - [ ] Rate limiting configured per-tier - [ ] TLS certificates valid and auto-renewing - [ ] Database migrations run as separate deployment step - [ ] Feature flags ready for gradual rollout ### Monitoring and Alerting | Metric | Threshold | Severity | Action | |--------|-----------|----------|--------| | Error rate | > 1% over 5min | Critical | Page on-call | | p99 latency | > 2s over 5min | Warning | Investigate | | Throughput drop | > 50% over 1min | Critical | Check upstream | | Queue depth | > 1000 over 1min | Warning | Scale consumers | | Disk usage | > 85% | Warning | Clean or expand | | Memory usage | > 90% heap | Critical | Restart or scale | ## Anti-Patterns | Anti-Pattern | Symptom | Root Cause | Solution | |-------------|---------|------------|----------| | Premature optimization | Complex code for no measured benefit | Guessing instead of profiling | Measure first, optimize based on data | | Copy-paste reuse | Duplicate code across codebase | Lack of abstraction | Extract shared logic into libraries | | Gold-plating | Features with no current requirement | Over-engineering | YAGNI — build what's needed now | | Magical thinking | Assumptions without validation | Skipping error handling | Handle all failure modes explicitly | ## Performance Optimization ### Caching Strategy Cache hierarchy: L1 (in-memory local) → L2 (distributed Redis/Memcached) → L3 (CDN/Edge). Cache invalidation: TTL-based (simple, stale), event-based (complex, fresh), write-through (consistent, higher write latency), write-behind (fast writes, eventual consistency). ### Resource Pooling - Database connections: Pool of reusable connections (HikariCP, pgBouncer) - HTTP connections: Keep-alive + connection pooling for external calls - Thread pool: Bounded thread pools for async task execution ### Profiling Methodology 1. Establish baseline with production traffic profile 2. Profile CPU with sampling profiler (pprof, perf, async-profiler) 3. Profile memory with heap dumps and allocation tracking 4. Profile I/O with strace/perf trace for syscall analysis 5. Profile latency with distributed tracing (OpenTelemetry) 6. Identify bottleneck, formulate hypothesis, implement fix 7. Re-profile to verify improvement, repeat ## Security Considerations ### Threat Modeling (STRIDE) - Spoofing: Identity validation, authentication - Tampering: Integrity checks, digital signatures - Repudiation: Audit logs, non-repudiation - Information disclosure: Encryption, access control - Denial of service: Rate limiting, resource quotas - Elevation of privilege: Principle of least privilege ### Supply Chain Security - Dependency scanning: Snyk, Dependabot, Trivy - SBOM generation: CycloneDX or SPDX format - Signed commits: GPG or SSH commit signing - Artifact verification: Checksum validation, signature verification ### Secrets Management - Secrets never in code — always in secrets manager (Vault, AWS Secrets Manager) - Rotation policy: Rotate database credentials every 90 days - Access audit: Log every secrets access, alert on anomalies - Encryption at rest and in transit for all secrets - Principle of least privilege: each service gets only its own secrets ## Rules - Default-deny security posture — allow only explicitly required access. - All inputs validated, all outputs encoded, all errors handled. - Defend in depth — multiple layers of security controls. - Fail securely — errors default to safe behavior. - Log security-relevant events for audit and investigation. - Keep dependencies updated — automate vulnerability scanning. - Design for observability from day one, not as an afterthought. - Document all architectural decisions with rationale. - Review code for security, performance, and correctness before merging.