# Developer churn Human Guide

## What This Is For
This skill helps you understand why developers leave, identify at-risk users before they churn, and win back those who've already left. It gives the agent a clearer input/output frame for go-to-market work: what context to ask for, what decisions to make, and what usable artifact to return.

Use this as a human-readable version of the Developer churn agent skill. It is meant for marketers, operators, founders, and other non-coders who want the workflow without reading agent-specific implementation instructions.

## When To Use This
- Use this when you need a repeatable process for developer churn.
- Use this when the task needs judgment, examples, constraints, or a clear output format rather than a one-off prompt.
- Use this when you want to hand an AI assistant enough context to produce a usable marketing artifact.

## When Not To Use This
- Do not use this when you only need a quick factual answer.
- Do not use this when the work depends on private data you cannot share with the assistant.
- Do not use this as a replacement for legal, compliance, financial, or medical review.

## What You Need Before Starting
- The goal or business outcome you want.
- The audience, customer segment, or market context.
- Any source material the assistant should respect, such as notes, briefs, examples, URLs, or brand guidance.
- Constraints such as tone, length, channel, deadline, region, or approval requirements.
- A clear definition of what a good final answer should look like.

## Step-By-Step Workflow
1. State the job clearly: "Use the Developer churn guide to help me with..."
2. Add context: audience, goal, offer, channel, source material, and constraints.
3. Ask the assistant to identify missing inputs before producing the final output.
4. Have the assistant follow the skill-specific guidance below.
5. Review the result against the final checklist and ask for revisions where needed.

## Skill-Specific Guidance
- **Load your developer audience context**:
- Check if `.agents/developer-audience-context.md` exists
- If not, run the `developer-audience-context` skill first
- Understanding your developers' alternatives and pain points is critical for churn analysis
- Current churn rate by segment
- Most recent churned users (last 30-90 days)
- Support ticket history for churned users
- Frequent support tickets on basic tasks
- Complaints about docs or SDKs
- "It's too complicated" feedback
- Breaking changes without migration paths
- Downgrades before cancellation

## Decision Points And Nuance
The original skill emphasizes: Before You Start, Understanding Developer Churn, The 6 Reasons Developers Churn, Developer Experience (DX) Issues, Pricing and Billing Friction, Superior Alternatives, Project Death, Integration Failure, Involuntary Churn, Identifying At-Risk Developers.

Use these questions to steer the work:
- What is the intended audience or buyer?
- What source material must be preserved?
- What should the assistant optimize for: clarity, persuasion, accuracy, speed, creativity, or conversion?
- What examples represent the desired quality bar?
- What should the assistant avoid?

## Common Mistakes
- **Key insight**: Developers don't leave because of price. They leave because of friction, frustration, or finding something better.
- Prototype never went to production
- **Reality check**: You can't prevent this. Don't waste energy trying.
- | Card expiration warnings | Email 30 and 7 days before |
- | In-app warnings | Banner when payment method needs update |
- | **[Octolens](https://octolens.com)** | Monitor competitor switches, track developer sentiment, detect early warning signs from social mentions |
- Helps you understand the real reasons developers churn, build early warning systems to identify at-risk users, conduct effective exit interviews, and run win-back campaigns that respect developer intelligence.
- Developers don't leave because of price — they leave because of friction

## Copy-And-Paste Prompt
```text
Use the Developer churn human guide.

My goal:
[Describe the business outcome]

Audience:
[Describe who this is for]

Context and source material:
[Paste notes, examples, links, or existing copy]

Constraints:
[Tone, length, channel, timeline, must-include items, must-avoid items]

Before producing the final output, ask me for any missing information that would materially improve the result.
```

## Final Checklist
- [ ] The output matches the original goal.
- [ ] The audience and context are reflected in the answer.
- [ ] Important constraints and source material were preserved.
- [ ] The assistant made the relevant decisions explicit.
- [ ] The final artifact is ready to use, review, or hand to the next person.

## Source
This guide was generated from the jonathimer/devmarketing-skills skill entry for `developer-churn`.

## Source Skill Notes
These notes preserve the nuance from the original skill. Use them as supporting reference when the workflow above feels too generic.

# Developer Churn

This skill helps you understand why developers leave, identify at-risk users before they churn, and win back those who've already left. No guilt trips or desperate discounts — just honest understanding and genuine value.

---

## Before You Start

1. **Load your developer audience context**:
   - Check if `.agents/developer-audience-context.md` exists
   - If not, run the `developer-audience-context` skill first
   - Understanding your developers' alternatives and pain points is critical for churn analysis

2. **Gather your data**:
   - Current churn rate by segment
   - Most recent churned users (last 30-90 days)
   - Support ticket history for churned users
   - Usage patterns before churn
   - Exit survey data (if any)

---

## Understanding Developer Churn

Developer churn is different from typical SaaS churn:

| Consumer/SMB SaaS | Developer Tools |
|-------------------|-----------------|
| Price sensitivity high | Value sensitivity high |
| Features drive decisions | DX drives decisions |
| Support tickets = engagement | Support tickets = friction |
| Monthly churn cycles | Project-based churn |
| Competitor marketing works | Peer recommendations work |

**Key insight**: Developers don't leave because of price. They leave because of friction, frustration, or finding something better.

---

## The 6 Reasons Developers Churn

### 1. Developer Experience (DX) Issues

**Symptoms**:
- High time-to-first-value
- Frequent support tickets on basic tasks
- Complaints about docs or SDKs
- "It's too complicated" feedback

**Root causes**:
- Poor documentation
- Buggy SDKs
- Breaking changes without migration paths
- Confusing authentication
- Missing quickstarts

**Detection signals**:
```
- Support tickets mentioning "confused" or "doesn't work"
- High signup-to-activation drop-off
- Long time between signup and first API call
- Multiple failed API calls before success
```

### 2. Pricing and Billing Friction

**Symptoms**:
- Downgrades before cancellation
- Usage dropping to stay under limits
- Questions about billing
- Requests for enterprise/custom pricing

**Root causes**:
- Unpredictable costs
- Expensive for early-stage
- No free tier or too restrictive
- Poor price-to-value perception
- Billing surprises

**Detection signals**:
```