community_champions v1.0.0

name: "community_champions" description: "Design and run a community champion program: identify power users, recruit them, give early access and recognition perks, and run the inner-circle cadence that keeps them active. Use when asked to build a champion, advocate, ambassador, or superuser program for a product or community."

Community Champions

Purpose

Turn power users into champions who recruit, teach, and defend the product. Champions are the people already doing the work for free: answering questions, filing good bug reports, making tutorials. This skill finds them, gives them reasons to keep going, and runs the program without burning them out.

Workflow

1. Define the job before naming anyone

Write the charter first, in one paragraph: what champions do (answer questions, beta test, create content, refer users), what they get (see perks below), and what success looks like in 6 months (e.g. 30% of forum questions answered by champions, not staff). Get leadership sign-off on the charter before recruiting. Programs die from vague expectations, not from too few perks.

2. Identify candidates with behavior signals, not vanity metrics

Repo count, follower count, and tenure are weak signals. Strong signals, in order:

• Helps others unprompted (answers in forums, Discord, Stack Overflow, issue trackers)
• Creates useful artifacts (tutorials, templates, code samples, walkthroughs)
• Files quality feedback (reproducible bugs, thoughtful feature requests)
• Shows product depth (advanced usage, edge-case knowledge)
• Consistent over months, not a one-week burst
• Positive, inclusive tone (check how they treat beginners)

Where to look: community forums, Discord/Slack, GitHub issue trackers, social mentions, support ticket threads where the user solved their own problem. Pick 5 to 15 for the founding cohort. Small and real beats big and decorative.

3. Recruit personally, never by blast

Send a direct, personal invite to each candidate naming what they specifically did ("your Redis caching guide fixed three threads last month"). The invite states the role, the time ask (be honest: typically 2-4 hours a month), the perks, and that they can leave anytime. Track: invitations sent, acceptance rate. Expect roughly half of personal invites to convert; mass emails convert near zero.

4. Onboard with one kickoff, not a course

One call or async thread covering: the charter, where champions hang out (private channel), how to reach the team directly, and the first small task so they act fast (e.g. review the beta, answer the pinned AMA). Give them an onboarding one-pager and a direct contact. Long training tracks kill enthusiasm before it starts.

5. Run the inner-circle cadence

This is the part most programs skip and the part that actually retains people:

• Private channel with real staff presence. Answer their questions fast. Champions who feel heard stay; champions who get a dead room leave.
• Monthly roadmap or preview briefing. Early access is the perk champions value most because it makes them more useful to the community, not because it is secret.
• Quarterly ask: one concrete contribution request (beta feedback, a blog collab, a community event talk), with credit attached.
• Annual moment: a summit, an awards post, or a public Hall of Fame page. One big recognition beat a year outperforms constant small badges.

6. Recognition that costs nothing (and what costs a little)

Free, highest value: public credit by name on release notes, blog features, a Hall of Fame page, titles they can put on a resume ("Champion", "MVP"). Cheap: swag packs they can share at meetups, early feature access, direct Slack/Teams line to engineers, speaking slots, co-authored content. Spend money on: an annual summit or retreat, travel to events. See references/program-archetypes.md for how real programs mix these.

7. Measure and prune

Track quarterly: champion retention rate, average response time in the community, share of community questions answered by champions, referrals or content produced per champion, sentiment of champion feedback to the product team. Ask champions for anonymous feedback every 6 months. Retire inactive champions to an alumni roster (public, honored) rather than quietly dropping them. A stale champion list is worse than a short one.

Output Contract

A champion program design document contains:

1. Charter: one-paragraph mission, champion duties, perk list, 6-month success metrics
2. Candidate list: 5-15 names with the specific behavior signal that surfaced each one
3. Perk menu: what is free, what costs money, with owner and budget per item
4. Cadence plan: channel setup, briefing schedule, quarterly asks, annual recognition beat
5. Measurement plan: metrics, review dates, alumni policy

Use assets/champion-program-brief.md as the template.

Operating Rules

1. Recruit by personal invite only. Mass emails and open applications produce low-commitment signups, not champions. (Application cohorts are the one exception: they work when run in windows with real screening, the Twilio pattern. See references.)
2. Never promise payment for advocacy. Access, recognition, and relationships are the currency. Paid advocacy converts champions into contractors and kills the credibility that makes them valuable.
3. Time ask stays small and explicit: 2-4 hours a month, stated up front. Scope creep is the top burnout cause.
4. Diversity of the cohort is a design input, not an afterthought: mix roles, regions, time zones, and use cases. Champions who all look alike answer the same questions the same way.
5. When a champion flames out or goes toxic, move them to alumni fast and privately. One bad actor costs more than the whole program earns.
6. Do not invent program stats, ROI figures, or benchmark numbers in proposals. If a claim is not from your own analytics or a cited source, cut it or label it an estimate.