653 lines
17 KiB
Markdown
653 lines
17 KiB
Markdown
---
|
|
name: developer-churn
|
|
description: When the user wants to understand, reduce, or recover from developer churn. Trigger phrases include "why developers leave," "churn rate," "win-back campaign," "at-risk users," "developer retention," "preventing churn," or "competitor switching."
|
|
risk: unknown
|
|
source: https://github.com/jonathimer/devmarketing-skills/tree/main/skills/developer-churn
|
|
source_repo: jonathimer/devmarketing-skills
|
|
source_type: community
|
|
date_added: 2026-07-01
|
|
license: MIT
|
|
license_source: https://github.com/jonathimer/devmarketing-skills/blob/main/LICENSE
|
|
---
|
|
|
|
# Developer Churn
|
|
## When to Use
|
|
|
|
Use this skill when you need when the user wants to understand, reduce, or recover from developer churn. Trigger phrases include "why developers leave," "churn rate," "win-back campaign," "at-risk users," "developer retention," "preventing churn," or "competitor switching.".
|
|
|
|
|
|
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**:
|
|
```
|
|
- Sudden usage reduction after billing cycle
|
|
- Pricing page visits from logged-in users
|
|
- Support tickets about unexpected charges
|
|
- API calls stopping mid-month
|
|
```
|
|
|
|
### 3. Superior Alternatives
|
|
|
|
**Symptoms**:
|
|
- Sudden churn (not gradual)
|
|
- Multiple team members churning together
|
|
- Churning without complaints
|
|
- "We're going a different direction"
|
|
|
|
**Root causes**:
|
|
- Competitor launched better feature
|
|
- Open source alternative matured
|
|
- Bigger player entered your space
|
|
- Their stack changed (new language/framework)
|
|
|
|
**Detection signals**:
|
|
```
|
|
- Sudden stop in usage (no gradual decline)
|
|
- Competitor mentions in support/feedback
|
|
- Traffic to your docs from competitor domains
|
|
- Social mentions comparing you to alternatives
|
|
```
|
|
|
|
### 4. Project Death
|
|
|
|
**Symptoms**:
|
|
- Gradual decline to zero
|
|
- No support contact
|
|
- Ignores all communication
|
|
- Whole company churn
|
|
|
|
**Root causes**:
|
|
- Their project was cancelled
|
|
- Startup failed
|
|
- Prototype never went to production
|
|
- Budget cuts
|
|
|
|
**Reality check**: You can't prevent this. Don't waste energy trying.
|
|
|
|
**Detection signals**:
|
|
```
|
|
- Slow decline over weeks/months
|
|
- No login activity
|
|
- No response to any outreach
|
|
- Domain no longer resolves
|
|
```
|
|
|
|
### 5. Integration Failure
|
|
|
|
**Symptoms**:
|
|
- High engagement then sudden stop
|
|
- Technical support tickets unresolved
|
|
- "Doesn't work with X" feedback
|
|
- Stuck at implementation phase
|
|
|
|
**Root causes**:
|
|
- Your product doesn't fit their stack
|
|
- Missing integration they need
|
|
- Technical limitation they hit
|
|
- SDK doesn't support their use case
|
|
|
|
**Detection signals**:
|
|
```
|
|
- Lots of docs page views on specific integration
|
|
- Support tickets about specific tech stack
|
|
- API calls from testing environment only
|
|
- "Evaluation" mentioned in communications
|
|
```
|
|
|
|
### 6. Involuntary Churn
|
|
|
|
**Symptoms**:
|
|
- Churn after failed payment
|
|
- No other warning signs
|
|
- Often surprised when contacted
|
|
|
|
**Root causes**:
|
|
- Expired credit card
|
|
- Card fraud protection
|
|
- Changed payment method
|
|
- Forgot to update billing
|
|
|
|
**Detection signals**:
|
|
```
|
|
- Failed payment events
|
|
- Usage continues until hard cutoff
|
|
- Quick reactivation when contacted
|
|
```
|
|
|
|
---
|
|
|
|
## Identifying At-Risk Developers
|
|
|
|
### Engagement Scoring
|
|
|
|
Create a simple health score:
|
|
|
|
| Signal | Weight | Calculation |
|
|
|--------|--------|-------------|
|
|
| API calls | 30% | This week vs last 4 week avg |
|
|
| Login frequency | 20% | Days since last login |
|
|
| Feature adoption | 20% | % of core features used |
|
|
| Support sentiment | 15% | Positive/negative ticket ratio |
|
|
| Billing health | 15% | Payment success, plan changes |
|
|
|
|
**Health score thresholds**:
|
|
- **80-100**: Healthy - continue nurturing
|
|
- **60-79**: Watch - proactive outreach
|
|
- **40-59**: At-risk - intervention needed
|
|
- **0-39**: Critical - personal contact
|
|
|
|
### Early Warning Signs
|
|
|
|
Monitor for these patterns:
|
|
|
|
**Usage-based signals**:
|
|
```
|
|
- API calls dropped >50% week-over-week
|
|
- No login in 14+ days
|
|
- Stopped using new features
|
|
- API errors increasing
|
|
- Only using deprecated endpoints
|
|
```
|
|
|
|
**Support-based signals**:
|
|
```
|
|
- Multiple tickets on same issue
|
|
- Negative sentiment in tickets
|
|
- Questions about data export
|
|
- Asking about contract/cancellation
|
|
- Unusual silence from previously engaged user
|
|
```
|
|
|
|
**Billing-based signals**:
|
|
```
|
|
- Viewing pricing page while logged in
|
|
- Downgrading plan
|
|
- Removing team members
|
|
- Asking about prorating cancellation
|
|
```
|
|
|
|
### Building an Alert System
|
|
|
|
Set up automated alerts:
|
|
|
|
```
|
|
ALERT: At-risk developer detected
|
|
|
|
User: [EMAIL/COMPANY]
|
|
Health score: 42 (was 78 last week)
|
|
|
|
Triggers:
|
|
- API calls down 73% this week
|
|
- 2 unresolved support tickets (both negative sentiment)
|
|
- Viewed pricing page 3 times
|
|
|
|
Recommended action: Personal outreach from [OWNER]
|
|
```
|
|
|
|
---
|
|
|
|
## Churn Interviews and Feedback
|
|
|
|
### The Right Approach
|
|
|
|
**Do**:
|
|
- Ask genuinely curious questions
|
|
- Accept their decision gracefully
|
|
- Make it about learning, not winning them back
|
|
- Keep it short (5 questions max)
|
|
- Offer something valuable for their time
|
|
|
|
**Don't**:
|
|
- Try to sell during the interview
|
|
- Get defensive about feedback
|
|
- Promise things to change their mind
|
|
- Make them feel guilty
|
|
- Take longer than 10 minutes
|
|
|
|
### Exit Survey (Email)
|
|
|
|
```
|
|
Subject: Quick question about your [PRODUCT] experience
|
|
|
|
Hey [NAME],
|
|
|
|
I noticed you've stopped using [PRODUCT]. No worries — these things happen.
|
|
|
|
If you have 30 seconds, I'd genuinely love to know:
|
|
|
|
What's the #1 reason you stopped?
|
|
|
|
[ ] Found a better alternative
|
|
[ ] Too expensive
|
|
[ ] Too complicated to use
|
|
[ ] Missing feature I needed
|
|
[ ] Project ended / no longer needed
|
|
[ ] Other: _____
|
|
|
|
Your feedback directly shapes our roadmap.
|
|
|
|
Thanks for giving us a try.
|
|
|
|
— [NAME], [TITLE] at [COMPANY]
|
|
```
|
|
|
|
### Exit Interview Questions
|
|
|
|
If they agree to a call (offer a $50 gift card or donation to their choice):
|
|
|
|
1. **Opening**: "Thanks for chatting. I'm not here to win you back — just want to understand your experience."
|
|
|
|
2. **Journey**: "Walk me through your experience with [PRODUCT], from signup to today."
|
|
|
|
3. **Breaking point**: "Was there a specific moment when you decided to stop using us?"
|
|
|
|
4. **Alternative**: "What are you using now instead? What made that a better fit?"
|
|
|
|
5. **Hypothetical**: "If you could wave a magic wand and change one thing about [PRODUCT], what would it be?"
|
|
|
|
6. **Close**: "Anything else you want us to know?"
|
|
|
|
### Analyzing Feedback
|
|
|
|
Track churn reasons by category:
|
|
|
|
| Category | % of Churn | Actionable? | Priority |
|
|
|----------|------------|-------------|----------|
|
|
| DX issues | 35% | Yes | High |
|
|
| Pricing | 25% | Yes | Medium |
|
|
| Alternatives | 20% | Partially | Medium |
|
|
| Project death | 15% | No | None |
|
|
| Integration gaps | 5% | Yes | Low |
|
|
|
|
Focus energy on actionable categories with high impact.
|
|
|
|
---
|
|
|
|
## Win-Back Campaigns
|
|
|
|
### When to Win Back
|
|
|
|
**Good candidates**:
|
|
- Churned due to fixable issues (you've since fixed)
|
|
- Left for alternative that's now inferior
|
|
- Project death but new project starting
|
|
- Billing/involuntary churn
|
|
|
|
**Bad candidates**:
|
|
- Left with strong negative sentiment
|
|
- Fundamental product mismatch
|
|
- Company no longer exists
|
|
- Recently churned (wait at least 30 days)
|
|
|
|
### Win-Back Sequence
|
|
|
|
**Timing**: Start 30-60 days after churn. Not sooner.
|
|
|
|
**Email 1: What's new (Day 30)**
|
|
|
|
```
|
|
Subject: [PRODUCT] update: [SPECIFIC THING THEY CARED ABOUT]
|
|
|
|
Hey [NAME],
|
|
|
|
I know you moved on from [PRODUCT] a while back. Totally respect that.
|
|
|
|
Quick update: We [SPECIFIC IMPROVEMENT RELEVANT TO THEIR CHURN REASON].
|
|
|
|
[1-2 sentence details with link to changelog/announcement]
|
|
|
|
If your situation has changed, we'd be happy to have you back.
|
|
If not, no worries — hope you're building great things.
|
|
|
|
— [NAME]
|
|
```
|
|
|
|
**Email 2: Social proof (Day 45)**
|
|
|
|
```
|
|
Subject: How [COMPANY SIMILAR TO THEIRS] uses [PRODUCT] now
|
|
|
|
Hey [NAME],
|
|
|
|
Thought you might find this interesting — [SIMILAR COMPANY]
|
|
just shared how they're using [PRODUCT] to [RELEVANT USE CASE].
|
|
|
|
[Link to case study or technical post]
|
|
|
|
Might spark some ideas for your current project.
|
|
|
|
— [NAME]
|
|
```
|
|
|
|
**Email 3: Direct offer (Day 60)**
|
|
|
|
```
|
|
Subject: Would 30 days free help?
|
|
|
|
Hey [NAME],
|
|
|
|
Last note from me.
|
|
|
|
If you've been thinking about giving [PRODUCT] another shot,
|
|
I can set you up with 30 days free on whatever plan you need.
|
|
|
|
Just reply and I'll make it happen.
|
|
|
|
If not, I'll stop emailing. Thanks for reading this far.
|
|
|
|
— [NAME]
|
|
```
|
|
|
|
### Win-Back Offers
|
|
|
|
Appropriate offers for developers:
|
|
|
|
| Offer | When to Use |
|
|
|-------|-------------|
|
|
| Extended free tier | Price-sensitive churners |
|
|
| Free upgrade for 30 days | Feature-gap churners |
|
|
| 1:1 technical help | DX-issue churners |
|
|
| Early access to new feature | Competitor-switch churners |
|
|
| Nothing (just information) | Project-death churners |
|
|
|
|
**What NOT to offer**:
|
|
- Permanent discounts (sets bad precedent)
|
|
- Desperate "please come back" messaging
|
|
- Anything to project-death churners
|
|
|
|
---
|
|
|
|
## Monitoring Competitor Switches
|
|
|
|
### Social Listening Setup
|
|
|
|
Set up monitoring for:
|
|
|
|
1. **Direct mentions**:
|
|
- "[Your product] vs [Competitor]"
|
|
- "Switching from [Your product] to [Competitor]"
|
|
- "Migrating away from [Your product]"
|
|
|
|
2. **Problem space discussions**:
|
|
- Monitor conversations in your category
|
|
- See what alternatives people recommend
|
|
- Track sentiment about your product vs others
|
|
|
|
3. **Competitor momentum**:
|
|
- Track competitor mentions and sentiment
|
|
- New features they're launching
|
|
- Developer reactions to their updates
|
|
|
|
### Competitive Intelligence Workflow
|
|
|
|
```
|
|
Weekly review:
|
|
|
|
1. Check social listening tools for:
|
|
- Any mentions of switching from you
|
|
- Competitor launches or announcements
|
|
- Developer complaints about your category
|
|
|
|
2. Analyze patterns:
|
|
- Are switches going to one competitor?
|
|
- What features/issues drive switches?
|
|
- What's competitor doing that resonates?
|
|
|
|
3. Update churn prevention:
|
|
- Add new at-risk signals
|
|
- Prioritize features that prevent switches
|
|
- Address common complaints
|
|
```
|
|
|
|
---
|
|
|
|
## Reducing Involuntary Churn
|
|
|
|
Involuntary churn (payment failures) is often 20-40% of total churn. Fix it.
|
|
|
|
### Prevention
|
|
|
|
| Strategy | Implementation |
|
|
|----------|----------------|
|
|
| Card expiration warnings | Email 30 and 7 days before |
|
|
| Multiple payment methods | Allow card + PayPal + ACH |
|
|
| Annual billing incentives | 2 months free for annual |
|
|
| Dunning emails | 3-4 emails over 14 days |
|
|
| Grace period | 7-14 days before hard cutoff |
|
|
| In-app warnings | Banner when payment method needs update |
|
|
|
|
### Dunning Sequence
|
|
|
|
**Email 1: Immediate**
|
|
|
|
```
|
|
Subject: Payment failed — update your card
|
|
|
|
Hey [NAME],
|
|
|
|
We couldn't process your payment for [PRODUCT].
|
|
|
|
Update your card: [LINK]
|
|
|
|
Your account is still active. We'll retry in 3 days.
|
|
|
|
— [PRODUCT]
|
|
```
|
|
|
|
**Email 2: Day 3**
|
|
|
|
```
|
|
Subject: Second attempt failed — action needed
|
|
|
|
Hey [NAME],
|
|
|
|
Still can't process your payment. Your service will be
|
|
interrupted on [DATE] if we can't charge a valid card.
|
|
|
|
Update now: [LINK]
|
|
|
|
Having trouble? Reply and we'll help.
|
|
|
|
— [PRODUCT]
|
|
```
|
|
|
|
**Email 3: Day 7**
|
|
|
|
```
|
|
Subject: Your [PRODUCT] account will be paused in 3 days
|
|
|
|
Hey [NAME],
|
|
|
|
Final notice: Your account will be paused on [DATE].
|
|
|
|
This means:
|
|
- API keys will stop working
|
|
- Webhooks will be disabled
|
|
- Your data stays safe (we keep it for 90 days)
|
|
|
|
Update your payment: [LINK]
|
|
|
|
— [PRODUCT]
|
|
```
|
|
|
|
**Email 4: Day 10**
|
|
|
|
```
|
|
Subject: Your account has been paused
|
|
|
|
Hey [NAME],
|
|
|
|
Your [PRODUCT] account is now paused due to payment failure.
|
|
|
|
To reactivate:
|
|
1. Update your payment method: [LINK]
|
|
2. Your service will resume immediately
|
|
|
|
Your data is safe and will be kept for 90 days.
|
|
|
|
Questions? Reply to this email.
|
|
|
|
— [PRODUCT]
|
|
```
|
|
|
|
### Recovery Tactics
|
|
|
|
| Tactic | Impact |
|
|
|--------|--------|
|
|
| Smart retries | Retry 3-5 times over 2 weeks at different times |
|
|
| Card updater services | Automatically update expired cards |
|
|
| Alternative payment request | "Try a different card?" |
|
|
| Payment link in dunning | Direct link, not "log in to update" |
|
|
| Phone/SMS for enterprise | High-value accounts get personal contact |
|
|
|
|
---
|
|
|
|
## Churn Metrics Dashboard
|
|
|
|
### Key Metrics
|
|
|
|
| Metric | How to Calculate | Target |
|
|
|--------|------------------|--------|
|
|
| Monthly churn rate | Churned users / Starting users | <5% |
|
|
| Net revenue churn | Lost revenue - expansion / Starting MRR | <2% |
|
|
| Time to churn | Avg days from signup to churn | Increasing |
|
|
| Win-back rate | Returned users / Churned users | >5% |
|
|
| Involuntary churn % | Payment churn / Total churn | <20% |
|
|
|
|
### Cohort Analysis
|
|
|
|
Track retention by:
|
|
- **Signup month**: Are recent cohorts retaining better?
|
|
- **Acquisition source**: Which channels produce sticky users?
|
|
- **Plan type**: Do paid users retain better than free?
|
|
- **Activation status**: Do activated users retain better?
|
|
|
|
### Health Score Tracking
|
|
|
|
```
|
|
Weekly health score distribution:
|
|
|
|
Healthy (80-100): 65% of users
|
|
Watch (60-79): 20% of users
|
|
At-risk (40-59): 10% of users
|
|
Critical (0-39): 5% of users
|
|
|
|
Trend: At-risk increased 3% this week (investigate)
|
|
```
|
|
|
|
---
|
|
|
|
## Common Mistakes
|
|
|
|
| Mistake | Why It Fails | Fix |
|
|
|---------|--------------|-----|
|
|
| Ignoring project death | Wasting resources on unwinnable users | Accept it and focus on actionable churn |
|
|
| Offering discounts first | Trains users to threaten churn for discounts | Lead with value, not price |
|
|
| Win-back too soon | Feels desperate, annoys recently churned | Wait 30+ days |
|
|
| Not listening to feedback | Repeating the same mistakes | Actually fix what they complained about |
|
|
| Generic win-back campaigns | Irrelevant messages get ignored | Personalize based on churn reason |
|
|
| Blaming developers | "They just didn't get it" | Your DX is the problem |
|
|
|
|
---
|
|
|
|
## Tools
|
|
|
|
| Tool | Use Case |
|
|
|------|----------|
|
|
| **[Octolens](https://octolens.com)** | Monitor competitor switches, track developer sentiment, detect early warning signs from social mentions |
|
|
| **Segment** | Track usage events for health scoring |
|
|
| **Amplitude/Mixpanel** | Cohort analysis and retention tracking |
|
|
| **Customer.io** | Automated at-risk and win-back sequences |
|
|
| **Stripe** | Dunning management for involuntary churn |
|
|
| **Profitwell Retain** | Specialized churn reduction for payments |
|
|
|
|
---
|
|
|
|
## Related Skills
|
|
|
|
- `developer-audience-context` — Understand alternatives and pain points
|
|
- `developer-email-sequences` — Re-engagement and win-back emails
|
|
- `competitor-tracking` — Monitor competitive landscape
|
|
- `developer-listening` — Capture feedback before churn
|
|
- `developer-onboarding` — Prevent churn at the source
|
|
|
|
## Limitations
|
|
|
|
- Use this skill only when the task clearly matches its upstream source and local project context.
|
|
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
|
|
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
|