Developer marketing frameworks and templates you can steal
Practical frameworks and templates for developer marketing. Positioning documents, launch plans, content strategies, and more, all ready to adapt for your products.
Frameworks save time. When you're building a developer marketing program from scratch, you don't need to reinvent every process. You need proven approaches that you can adapt to your specific context. These days frameworks are even more valuable as you can use them to guide your LLM in generate the information you need in a standard format that you can reuse time and again.
Over thirty years marketing developer products, I've developed and refined frameworks for every major product marketing function. This article compiles the most useful ones, complete with templates you can steal and adapt. I use these daily to help me move faster, to focus Claude Code on the most germane and research-intensive tasks, and to deliver what all my stakeholders (PM, Sales, Customer Success, and more) need.
Positioning framework
Positioning defines where your product fits in the competitive landscape and why developers should choose it. Every developer product needs a clear positioning statement with supporting pillars. Strong positioning also enables powerful storytelling that resonates with your audience.
The three-pillar structure
My positioning framework follows principles I've written about in the positioning framework. It's rooted in Aristotle's rhetorical framework and cognitive psychology research on working memory. Each pillar includes four layers: the value claim, a mechanism explaining how you deliver on it, a consequence of inaction, and proof points.
[PRODUCT NAME] is a [CATEGORY]
that helps [TARGET DEVELOPER] achieve [KEY OUTCOME].
- [EMOTIONAL PILLAR] (Pathos): How it makes their life better
- [LOGICAL PILLAR] (Logos): What unique capabilities it provides
- [CREDIBILITY PILLAR] (Ethos): Why they can depend on it
Differentiation summary: [One sentence synthesizing all pillars]
Positioning template
Here's a template you can fill in:
## Positioning document: [Product Name]
### Category test
Category: [Your category] -- Does this alone answer "what is this?"
Use case: [Primary use case] -- Does this alone answer "what is this?"
If either answer is no, revise until they pass.
### Core positioning statement
For [target developer segment] who [experience this specific problem],
[Product Name] is a [category] that [primary benefit].
Unlike [primary alternative], we [key differentiator].
### Problem-framing variants
Category-anchored: [Problem framed as a category gap]
Use-case-anchored: [Problem framed as a workflow pain]
Alternative-anchored: [Problem framed as a displacement story]
Recommended framing: [Which one and why]
### Supporting pillars
**1. [Emotional benefit] (Pathos)**
Brief: [One sentence summary]
How it works: [The mechanism or approach that enables this]
Without this: [What happens if the customer does not act]
Proof points:
- [Specific claim with evidence]
- [Specific claim with evidence]
- [Specific claim with evidence]
**2. [Logical/technical differentiator] (Logos)**
Brief: [One sentence summary]
How it works: [The mechanism or approach that enables this]
Without this: [What happens if the customer does not act]
Proof points:
- [Specific claim with evidence]
- [Specific claim with evidence]
- [Specific claim with evidence]
**3. [Credibility/trust] (Ethos)**
Brief: [One sentence summary]
How it works: [The mechanism or approach that enables this]
Without this: [What happens if the customer does not act]
Proof points:
- [Specific claim with evidence]
- [Specific claim with evidence]
- [Specific claim with evidence]
### Differentiation summary
[One sentence synthesizing all three pillars into a unified story]
### Competitive differentiation
vs [Direct competitor]: [Key differentiator]
vs [Indirect competitor]: [Key differentiator]
vs [Status quo/DIY]: [Key differentiator]
vs [Build-it-yourself]: [Key differentiator]
### Proof points
- [Customer testimonial or case study]
- [Benchmark or performance data]
- [Industry recognition or certification]Example: AWS positioning (circa 2007)
When I was the first Director of Marketing at Amazon Web Services, here's how we applied this framework:
Amazon Web Services is a cloud computing platform
that helps developers build scalable applications quickly.
- Flexible (Pathos): Easy to use and get started.
How: Self-service APIs that let you provision infrastructure
in minutes, not weeks. No procurement process required.
Without it: Developers wait weeks for provisioning approvals
and commit to multi-year contracts before writing a line of code.
Proof: Pay only for what you use, no upfront commitment,
sign up with a credit card and start building immediately.
- Cost-effective (Logos): No contracts, pay as you go,
transparent pricing.
How: Usage-based billing with per-hour granularity and a public
pricing page that requires no sales call to access.
Without it: Teams over-provision infrastructure to avoid running
out of capacity, paying for resources they never use.
Proof: Reduces capital expenditure, turns infrastructure into
operating expense, customers report 30-60% cost savings.
- Dependable (Ethos): Scalability and reliability from the company
who knows how to run infrastructure at web scale.
How: The same infrastructure that powers Amazon.com, with
multi-region redundancy and automated failover.
Without it: Teams build and maintain their own redundancy,
pulling engineering time away from product development.
Proof: Powers Amazon.com, 99.95% SLA, proven at massive scale.
Differentiation summary: AWS is the only cloud platform that
combines self-service simplicity with Amazon-scale reliability,
so developers can build anything without managing infrastructure.
This framework has guided my positioning work for twenty years. The expanded template adds layers (mechanism, consequence, differentiation summary) and validation steps (category test, problem-framing variants) that I refined after studying several other positioning frameworks alongside Aristotle's. Adapt it to your product, but respect the underlying structure.
Each pillar's content can also be reorganized into a vertical argument thread: one column per pillar, running from sub-problem through mechanism through features through benefit. Each column is a self-contained narrative that can be lifted out as a blog post, a sales talk track, or a conference talk section. The horizontal hierarchy ensures consistency. The vertical columns enable execution. For the conceptual explanation, see the positioning framework.
Create a comprehensive positioning framework for [PRODUCT NAME], a developer product.
PRODUCT CONTEXT:
- What it does: [DESCRIBE THE CORE FUNCTIONALITY]
- Target developers: [ROLE, SENIORITY, TECH STACK]
- Primary competitors: [LIST 2-4 WITH BRIEF DESCRIPTIONS]
- Current traction: [USERS, CUSTOMERS, OR STAGE]
DELIVER THE FOLLOWING:
1. CATEGORY TEST
- Does the category descriptor alone answer "what is this product?"
- Does the primary use case alone answer "what is this product?"
- If either fails, revise before continuing.
2. POSITIONING STATEMENT
"For [target developers] who [problem],
[Product] is a [category] that [benefit].
Unlike [primary alternative], we [differentiator]."
3. PROBLEM-FRAMING VARIANTS
Rewrite the problem three ways:
- Category-anchored: frame as a gap in the category
- Use-case-anchored: frame as a daily workflow pain
- Alternative-anchored: frame as frustration with the current approach
Recommend which framing fits the go-to-market motion.
4. THREE MESSAGING PILLARS (Aristotle's Framework)
Pillar 1 - Emotional Appeal (Pathos):
- Value claim: Why will developers love using this?
- How it works: The mechanism that enables this benefit
- Without this: What happens if the developer does not act
- Proof points: testimonials, community sentiment, adoption stories
Pillar 2 - Logical Appeal (Logos):
- Value claim: What unique technical capabilities does it have?
- How it works: The mechanism that enables this benefit
- Without this: What happens if the developer does not act
- Proof points: benchmarks, performance data, feature comparisons
Pillar 3 - Credibility Appeal (Ethos):
- Value claim: Why can developers depend on this long-term?
- How it works: The mechanism that enables this benefit
- Without this: What happens if the developer does not act
- Proof points: customer logos, uptime stats, team credentials
5. DIFFERENTIATION SUMMARY
One sentence synthesizing all three pillars.
6. COMPETITIVE DIFFERENTIATION
For each competitor, provide:
- What they genuinely do well
- Where you have defensible advantages
- The consequence for the customer of choosing them over you
7. VALIDATION
Run four tests on the completed positioning:
- Duck test: Does it clearly name what the product is?
- Category test: Can the category alone classify the product?
- Swap test: Can a competitor say the same statement truthfully?
- Consequence test: Does each pillar have a tangible cost of inaction?
Flag any failures and suggest revisions.Go-to-market plan template
Every launch needs a plan. I've written extensively about how to write a go-to-market plan, but here's a condensed template.
## Go-to-market plan: [Product/Feature Name]
### Overview
**Launch date**: [Date]
**Launch tier**: [1/2/3 - see tier definitions below]
**Owner**: [Name]
**Stakeholders**: [List]
### Objectives
1. [Primary objective with measurable target]
2. [Secondary objective with measurable target]
3. [Tertiary objective with measurable target]
### Target audience
**Primary ICP**: [Description]
**Secondary ICP**: [Description]
### Key messages
**Headline**: [One sentence summary]
**Value prop 1**: [First key message]
**Value prop 2**: [Second key message]
**Value prop 3**: [Third key message]
### Launch tier definition
- Tier 1: Major product launch, full marketing push
- Tier 2: Significant feature, moderate marketing push
- Tier 3: Minor feature, lightweight announcement
### Tactics by tier
**Tier 1 tactics:**
- [ ] Press release and media outreach
- [ ] Blog post (see launch post template)
- [ ] Email to full list
- [ ] Social media campaign
- [ ] Paid promotion
- [ ] Webinar or live event
- [ ] Partner communications
- [ ] Sales enablement
- [ ] Customer advisory board preview
**Tier 2 tactics:**
- [ ] Blog post
- [ ] Email to relevant segment
- [ ] Social media posts
- [ ] Documentation update
- [ ] Sales notification
**Tier 3 tactics:**
- [ ] Changelog entry
- [ ] Documentation update
- [ ] Social mention
### Timeline
| Date | Activity | Owner | Status |
|------|----------|-------|--------|
| T-14 | Messaging approved | PMM | |
| T-7 | Blog post drafted | Content | |
| T-3 | Blog post reviewed | Eng | |
| T-1 | Assets staged | Marketing | |
| T-0 | Launch! | All | |
### Measurement
**Success metrics:**
- [Metric 1]: Target [X]
- [Metric 2]: Target [Y]
- [Metric 3]: Target [Z]
**Tracking plan:**
- [How you'll track each metric]Create a developer product launch plan for [PRODUCT/FEATURE NAME].
CONTEXT:
- Launch date: [DATE]
- Product type: [NEW PRODUCT / MAJOR FEATURE / MINOR UPDATE]
- Target audience: [DESCRIBE TARGET DEVELOPERS]
- Primary goal: [ADOPTION / AWARENESS / REVENUE]
DELIVER THE FOLLOWING:
1. LAUNCH TIER CLASSIFICATION
Classify as Tier 1 (major), Tier 2 (significant), or Tier 3 (minor) with justification.
2. PRE-LAUNCH TIMELINE
Week-by-week checklist from T-4 weeks to launch day covering:
- Messaging and positioning finalization
- Content asset creation (blog, docs, demo)
- Beta program and early feedback
- Sales and support enablement
3. LAUNCH DAY SCHEDULE
Hour-by-hour plan covering:
- Blog post publication
- Social media (Twitter thread, LinkedIn, Reddit, HN)
- Email announcements
- Community engagement
4. CHANNEL-SPECIFIC TACTICS
For each channel (Product Hunt, Hacker News, Twitter, Reddit, YouTube):
- Optimal timing and format
- Content approach
- Success metrics
5. CONTENT ASSET CHECKLIST
Required and nice-to-have assets with owners and deadlines.
6. POST-LAUNCH PLAN (Weeks 2-4)
Follow-up content, customer interviews, iteration based on feedback.Content strategy framework
Developer content strategy is more than a list of blog post ideas. It's a systematic approach to creating content that serves your audience and achieves your business goals. Understanding the eleven types of content that work for developers is essential before building your strategy.
I've written about six tips for building your content strategy and how to produce developer content at scale. Here's the framework I use:
Content pillars
Define three to five content pillars that align with your positioning. Each pillar represents a major theme you'll create content around.
## Content pillar: [Pillar Name]
**Purpose**: Why this pillar matters to your audience and business
**Keywords**: Primary keywords you're targeting
**Content types**: Blog posts, tutorials, videos, etc.
**Cadence**: How often you'll publish in this pillar
**Owner**: Who's responsible for this pillar
### Sample topics
1. [Topic idea with target keyword]
2. [Topic idea with target keyword]
3. [Topic idea with target keyword]
4. [Topic idea with target keyword]
5. [Topic idea with target keyword]Editorial calendar template
## Editorial calendar: [Quarter/Month]
### Monthly themes
- Month 1: [Theme]
- Month 2: [Theme]
- Month 3: [Theme]
### Content schedule
| Date | Title | Type | Pillar | Author | Status |
|------|-------|------|--------|--------|--------|
| | | | | | Idea |
| | | | | | Outlined |
| | | | | | Drafted |
| | | | | | Reviewed |
| | | | | | Published |Content brief template
Every piece of content should start with a brief:
## Content brief: [Working Title]
**Author**: [Name]
**Due date**: [Date]
**Target length**: [Word count]
**Content type**: Blog post / Tutorial / Guide / etc.
### Target audience
Who is this for? What do they already know? What problem are they solving?
### Objective
What should the reader know, think, or do after reading?
### Primary keyword
[Main keyword to target]
### Secondary keywords
- [Secondary keyword 1]
- [Secondary keyword 2]
- [Secondary keyword 3]
### Outline
1. [Section 1]
- [Subsection]
- [Subsection]
2. [Section 2]
- [Subsection]
- [Subsection]
3. [Section 3]
### Key points to include
- [Important point]
- [Important point]
- [Important point]
### Internal links
- [Existing content to link to]
- [Existing content to link to]
### Call to action
What should the reader do next?
### References and research
- [Source]
- [Source]Build a developer content strategy for [PRODUCT NAME].
CONTEXT:
- Product: [WHAT IT DOES AND WHO IT'S FOR]
- Target developers: [ROLE, SENIORITY, TECH STACK]
- Current content: [WHAT EXISTS TODAY]
- Primary goal: [AWARENESS / ACTIVATION / RETENTION]
- Resources: [TEAM SIZE, BUDGET]
DELIVER THE FOLLOWING:
1. CONTENT PILLARS (3-5)
For each pillar:
- Theme and why it resonates with audience
- 5-10 specific topic ideas
- Best content formats for this pillar
- Target keywords
2. 12-WEEK EDITORIAL CALENDAR
Weekly content schedule with:
- Title and content type
- Target keyword
- Owner and status
- Distribution channels
3. CONTENT BRIEF TEMPLATE
Filled-in example for your highest priority piece.
4. DISTRIBUTION STRATEGY
For each channel (blog, Dev.to, GitHub, YouTube, Twitter, Reddit):
- Content approach
- Posting frequency
- Engagement tactics
5. SUCCESS METRICS
Traffic, engagement, and conversion metrics with targets.Launch blog post template
Launch posts are critical. They're often the most-read content about a new product or feature. I've written about writing the perfect launch blog post, and here's the structure:
## [Announcing/Introducing] [Product/Feature Name]: [Key Benefit]
[Opening paragraph: One to two sentences capturing what's new and
why it matters. Lead with the value, not the feature.]
### What's new
[Explanation of the new capability in plain language. Avoid jargon.
Focus on what developers can now do that they couldn't before.]
### Why we built this
[Brief context on the problem this solves. What did you hear from
customers? What gap did you see in the market?]
### How it works
[Technical explanation appropriate to your audience. Include code
samples, screenshots, or architecture diagrams as relevant.]
### Get started
[Clear, actionable instructions for trying it out. Link to docs,
quickstart guides, or sign-up pages.]
### What's next
[Brief mention of roadmap items or areas you're continuing to
develop. Invites readers to give feedback.]
---
[Call to action: Sign up, try the feature, read the docs, etc.]Developer segmentation template
Understanding your audience requires concrete segmentation. Personas are too imprecise and subject to misinterpretation. A segmentation-based approach emphasizes specificity and actionable criteria you can use in tools like LinkedIn Sales Navigator. This template complements identifying your ideal customer profile, which goes deeper into the strategic considerations. Here's how I structure developer segments:
## Developer segment: [Name]
### Demographics
**Role**: [Job title]
**Experience**: [Years in role]
**Company size**: [Range]
**Industry**: [Primary industries]
### Technical context
**Primary languages**: [Languages]
**Frameworks**: [Frameworks]
**Cloud/infrastructure**: [Platforms]
**Development methodology**: [Agile, etc.]
### Goals and motivations
- [Primary goal]
- [Secondary goal]
- [What success looks like]
### Pain points
- [Pain point 1]
- [Pain point 2]
- [Pain point 3]
### Evaluation criteria
How do they decide whether to adopt a new tool?
- [Criterion 1]
- [Criterion 2]
- [Criterion 3]
### Information sources
Where do they learn about new tools?
- [Source 1]
- [Source 2]
- [Source 3]
### Objections and concerns
What might prevent them from adopting?
- [Objection 1]
- [Objection 2]
### Quote
[A representative quote that captures their mindset]Competitive analysis template
Understanding your competition is essential for positioning. Here's how to structure competitive intelligence:
## Competitive analysis: [Your Product] vs [Competitor]
### Overview
**Competitor**: [Name]
**Category**: [Product category]
**Target audience**: [Their ICP]
**Positioning**: [Their main message]
### Product comparison
| Capability | [Your Product] | [Competitor] |
|------------|----------------|--------------|
| [Capability 1] | [Your approach] | [Their approach] |
| [Capability 2] | [Your approach] | [Their approach] |
| [Capability 3] | [Your approach] | [Their approach] |
### Strengths (theirs)
- [Strength 1]
- [Strength 2]
### Weaknesses (theirs)
- [Weakness 1]
- [Weakness 2]
### Our advantages
- [Advantage 1]: [How to message it]
- [Advantage 2]: [How to message it]
### Their advantages
- [Advantage 1]: [How to counter or neutralize]
- [Advantage 2]: [How to counter or neutralize]
### Competitive talking points
**When they mention [topic]**: [Your response]
**When they claim [claim]**: [Your counter]
### Migration path
How do customers move from [Competitor] to [Your Product]?
[Description of migration process and support]Create a competitive battlecard comparing [YOUR PRODUCT] vs [COMPETITOR].
CONTEXT:
- Your product: [BRIEF DESCRIPTION]
- Competitor: [BRIEF DESCRIPTION]
- Primary evaluation criteria: [LIST 3-5]
DELIVER THE FOLLOWING:
1. HONEST STRENGTHS ASSESSMENT
Competitor Strengths (be genuine):
- 4-6 real strengths with technical specifics
- Why each matters to developers
Your Strengths:
- 4-6 defensible advantages with proof points
2. HONEST WEAKNESSES ASSESSMENT
Competitor Weaknesses:
- 3-5 genuine limitations
Your Weaknesses (yes, include these):
- 2-4 areas where competitor is stronger
3. WHEN EACH PRODUCT WINS
3-5 scenarios for each with one-sentence summary.
4. OBJECTION HANDLING
Top 5 objections with response framework:
- Acknowledge what's true
- Provide context
- Explain your approach
5. FEATURE COMPARISON TABLE
Cover: Core functionality, DX, performance, pricing, ecosystem.
6. WHEN TO RECOMMEND THE COMPETITOR
3-4 scenarios where you should honestly recommend them.Event brief template
For conferences and events, planning is everything. Before committing resources, read my analysis on whether developer events are worth it. If you decide to attend, you'll also want to master writing an effective keynote and the art of the demo. Here's the brief I use:
## Event brief: [Event Name]
### Event overview
**Event**: [Name]
**Dates**: [Dates]
**Location**: [City/Virtual]
**Expected attendance**: [Number]
**Target audience**: [Description]
### Our objectives
1. [Objective with measurable target]
2. [Objective with measurable target]
3. [Objective with measurable target]
### Presence
**Booth**: [Yes/No, size, location]
**Speaking**: [Session titles, speakers]
**Sponsorship level**: [Tier]
### Staffing
| Name | Role | Dates on-site |
|------|------|---------------|
| | | |
### Messaging
**Key theme**: [Theme for our presence]
**Demo focus**: [What we're showing]
**CTA**: [What we want attendees to do]
### Materials needed
- [ ] Booth materials (banners, swag, etc.)
- [ ] Demo environment
- [ ] Presentation slides
- [ ] One-pagers/handouts
- [ ] Lead capture system
### Pre-event marketing
- [ ] Email to customers/prospects in region
- [ ] Social media promotion
- [ ] Meeting scheduler
### Post-event follow-up
- [ ] Lead follow-up process
- [ ] Content from sessions
- [ ] Internal debrief
### Budget
| Item | Estimate | Actual |
|------|----------|--------|
| Sponsorship | | |
| Travel | | |
| Booth | | |
| Swag | | |
| **Total** | | |Case study framework
Case studies are among the most valuable content types for developer products. I've written a full guide on how to write a great developer case study. Here's the structure:
## Case study: [Customer Name]
### Key results
- [Result 1 with specific metric]
- [Result 2 with specific metric]
- [Result 3 with specific metric]
### Customer overview
**Company**: [Name]
**Industry**: [Industry]
**Size**: [Employees/revenue]
**Use case**: [How they use your product]
### Challenge
[Two to three paragraphs on the problem they faced before using
your product. Be specific about pain points and business impact.]
### Solution
[Two to three paragraphs on how they implemented your product.
Include technical details appropriate to your audience.]
### Results
[Detailed description of outcomes with specific metrics. Quantify
wherever possible: percentage improvements, time saved, etc.]
### Customer quote
"[Direct quote from customer about their experience]"
- [Name], [Title], [Company]
### What's next
[Brief mention of how they plan to expand usage or future plans.]Using these frameworks
Frameworks are starting points, not straitjackets. Adapt them to your specific context, product, and audience. The goal is to save time and ensure consistency, not to limit creativity. For additional context, see my guides on building a sales enablement strategy and choosing what content to build.
If you want to go deeper on any of these topics, I cover them all extensively in Picks and Shovels: Marketing to Developers During the AI Gold Rush. The book includes additional templates, real-world examples, and the thinking behind each framework.
And if you have frameworks you've found useful, I'd love to hear about them. Reach out on Twitter and let's compare notes.
Developer marketing expert with 30+ years of experience at Sun Microsystems, Microsoft, AWS, Meta, Twitter, and Supabase. Author of Picks and Shovels, the Amazon #1 bestseller on developer marketing.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.
Don't get left behind by AI
Sign up for the Strategic Nerds Newsletter and get expert advice on Developer Marketing and Developer Relations so you can navigate technical marketing in the AI era.