You want developers advocating for your product. Creating content, answering questions, recommending you to peers. Most developer advocate programs fail because they feel transactional or inauthentic.
Real advocacy happens when developers genuinely love your product and want to help others succeed with it. Here's how to enable that.
What Developer Advocacy Actually Is
Not:
- Paying influencers to tweet about your product
- Requiring advocates to post X times per month
- Giving people a title and expecting them to shill
Is:
- Empowering developers who already love your product
- Providing resources to help them help others
- Recognizing their contributions authentically
- Building relationships, not transactions
The Three Types of Developer Advocates
1. Internal advocates (employees)
Developer relations team members employed to create content, speak at events, engage with community.
Example: Cassidy Williams at Netlify, Lee Robinson at Vercel.
Role: Full-time advocate, bridge between community and company.
2. External champions (volunteer advocates)
Developers who use your product, create content, and help others without being employees.
Example: GitHub Stars program, Auth0 Ambassadors.
Role: Community members who advocate voluntarily, often recognized through formal programs.
3. Organic advocates (happy customers)
Developers who recommend your product because it solved their problem. No formal relationship.
Example: Every developer who recommends Vercel or Supabase to a colleague.
Role: Word-of-mouth at scale. Most authentic but hardest to coordinate.
When to Build an Advocate Program
Don't build if:
- You have fewer than 500 active developers using your product
- Your product NPS is below 30 (fix product first)
- You can't commit someone to manage the program
- You're doing this purely for "content distribution"
Do build if:
- Developers are already creating content about your product
- You have engaged community members helping others
- Developers ask how they can contribute or get more involved
- You want to scale education and support beyond your team
Advocacy programs amplify existing love. They don't create it.
Building an External Champion Program
Step 1: Identify potential champions
Look for developers who:
- Answer questions in your community
- Create tutorials or blog posts about your product
- Give conference talks mentioning your product
- Contribute to documentation or open source
- Are genuinely helpful and kind
Don't recruit based on:
- Follower count alone
- Willingness to post promotional content
- Quid pro quo ("I'll advocate if you pay me")
Step 2: Define champion benefits
What champions actually value:
Early access: Beta features, preview releases, input on roadmap.
Example: Auth0 Ambassadors get early access to features and direct input with product team.
Direct access to team: Monthly calls with engineers, dedicated Slack channel, inside track on product decisions.
Recognition: Profile on website, badge in community, featured in newsletter, resume material.
Learning and growth: Training, certifications, speaking opportunities, introductions to other companies.
Swag and perks: Conference tickets, branded swag, credits, but these are secondary to access and recognition.
What doesn't work:
- Purely transactional rewards ("$50 per blog post")
- Generic swag without other benefits
- Recognition without substance
Step 3: Set clear expectations (without being prescriptive)
Good framework:
Expectations:
- Create at least one piece of content per quarter (blog, video, talk)
- Participate in monthly champion calls
- Help others in community when you can
- Provide product feedback
- Follow code of conduct
Not required:
- Promoting product features you don't use
- Creating content on specific topics
- Hitting engagement metrics
- Posting on schedule
Example: Cloudinary Developer Experts - clear expectations about engagement, but flexibility in how they contribute.
Step 4: Application and selection process
Application should ask:
- How do you use our product?
- What have you created or shared about it?
- How do you want to help the community?
- What do you want to learn or achieve?
Don't ask:
- How many followers do you have?
- How many posts will you create?
Selection criteria:
- Product expertise
- Quality of existing content or contributions
- Community helpfulness
- Alignment with values
Running the Program
Monthly champion calls:
Format:
- Product updates and roadmap preview (15 min)
- Champion showcase - someone presents what they built (15 min)
- Open discussion and Q&A (20 min)
- Social time (10 min)
Goal: Make champions feel like insiders with direct connection to team.
Private community channel:
Dedicated Slack/Discord channel where champions can:
- Ask questions directly to team
- Share what they're building
- Collaborate with each other
- Get early announcements
Recognition program:
Spotlight champions:
- Feature their content in newsletter
- Share their posts on company social
- Highlight them in community
- Include them in customer stories
Avoid: Making it feel like you're using them for distribution. Recognize genuine contributions.
Support their content creation:
Provide:
- Beta access for tutorials
- Technical review of content
- Promotion of their content
- Resources (graphics, examples, credits)
Don't:
- Require approval of content
- Force them to use marketing speak
- Demand exclusivity
Measuring Program Success
Vanity metrics (don't optimize for these alone):
- Number of advocates
- Number of posts created
- Social reach/impressions
Meaningful metrics:
Product adoption: How many developers did advocates help adopt your product?
- Track referral signups
- Survey new users about discovery source
Community impact: Are advocates making your community better?
- Questions answered by advocates
- Content created that fills gaps
- New community members they welcome
Advocate retention: Do advocates stay active over time?
- Active advocates after 6 months, 12 months
- Participation in calls and activities
Advocate satisfaction: Are advocates getting value?
- Regular surveys about program benefits
- Renewal rate if program has terms
Product improvement: Is advocate feedback improving product?
- Feature requests from advocates implemented
- Bugs reported and fixed
Common Program Failures
Failure 1: Treating advocates as content distributors
Looks like: "Can you post about our new feature?" "We need 3 tweets this week." "Here's content to share."
Why it fails: Developers see through inauthentic promotion. Advocates feel used.
Instead: Let advocates create content about what they're genuinely excited about. Provide resources, don't assign content.
Failure 2: No benefits beyond swag
Looks like: "Join our program and get a t-shirt!" No early access, no direct team connection, no real recognition.
Why it fails: T-shirts don't motivate sustained engagement.
Instead: Provide access, influence, and learning opportunities that help advocates professionally.
Failure 3: Too many requirements
Looks like: Must create 2 posts per month, speak at 1 event per quarter, answer 10 questions per week.
Why it fails: Advocacy becomes a job, not a choice. Burns out genuine enthusiasts.
Instead: Set minimum bar for participation, celebrate those who go above and beyond.
Failure 4: Ignoring advocate feedback
Looks like: Advocates report bugs and frustrations. Nothing changes. Feedback goes into void.
Why it fails: Advocates feel their voice doesn't matter. Why stay engaged?
Instead: Create clear path from advocate feedback to product team. Share what changed based on their input.
Examples of Great Advocate Programs
GitHub Stars:
What they do well:
- Highly selective (real GitHub community leaders)
- Direct access to GitHub team and product previews
- Spotlight in official GitHub communications
- Annual summit bringing Stars together
- No posting requirements
Auth0 Ambassadors:
What they do well:
- Clear application and selection process
- Quarterly goals (flexible, not rigid)
- Direct access to product and engineering teams
- Recognition in community and marketing
- Training and certification opportunities
Cloudflare Developers:
What they do well:
- Focus on builders creating on Cloudflare Workers
- Highlight community projects
- Provide resources and promotion
- No transactional "post X times" requirements
Starting Your Program
Month 1: Identify and recruit
- Identify 10-15 developers already creating content or helping community
- Personally invite them (not mass invitation)
- Explain program benefits and expectations
- Get commitments
Month 2: Launch
- First champion call - set tone of collaboration
- Create private community channel
- Share roadmap preview or early access
- Ask: What would make this program valuable for you?
Month 3-6: Establish rhythm
- Monthly calls
- Regular recognition of contributions
- Support champion content creation
- Gather feedback and iterate
Month 6: Evaluate
- Are champions engaged?
- Is program delivering value to them and you?
- What's working? What's not?
- Adjust based on feedback
The Organic Advocacy Strategy
Beyond formal programs:
The best advocacy is organic - developers recommending your product because it's genuinely great.
Enable organic advocacy by:
Making sharing easy:
- Great documentation developers can link to
- Clear explanations they can forward to colleagues
- Code examples they can share
Celebrating user projects:
- Highlight what developers build with your product
- Share customer stories
- Feature community projects
Being genuinely helpful:
- Fast support responses
- Active presence in community
- Transparent about roadmap and issues
Having strong opinions:
- Point of view on how to solve problems
- Technical blog posts that teach
- Open source contributions to ecosystem
Companies that generate organic advocacy:
Vercel, Supabase, Railway - developers recommend them constantly not because of formal programs, but because the product is excellent and the team is genuinely helpful.
The Authenticity Test
Before launching or scaling advocate program, ask:
Would advocates still create content if program ended?
If yes: Program is amplifying genuine enthusiasm.
If no: Program is transactional. Rethink approach.
Real advocacy comes from product love, community connection, and authentic relationships. Programs should enable and recognize that - not manufacture it.
Build a product developers love first. Then empower those who want to help others love it too.