Initial commit
This commit is contained in:
Zhongwei Li
436
skills/technical-launch-planner/references/launch_messaging.md
Normal file
436
skills/technical-launch-planner/references/launch_messaging.md
Normal file
@@ -0,0 +1,436 @@
|
||||
# Technical Launch Messaging
|
||||
|
||||
Messaging frameworks and templates for developer-focused product launches.
|
||||
|
||||
---
|
||||
|
||||
## Messaging Principles for Developers
|
||||
|
||||
### DO:
|
||||
- ✅ **Be specific** - Use concrete technical details
|
||||
- ✅ **Show code** - Developers want to see, not read
|
||||
- ✅ **State limitations** - Honest about what it can't do
|
||||
- ✅ **Provide metrics** - Performance numbers, benchmarks
|
||||
- ✅ **Explain why** - Technical reasoning matters
|
||||
- ✅ **Link to docs** - Make it easy to try
|
||||
|
||||
### DON'T:
|
||||
- ❌ **Use marketing jargon** - "Revolutionary", "game-changing"
|
||||
- ❌ **Oversimplify** - Developers can handle complexity
|
||||
- ❌ **Hide limitations** - They'll find them anyway
|
||||
- ❌ **Make unsubstantiated claims** - Back it up with data
|
||||
- ❌ **Skip code examples** - Abstract descriptions fail
|
||||
|
||||
---
|
||||
|
||||
## Messaging Framework
|
||||
|
||||
### Problem Statement
|
||||
**Format:** [Current pain point] → [Why existing solutions fail] → [Impact on developers]
|
||||
|
||||
**Example:**
|
||||
"Debugging distributed systems is painful. Traditional logging tools weren't built for microservices, forcing developers to manually correlate logs across dozens of services. This turns a 5-minute bug into a 5-hour investigation."
|
||||
|
||||
---
|
||||
|
||||
### Solution Overview
|
||||
**Format:** [What it is] → [How it works (technical)] → [Key benefit]
|
||||
|
||||
**Example:**
|
||||
"Distributed Tracer automatically instruments your services to create a unified view of requests across your entire stack. Using OpenTelemetry standards, it correlates logs, metrics, and traces in real-time, reducing MTTR by 80%."
|
||||
|
||||
---
|
||||
|
||||
### Key Differentiators
|
||||
**Format:** [Feature] → [Technical implementation] → [Why it matters]
|
||||
|
||||
**Example:**
|
||||
"Zero-config auto-instrumentation. Our SDK uses bytecode injection to automatically trace all HTTP calls, database queries, and external APIs without code changes. Deploy in under 5 minutes instead of days."
|
||||
|
||||
---
|
||||
|
||||
## Launch Announcement Template
|
||||
|
||||
### Blog Post Structure
|
||||
|
||||
```markdown
|
||||
# Introducing [Product]: [One-line value prop]
|
||||
|
||||
## TL;DR
|
||||
- [Key point 1 with metric]
|
||||
- [Key point 2 with metric]
|
||||
- [Get started link]
|
||||
|
||||
## The Problem
|
||||
|
||||
[Describe the developer pain in detail. Be specific.]
|
||||
|
||||
**Example:**
|
||||
Every API call in a distributed system touches 5-10 services. When something breaks, you're left grep'ing through gigabytes of logs, trying to piece together what happened. We've all been there.
|
||||
|
||||
## The Solution
|
||||
|
||||
[High-level overview]
|
||||
|
||||
**How it works:**
|
||||
|
||||
\`\`\`python
|
||||
# Show concrete code example
|
||||
import tracer
|
||||
|
||||
tracer.init(api_key="your_key")
|
||||
|
||||
# That's it. All requests automatically traced.
|
||||
\`\`\`
|
||||
|
||||
## Key Features
|
||||
|
||||
### 1. [Feature Name]
|
||||
|
||||
**What it does:** [Technical description]
|
||||
|
||||
**Why it matters:** [Developer benefit]
|
||||
|
||||
**Example:**
|
||||
\`\`\`[language]
|
||||
[Code showing the feature]
|
||||
\`\`\`
|
||||
|
||||
[Repeat for top 3-5 features]
|
||||
|
||||
## Performance
|
||||
|
||||
[Include benchmarks, metrics]
|
||||
|
||||
- Latency: < 1ms overhead (p99)
|
||||
- Throughput: 100K traces/second per instance
|
||||
- Storage: 90-day retention included
|
||||
|
||||
## Get Started in 5 Minutes
|
||||
|
||||
\`\`\`bash
|
||||
# Installation
|
||||
npm install @company/sdk
|
||||
|
||||
# Basic setup
|
||||
[Minimal code to get value]
|
||||
\`\`\`
|
||||
|
||||
[Link to full documentation]
|
||||
|
||||
## What's Next
|
||||
|
||||
[Roadmap tease for 1-2 upcoming features]
|
||||
|
||||
## Resources
|
||||
|
||||
- [Documentation]
|
||||
- [Sample apps]
|
||||
- [API reference]
|
||||
- [Community Discord]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Email Announcement Template
|
||||
|
||||
**Subject Lines (A/B test these):**
|
||||
- "[Product] is now GA - [Key benefit]"
|
||||
- "Ship faster with [Product]"
|
||||
- "[Pain point solved]: Introducing [Product]"
|
||||
|
||||
**Body:**
|
||||
|
||||
```
|
||||
Hi [Name],
|
||||
|
||||
We're excited to announce [Product] is now generally available.
|
||||
|
||||
What it does:
|
||||
[One sentence technical description]
|
||||
|
||||
Why it matters to you:
|
||||
[Specific benefit for recipient's role/tech stack]
|
||||
|
||||
Get started in 5 minutes:
|
||||
|
||||
```[language]
|
||||
[Minimal code example]
|
||||
```
|
||||
|
||||
Key features:
|
||||
• [Feature 1 - one line]
|
||||
• [Feature 2 - one line]
|
||||
• [Feature 3 - one line]
|
||||
|
||||
Resources:
|
||||
→ Documentation: [link]
|
||||
→ Sample code: [link]
|
||||
→ API reference: [link]
|
||||
|
||||
[If Beta]: As a beta user, you already have access. Check your dashboard to enable.
|
||||
|
||||
Questions? Hit reply or join us in [Discord/Slack].
|
||||
|
||||
Happy building,
|
||||
[Name]
|
||||
[Title]
|
||||
|
||||
P.S. [Call to action or incentive]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Social Media Templates
|
||||
|
||||
### Twitter/X (Technical)
|
||||
|
||||
**Format 1: Problem → Solution**
|
||||
```
|
||||
Tired of [pain point]?
|
||||
|
||||
[Product] gives you [benefit]:
|
||||
• [Feature 1]
|
||||
• [Feature 2]
|
||||
• [Feature 3]
|
||||
|
||||
Get started: [link]
|
||||
|
||||
[Include code snippet image or architecture diagram]
|
||||
```
|
||||
|
||||
**Format 2: Show the Code**
|
||||
```
|
||||
This is all it takes to [achieve outcome]:
|
||||
|
||||
[Code snippet image]
|
||||
|
||||
Try it now: [link]
|
||||
#developer #[tech stack]
|
||||
```
|
||||
|
||||
**Format 3: Metrics**
|
||||
```
|
||||
We just reduced distributed tracing overhead from 5ms to < 1ms.
|
||||
|
||||
How? [Link to technical blog post]
|
||||
|
||||
Open-sourced the approach: [GitHub link]
|
||||
```
|
||||
|
||||
### LinkedIn (Business + Technical)
|
||||
|
||||
**Format:**
|
||||
```
|
||||
[Company] is launching [Product] today.
|
||||
|
||||
The problem we're solving:
|
||||
[2-3 sentences about developer pain]
|
||||
|
||||
Our approach:
|
||||
[Technical differentiation]
|
||||
|
||||
Early results from beta:
|
||||
• [Metric/testimonial 1]
|
||||
• [Metric/testimonial 2]
|
||||
|
||||
If you're working on [use case], check it out: [link]
|
||||
|
||||
[Include demo video or architecture diagram]
|
||||
```
|
||||
|
||||
### Hacker News Post
|
||||
|
||||
**Title Format:**
|
||||
- "Show HN: [Product] – [One-line description]"
|
||||
- "[Product] – [Interesting technical approach]"
|
||||
|
||||
**Comment (required):**
|
||||
```
|
||||
Hey HN! Creator here.
|
||||
|
||||
We built [Product] to solve [problem we experienced].
|
||||
|
||||
Technical approach:
|
||||
[2-3 paragraphs explaining interesting technical decisions]
|
||||
|
||||
What's different:
|
||||
[Why this approach vs. alternatives]
|
||||
|
||||
How to try it:
|
||||
[Quick start instructions]
|
||||
|
||||
Happy to answer questions!
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Positioning Statements
|
||||
|
||||
### General Template
|
||||
"For [target developers] who [need/pain point], [Product] is a [category] that [key benefit]. Unlike [alternatives], we [unique differentiation]."
|
||||
|
||||
### Examples
|
||||
|
||||
**API Tool:**
|
||||
"For backend developers who need reliable API integrations, FastAPI Connect is an API orchestration platform that auto-retries, caches, and monitors all external calls. Unlike building retry logic yourself, we provide production-grade reliability out of the box."
|
||||
|
||||
**Developer Platform:**
|
||||
"For platform teams building internal developer platforms, DevHub is a self-service portal that gives developers one-click access to infrastructure. Unlike traditional ticketing systems, we automate provisioning in seconds instead of days."
|
||||
|
||||
---
|
||||
|
||||
## Value Propositions by Persona
|
||||
|
||||
### Backend Developers
|
||||
**Focus:** Performance, reliability, ease of integration
|
||||
|
||||
"Reduce latency by 40% with one line of code"
|
||||
|
||||
### DevOps/SRE
|
||||
**Focus:** Reliability, observability, automation
|
||||
|
||||
"Cut MTTR from hours to minutes with automated root cause analysis"
|
||||
|
||||
### Engineering Leaders
|
||||
**Focus:** Productivity, costs, team velocity
|
||||
|
||||
"Ship 2x faster by eliminating [bottleneck]"
|
||||
|
||||
### Security Teams
|
||||
**Focus:** Compliance, security, visibility
|
||||
|
||||
"SOC 2 Type II compliant with built-in audit logging"
|
||||
|
||||
---
|
||||
|
||||
## Messaging by Launch Tier
|
||||
|
||||
### Tier 1 (Major Launch)
|
||||
- **Bold claims** backed by data
|
||||
- **Vision** for the future
|
||||
- **Ecosystem** impact
|
||||
- **Industry** transformation
|
||||
|
||||
**Example:**
|
||||
"Redefining how developers build distributed systems"
|
||||
|
||||
### Tier 2 (Standard)
|
||||
- **Practical benefits**
|
||||
- **Specific use cases**
|
||||
- **Integration** value
|
||||
- **Productivity** gains
|
||||
|
||||
**Example:**
|
||||
"The fastest way to add real-time features to your app"
|
||||
|
||||
### Tier 3 (Minor)
|
||||
- **Specific improvement**
|
||||
- **Developer benefit**
|
||||
- **Clear changelog**
|
||||
|
||||
**Example:**
|
||||
"Python SDK now 3x faster with async support"
|
||||
|
||||
---
|
||||
|
||||
## Competitive Positioning
|
||||
|
||||
### When to Mention Competitors
|
||||
|
||||
**DO mention when:**
|
||||
- You have clear technical superiority
|
||||
- Migration is a key use case
|
||||
- Comparison requested by prospects
|
||||
|
||||
**DON'T mention when:**
|
||||
- You're the market leader
|
||||
- Competitor is much larger
|
||||
- Claim isn't defensible
|
||||
|
||||
### Competitive Messaging Template
|
||||
|
||||
"Unlike [Competitor], [Product] [specific advantage]:
|
||||
|
||||
**[Competitor]:**
|
||||
- [Limitation 1]
|
||||
- [Limitation 2]
|
||||
|
||||
**[Product]:**
|
||||
- [Advantage 1] - [metric]
|
||||
- [Advantage 2] - [metric]
|
||||
|
||||
[Code comparison or performance benchmark]"
|
||||
|
||||
---
|
||||
|
||||
## Technical Credibility Signals
|
||||
|
||||
Include these to build trust:
|
||||
|
||||
- **Open source** components used
|
||||
- **Standards** supported (OpenTelemetry, OAuth, etc.)
|
||||
- **Scale** handled (requests/sec, data volume)
|
||||
- **Customers** using in production (if allowed)
|
||||
- **Team background** (ex-Google, ex-AWS, etc.)
|
||||
- **Security** certifications (SOC 2, ISO 27001)
|
||||
- **Performance** benchmarks
|
||||
- **GitHub** stars (if applicable)
|
||||
|
||||
---
|
||||
|
||||
## Avoiding Common Mistakes
|
||||
|
||||
### Mistake 1: Too Abstract
|
||||
**Bad:** "Simplify your workflow"
|
||||
**Good:** "Reduce deployment time from 45 minutes to 2 minutes"
|
||||
|
||||
### Mistake 2: Jargon Overload
|
||||
**Bad:** "Leverage synergistic paradigms"
|
||||
**Good:** "Run the same code on AWS, GCP, and Azure"
|
||||
|
||||
### Mistake 3: No Proof
|
||||
**Bad:** "The fastest API"
|
||||
**Good:** "p99 latency < 50ms (see benchmark: [link])"
|
||||
|
||||
### Mistake 4: Feature List
|
||||
**Bad:** "Includes caching, retries, and monitoring"
|
||||
**Good:** "Auto-retry failed requests up to 3x with exponential backoff"
|
||||
|
||||
### Mistake 5: Ignoring Migration
|
||||
**Bad:** [No mention of existing solutions]
|
||||
**Good:** "Migrate from [Competitor] in under 1 hour: [guide]"
|
||||
|
||||
---
|
||||
|
||||
## Testing Your Messaging
|
||||
|
||||
### Internal Test
|
||||
- [ ] Can a new engineer explain the value?
|
||||
- [ ] Do engineers volunteer to use it?
|
||||
- [ ] Does it pass the "so what?" test?
|
||||
|
||||
### External Test
|
||||
- [ ] Beta feedback positive?
|
||||
- [ ] Clear from HN/Reddit comments?
|
||||
- [ ] Low support questions about "what is it?"
|
||||
|
||||
### Metrics to Watch
|
||||
- Email open rate (> 25% good for developer emails)
|
||||
- Click-through rate to docs (> 10%)
|
||||
- Sign-up conversion (depends on product)
|
||||
- Social engagement (shares, comments)
|
||||
- Media pickup (for Tier 1)
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
**Technical messaging succeeds when:**
|
||||
1. Problem is relatable
|
||||
2. Solution is clear (with code)
|
||||
3. Benefits are concrete
|
||||
4. Limitations are honest
|
||||
5. Getting started is easy
|
||||
|
||||
**Keep developer-first always.**
|
||||
Reference in New Issue
Block a user