Motion community

Motion: Community-Led Growth (CLG)

Contract

This skill guarantees:

• Community stage is diagnosed before any content or program design begins
• Only ONE primary venue is selected — multi-venue sprawl is explicitly blocked
• Content loop is designed by conversion impact, not by content volume
• Community health is measured with leading indicators (WAM, new contributor rate, time-to-first-answer), not vanity metrics (total member count)
• Distribution norms from growth/DOMAIN.md are referenced, not duplicated

---

Role: Community Architect. For developer-first products, community is distribution. Engineers trust engineers. A practitioner writing honestly about solving a real problem with your product reaches the ICP more credibly than any ad. This skill builds the engine that produces that trust at scale.

---

Before starting

Confirm:

• Community existence — does a community exist today? If yes, on which platform(s)?
• ICP card — read knowledge/icp-map.md to confirm who the target community member is; community ICP and product ICP should be the same person
• Experiment history — read experiments/experiment-log.md to check what community or content experiments have been tried; avoid re-running approaches with LOSS verdict
• Current health metrics — if auditing, gather WAM, total member count, and recent signup attribution data before starting

---

Inputs

Required before proceeding:

• Product description and target audience
• Whether designing from scratch or auditing an existing community
• Current community platform(s) if any exist
• Current WAM and total member count (even rough estimates)

If ICP card is available: use Core ICP segment to anchor venue selection and content type decisions — the community must live where the ICP already spends time.

---

Step 1 — Stage Assessment

Diagnosing the current community stage is the first step. The right actions depend entirely on the stage.

Three-stage framework

See growth/DOMAIN.md for the full three-stage community flywheel (Stage 1: Seeding 0→100 active members; Stage 2: Growth 100→1,000+; Stage 3: Sustaining). Reference, do not duplicate.

Stage diagnosis

Apply these criteria to determine which stage the community is in:

Stage 1 — Seeding (0 → first 100 active members)
  
  Criteria for Stage 1:
    - Total active members < 100 (where "active" = asked a question, wrote a post,
      or replied in the last 30 days)
    - Content is primarily produced by founders or the core team, not community members
    - No contributor program or recognition system in place
    - Community may not have a formal venue yet (conversations happening in DMs, at events,
      or scattered across platforms)
  
  Stage 1 diagnosis: [YES / NO]
  Active member count (approx): [number or "not yet measured"]

Stage 2 — Growth (100 → 1,000+ active members)
  
  Criteria for Stage 2:
    - 100+ active members (30-day activity definition from Stage 1)
    - Community has at least one primary venue and a defined "active member" metric
    - Some content is produced by community members (not just team), but team
      still drives most of the editorial output
    - No more than 30% of helpful answers in support/forum come from non-staff
  
  Stage 2 diagnosis: [YES / NO]

Stage 3 — Sustaining (self-generating ecosystem)
  
  Criteria for Stage 3:
    - >30% of helpful answers in forums or support come from non-staff members
    - New contributors join and produce content without direct outreach from the team
    - Community produces canonical content that gets shared outside the community
  
  Stage 3 diagnosis: [YES / NO]

Current stage: [1 / 2 / 3]

Stage-specific priority actions

If Stage 1:
  Priority actions:
    1. Find 10–20 people who have the problem your product solves and engage them
       personally before any content or infrastructure is built
    2. Pick ONE primary venue (see Step 2)
    3. Create the first 3–5 canonical content pieces (migration story, benchmark,
       architecture decision) — these are the content the community will share
    4. Help community members publicly; do not promote the product until trust exists
  
  Stage 1 trap to block: "Build the infrastructure before we have community."
    Nobody joins an empty Slack. Get the first 20 advocates first.
    If there is no primary venue yet: do not create one until you have 10 people who
    have committed to joining.

If Stage 2:
  Priority actions:
    1. Define "active member" precisely (see health metrics in Step 4) and start tracking it
    2. Launch a contributor program: recognize top contributors publicly and amplify their content
    3. Establish a repeatable content loop (see Step 3)
    4. Transition from founder-led to program-led moderation and editorial

If Stage 3:
  Priority actions:
    1. Measure the 30% non-staff answer rate and track it monthly
    2. Focus on editorial quality over production volume — the community produces the content;
       your job is to amplify the best of it
    3. Design the loop from community content → product distribution (see Step 4)
    4. Identify risks to health metrics (contributor burnout, answer latency increasing)

---

Step 2 — Venue Selection Decision

One primary venue only. Spreading across multiple venues at the same time dilutes attention, fragments the community, and creates maintenance burden without payoff.

Venue selection criteria

Criterion 1 — Where does the ICP already spend time?
  (From ICP card: what communities, platforms, forums does the target engineer use?)
  
  Options to evaluate:
    Discord: best for real-time community, developer tools with active user base,
             product support, fast-iteration communities
    Slack: best for professional/practitioner communities; works well for teams already
           using Slack internally; lower public discoverability than Discord
    GitHub Discussions: best for OSS products; engineers are already in GitHub;
                        integrates with the OSS codebase naturally
    Reddit sub: best for topic-based communities with broader reach; high discoverability
                for specific problem spaces; lower real-time engagement
    Forum (Discourse or similar): best for longer-form Q&A and searchable knowledge base;
                                  slower but more durable content
  
  ICP primary platform: [where does your ICP already spend time?]

Criterion 2 — What is the primary community activity?
  Real-time support and discussion → Discord or Slack
  Async technical Q&A and searchable knowledge → GitHub Discussions or forum
  Broad discovery and reach → Reddit sub
  OSS-native community → GitHub Discussions first

Criterion 3 — What is the team's capacity to moderate?
  Low capacity (one person, part-time) → GitHub Discussions or forum (async, searchable)
  Medium capacity → Discord with structured channels
  High capacity → any; Discord with multiple channels and events

Venue decision output

Selected primary venue: [one platform]
Rationale:
  - ICP fit: [one sentence — why this is where your ICP is]
  - Activity fit: [one sentence — why this matches the primary community activity]
  - Team capacity: [one sentence — why this is manageable]

Secondary venue (reference only, not a second community):
  [Platform] for [specific purpose — e.g. "GitHub Discussions for OSS issue triage
  only; Discord is the community home"]

Venues explicitly NOT using and why:
  [Platform]: [one sentence reason — e.g. "LinkedIn: wrong audience register;
  community should feel like a peer space, not a professional network"]

---

Step 3 — Content Loop Design

Community content is the primary conversion driver in CLG. Design the content loop before trying to scale it.

Content types by conversion impact

See growth/DOMAIN.md for the full content types ranked by conversion impact (migration story, technical deep dive, architecture decision record, OSS contribution, honest failure post). Reference, do not duplicate the table.

Priority content type assessment

For the current stage, assess which content types are feasible and which are missing:

Priority 1 — Migration story ("we moved from X to [product]")
  Why it converts: Real constraints and real numbers. Engineers read it to avoid the
  same pain. It is the highest-conversion content type for technical communities.
  
  Do you have a migration story with: named company, real numbers, author who can be contacted?
    [YES / IN PROGRESS / NO]
  If NO: identify the top 2–3 customers who have migrated and could write this story.

Priority 2 — Technical deep dive with benchmarks
  Why it converts: Methodology credibility. Engineers share methodology, not claims.
  
  Exists with: specific setup description, reproducible methodology, honest limits?
    [YES / IN PROGRESS / NO]

Priority 3 — Architecture decision record
  Why it converts: Discoverable via search. Engineers facing the same decision find it.
  
  Exists with: specific trade-off criteria, alternatives considered, reasoning for the choice?
    [YES / IN PROGRESS / NO]

Content loop spec

The repeatable loop that compounds over time:

Step 1 — Identify
  Who: [community manager / growth / DevRel]
  How: monitor community channels and usage data for members with a real story
       (usage milestones, migrations, interesting integrations)
  Signal: high usage frequency + active in community = good candidate

Step 2 — Offer editorial support
  "We noticed you've been [using X feature / migrating from Y] — would you be
  interested in writing about it? We'll help with editing and distribution."
  
  Rules:
    - Editorial support, not ghostwriting — the story must be the author's
    - Do not offer to write it for them; offer to make their story better
    - Never ask them to write promotional content; the story should be honest,
      including trade-offs

Step 3 — Produce
  Format: [migration story / technical deep dive / architecture decision]
  Length and structure: see `growth/DOMAIN.md` developer community story frameworks
  Review gate: every community content piece requires a practitioner voice review
               before publishing (see pmm/content-review)

Step 4 — Distribute
  Platform selection and distribution norms: see `growth/DOMAIN.md` distribution norms
  (HN, Reddit, LinkedIn, X — norms for each platform are defined there; reference, do not duplicate)
  
  Route traffic to: a specific product page or experiment landing page, not the homepage
  Capture: who clicked, who signed up, what they searched for

Step 5 — Feedback and repeat
  Track: community-driven signups (signups where first touch was community content)
  Review: which story type drove the most signups per piece published
  Adjust: prioritize the story type with the highest conversion signal in the next loop

---

Step 4 — Community Health Measurement

Measure leading indicators, not vanity metrics.

Health metric definitions

See growth/DOMAIN.md for the community health metrics table and benchmarks (WAM > 20% of total members; new contributor rate; time to first answer < 4 hours). Reference, do not duplicate.

Health dashboard spec

Metric 1 — Weekly Active Members (WAM)
  Definition: members who asked a question, wrote a post, or replied in the last 7 days
  How to measure: [platform analytics / manual count / export and count]
  Current value: [number or "not yet measured"]
  Current WAM as % of total members: [% or "not yet measured"]
  Target: > 20% of total members
  
  If below 20%: the community has a retention problem, not an acquisition problem.
    Do not invite more members until the active percentage improves.

Metric 2 — New Contributor Rate
  Definition: % of new members who produce content or answers within 30 days of joining
  How to measure: [platform analytics / manual tracking of new member cohorts]
  Current value: [% or "not yet measured"]
  Target: establish baseline, then improve monthly
  
  If near 0%: members join and lurk. Content types are not invitation to participate,
    or joining friction is too high. Fix onboarding to the community (welcome message,
    first question prompt, contributor recognition).

Metric 3 — Time to First Answer
  Definition: median time from a question being posted to the first substantive answer
  How to measure: [manual sample / platform analytics]
  Current value: [hours or "not yet measured"]
  Target: < 4 hours = active community
  
  If > 4 hours: response capacity is insufficient for current question volume.
    Either reduce question volume (better docs / self-serve answers) or
    grow the responder pool (contributor program, team rotation).

Metric 4 — Community-Driven Signups
  Definition: new product signups where first-touch attribution is community content
  How to measure: [self-reported attribution at signup + UTM tracking on content links]
  Current value: [number/month or "not yet measured"]
  
  Note: developer products have a dark funnel problem — HN, Reddit, and Slack
  are invisible to URL-based attribution. Use self-reported "how did you hear about us?"
  at signup in addition to UTM tracking.

Vanity metrics to stop tracking as health signals

• Total member count (grows with any invite; does not indicate engagement)
• Number of messages sent (bot spam inflates this)
• Number of posts published by the company team (company output is not community health)
• GitHub stars as the primary community metric (lagging indicator; not an action target)

---

Output format

Produce all three of the following at the end of the session:

1. Community Stage Assessment

## Community Stage Assessment

Product: [name]
Date: [date]

Current stage: [1: Seeding / 2: Growth / 3: Sustaining]

Stage evidence:
  Active members (30-day): [number]
  % of helpful answers from non-staff: [% or "not yet measured"]
  Primary content source: [team / mixed / mostly community]

Stage-specific priority actions (top 3):
  1. [action]
  2. [action]
  3. [action]

Stage trap to avoid: [one sentence — the most common mistake at this stage]

2. Venue Recommendation

## Venue Recommendation

Selected primary venue: [platform]
Rationale: [2–3 sentences covering ICP fit, activity fit, team capacity]

Secondary usage (reference only):
  [Platform]: [specific narrow purpose]

Venues explicitly excluded: [list with one-line reason each]

If no venue exists yet: do not create one until [specific readiness condition].

3. Content Loop Spec

## Content Loop Spec

Priority content type: [migration story / technical deep dive / architecture decision]
Rationale: [why this type first, for this community at this stage]

Candidate authors identified: [list 2–3 community members or customers with a real story]

Loop cadence: [target content pieces per month — quality over volume]

Distribution plan: [reference growth/DOMAIN.md distribution norms; specify which platforms]

Traffic routing: [specific landing page URL or experiment page, not homepage]

Attribution tracking:
  UTM parameter: [specify]
  Self-reported attribution question: [text of "how did you hear about us" prompt]

Health metrics dashboard:
  WAM (current): [number]
  WAM as % of total: [%]
  New contributor rate: [%]
  Time to first answer: [hours]
  Community-driven signups (current): [number/month]

Next step: /growth-experiment (when baseline metrics are established and content loop is producing)

---

Brain reads / writes

If a companion aether-growth-brain repo is connected:

Before starting:

• Read knowledge/icp-map.md — confirm who the target community member is; community ICP and product ICP should be the same person; venue selection depends on where this person spends time
• Read experiments/experiment-log.md — check what community content or distribution experiments have been tried; do not re-run content types or platforms with LOSS verdict without a variable change

Brain write (when community design is finalized):

• Write community stage assessment and venue recommendation to decisions/motion-community-design-[date].md
• Record content loop spec and health metric baselines in decisions/community-content-loop-[date].md

Brain not connected: proceed; recommend saving the stage assessment and content loop spec locally and reviewing health metrics monthly.

---

Anti-patterns

Anti-pattern	Why it fails	Fix
Building community infrastructure before having community	Nobody joins an empty Slack; infrastructure signals confidence, not community	Get 20 advocates who will show up before creating a venue
Using multiple venues simultaneously at Stage 1 or 2	Effort is split; each venue feels empty; community cannot coalesce	Pick ONE primary venue; secondary usage is reference only, not a second community
Tracking total member count as the primary health metric	Total count grows with any invite; does not indicate engagement or health	Track WAM as % of total; new contributor rate; time to first answer
Writing community content for the company, not the author	Product-promotional "community content" is not trusted by engineers; it reads as marketing	Editorial support only; the story must be honest, in the author's voice, with real trade-offs
Routing community traffic to the homepage	Homepage is designed for multiple audiences; community readers convert better on targeted landing pages	Create and link to experiment-specific landing pages for each content distribution
Measuring community health once a quarter	Community decay is fast; a metric that was healthy 90 days ago may have collapsed	Measure WAM and time to first answer weekly; new contributor rate monthly

---

Validation criteria

• Current community stage diagnosed with explicit criteria (active member count, content source, 30% non-staff answer rate)
• ONE primary venue selected with explicit rationale
• Content loop designed with priority content type, candidate authors, cadence, and distribution plan
• Community health dashboard specified with current baselines for all four metrics
• Vanity metrics (total member count, company post count) excluded from health signals
• Community stage assessment produced
• Venue recommendation produced
• Content loop spec produced

---

References & Sources

Tier 1:

• growth-motion-community (growth-skills v1.0, score 7.5/10): three-stage flywheel, content types by conversion impact, community health metrics, OSS distribution strategy
• growth-platform-execution-norms (growth-skills v1.0, score 7.5/10): distribution norms for HN, Reddit, LinkedIn, X — referenced via growth/DOMAIN.md
• dev-infra-community-story (growth-skills v1.0): story format frameworks for migration story, technical deep dive, architecture decision record — referenced via growth/DOMAIN.md

Tier 2 (via growth/DOMAIN.md):

• Community health metric benchmarks (WAM, new contributor rate, time to first answer)
• Content type conversion impact ranking
• Platform distribution norms
• Developer community story length and structure guidelines