# Community & PLG Director Playbook

Reference playbook for the community-plg-director skill. Read the relevant section before producing any community/PLG artifact.

## Table of Contents

1. OSS Monetization Models
2. Community Signal Model - Build Guide
3. PQL Framework - Design and Calibration
4. PLG Funnel Architecture - Detailed Design
5. Community-to-Commercial Handoff - Process Design
6. DevRel Alignment - Operating Model
7. Enterprise Nurture for Community Users
8. Upgrade Conversation Frameworks
9. Community Health Metrics
10. Conversion Benchmarks and Targets

---

## 1. OSS Monetization Models

### The OSS Monetization Spectrum

Understanding which model a company uses (or should use) determines the entire community/PLG architecture.

| Model | How It Works | Examples | Community Implications |
|-------|-------------|----------|----------------------|
| Open Core | Core product is OSS, enterprise features are proprietary | GitLab, Elastic, Fleet | Clear upgrade path based on feature needs |
| Support/Services | Full product is OSS, revenue from support and services | Red Hat (historical) | Conversion driven by scale and complexity |
| Cloud Hosting | OSS product, managed hosting is the commercial offering | MongoDB Atlas, Confluent Cloud | Conversion driven by operational burden |
| Dual License | OSS for small/dev use, commercial license for production/enterprise | MariaDB, Qt | Conversion driven by usage scale and compliance |
| Marketplace/Extensions | Core is free, extensions/integrations are commercial | WordPress (model), Shopify apps | Ecosystem-driven conversion |

### Open Core Feature Gating Strategy

For Open Core companies (the most common model for enterprise OSS):

**Features that should be free (community tier):**
- Core product functionality that defines the category
- Everything needed to evaluate and adopt the technology
- Features that drive community growth and word-of-mouth
- Features that individual contributors use day-to-day

**Features that should be enterprise (paid tier):**
- Administrative and governance capabilities (RBAC, audit logs, SSO)
- Compliance and security features (encryption, certifications, policy enforcement)
- Scale features (multi-team, multi-tenant, high availability)
- Support guarantees (SLA, dedicated support, professional services)
- Advanced analytics and reporting

**The Gating Principle:** Users should be able to do their individual job with the free version. When the organization needs to manage, secure, or scale the tool, that's when enterprise value kicks in.

**Anti-patterns:**
- Gating basic functionality to force upgrades (erodes trust, drives forks)
- Making the free tier so good there's no enterprise reason to pay (leaves money on table)
- Unclear or shifting feature boundaries (confuses users and sales)

---

## 2. Community Signal Model - Build Guide

### Step 1: Inventory Available Data Sources

Map every system that captures community/product behavior:

| System | Data Available | Signal Potential |
|--------|---------------|-----------------|
| Product telemetry | Usage metrics, feature adoption, deployment size, error rates | High - most reliable indicator of enterprise readiness |
| GitHub | Stars, forks, PRs, issues, contributor activity | Medium - indicates investment but not always commercial intent |
| Community Slack/Discord | Channel activity, questions asked, topics discussed | Medium-High - questions reveal needs |
| Documentation site | Page views, search queries, time on page | Medium - what they're researching |
| Marketing site | Pricing page views, enterprise page views, demo requests | High - explicit commercial interest |
| Email/newsletter | Opens, clicks, content engagement patterns | Low-Medium - passive indicator |
| Events | Registration, attendance, speaker engagement | Medium - indicates investment |

### Step 2: Define Signal-to-Tier Mapping

For each data source, define specific signals and map to tiers:

**Product Telemetry Signals:**

| Signal | Description | Tier | Rationale |
|--------|-------------|------|-----------|
| Deployment > threshold | Active deployment exceeds enterprise threshold | 1 | They've committed to the tech at enterprise scale |
| Enterprise feature blocked | Attempted to access paid feature and hit paywall | 1 | Explicit enterprise need |
| Multi-user from same org | 3+ users from same email domain | 2 | Organizational adoption underway |
| Production deployment detected | Deployment characteristics match production patterns | 2 | Past evaluation, in real use |
| Usage acceleration | 50%+ increase in usage over 30-day period | 2 | Growing dependency |
| API integration detected | Using API to integrate with other enterprise tools | 2 | Embedding into workflows |
| Performance query | Questions about scaling, performance, HA | 2 | Outgrowing current setup |

**Community Platform Signals:**

| Signal | Description | Tier | Rationale |
|--------|-------------|------|-----------|
| Compliance/security question | Asks about SOC2, FedRAMP, HIPAA, encryption, audit | 1 | Enterprise compliance driver |
| Support escalation | Requests SLA-backed support or professional services | 1 | Enterprise support need |
| Architecture question | Asks about HA, disaster recovery, multi-site deployment | 2 | Enterprise infrastructure planning |
| Migration question | Asks about migrating from competitor or internal solution | 2 | Active evaluation |
| Integration question | Asks about SSO, SCIM, IdP, SIEM integration | 2 | Enterprise toolchain integration |
| Contributor activity | Submits PRs, reviews code, contributes docs | 3 | Deep investment but not necessarily commercial |
| General questions | How-to, troubleshooting, basic configuration | 4 | Normal community activity |

### Step 3: Build the Composite Scoring Model

```
SIGNAL SCORE = base_weight × recency_multiplier × frequency_multiplier × icp_multiplier

base_weight:
  Tier 1 signal: 30 points
  Tier 2 signal: 15 points
  Tier 3 signal: 5 points
  Tier 4 signal: 1 point

recency_multiplier:
  Last 7 days: 1.0
  8-30 days: 0.7
  31-90 days: 0.4
  90+ days: 0.2

frequency_multiplier:
  One-time occurrence: 1.0
  2-3 occurrences: 1.5
  4+ occurrences: 2.0
  Accelerating pattern: 2.5

icp_multiplier:
  Strong ICP match (firmographics confirmed): 1.5
  Moderate ICP match (partial firmographic data): 1.0
  Unknown/unmatched: 0.7
  Non-ICP: 0.3

ACCOUNT SCORE = Sum of all signal scores for the organization

THRESHOLDS (calibrate to your data):
  Hot (route to SDR): >80
  Warm (enterprise nurture + SDR): 50-80
  Developing (monitor): 20-50
  Community (serve, don't sell): <20
```

### Step 4: Build Infrastructure

```
DATA PIPELINE:
  Product telemetry → Data warehouse
  Community platforms → Community analytics tool or data warehouse
  Website → Analytics platform
  CRM → Enrichment (Clearbit/ZoomInfo/Apollo for org matching)
  
  ↓ All sources merge on email domain / org identifier ↓

SCORING ENGINE:
  Calculate account-level scores daily (or real-time for Tier 1 signals)
  Store score + contributing signals in CRM or scoring tool
  
ROUTING:
  Score > threshold → Create CRM task for SDR
  Score > threshold + existing owner → Alert owner via Slack/email
  New Tier 1 signal → Immediate alert regardless of score

MONITORING:
  Track: signal volume, PQL generation rate, false positive rate
  Calibrate: adjust thresholds quarterly based on conversion data
```

---

## 3. PQL Framework - Design and Calibration

### PQL Design Process

**Step 1: Analyze closed-won customers backward**

Pull last 12-24 months of closed-won enterprise deals. For each:
- What was their product usage before becoming a customer?
- What community signals existed before commercial engagement?
- What triggered the commercial conversation?
- How long between first product use and first commercial meeting?

Look for patterns - the common usage/behavior thresholds that preceded conversion.

**Step 2: Define candidate PQL criteria**

Based on the pattern analysis, define 3-5 candidate PQL definitions with different threshold combinations.

Example candidates:
```
PQL Definition A (strict):
  - Deployment > 1,000 devices AND
  - Enterprise feature attempt in last 30 days AND
  - ICP score > 70

PQL Definition B (moderate):
  - Deployment > 500 devices AND
  - Any Tier 1 or Tier 2 signal in last 60 days AND
  - ICP score > 50

PQL Definition C (broad):
  - Active deployment (any size) AND
  - Community engagement score > 50 AND
  - ICP score > 50
```

**Step 3: Backtest against historical data**

For each candidate definition, check:
- How many of your current customers would have qualified as PQLs before their deal?
- How many non-customers would qualify today? (potential false positives)
- What's the estimated conversion rate for each definition?

**Step 4: Select and calibrate**

Choose the definition that optimizes for:
- High enough volume to be useful (at least 10-20 PQLs per month)
- High enough conversion rate to be worth SDR time (target >15% PQL-to-meeting)
- Low enough false positive rate to maintain SDR trust (<50% disqualification)

**Step 5: Iterate**

Review PQL performance monthly:
- PQL volume trending (up, down, stable)
- PQL-to-meeting conversion rate
- PQL-to-opportunity conversion rate
- PQL-to-closed-won conversion rate
- SDR feedback on PQL quality
- Adjust thresholds quarterly

---

## 4. PLG Funnel Architecture - Detailed Design

### Self-Serve to Enterprise Upgrade Path

```
SELF-SERVE TIER:
  Entry: User signs up, downloads, or deploys
  Value: Core product functionality + community support
  Limits: Feature-gated (no enterprise capabilities), support via community only
  Upgrade triggers:
    - Hits feature gate (SSO, RBAC, compliance features)
    - Exceeds usage threshold (devices, users, deployments)
    - Requests SLA-backed support
    - Admin/security features needed

  ↓ UPGRADE MOMENT (the critical transition) ↓

ASSISTED EVALUATION:
  Entry: User expresses interest in enterprise features (in-product, website, community)
  Experience: Talk to a human who understands their community context
  Value: Personalized guidance on enterprise capabilities, proof that the upgrade is worth it
  Key: The transition should feel like BETTER SERVICE, not a sales pitch

  ↓

ENTERPRISE DEAL:
  Entry: Formal evaluation with defined timeline and stakeholders
  Experience: Standard enterprise sales process (discovery, demo, proposal, negotiation)
  Key: Sales team has FULL CONTEXT from community/product usage
```

### In-Product Upgrade Triggers

Design product experiences that naturally surface upgrade moments:

| Trigger | In-Product Experience | Backend Action |
|---------|----------------------|----------------|
| Feature gate hit | "This feature is available in Fleet Premium. Learn more →" | Log attempt, increment PQL score |
| Usage threshold approached | "You're managing [N] devices. See how enterprise customers manage [10x] →" | Alert SDR if ICP match |
| Admin feature needed | "Set up SSO for your team → (Enterprise feature)" | Log interest, update PQL score |
| Support limit | "For priority support with SLA, explore our enterprise plan →" | Route to SDR if score qualifies |
| Compliance content | "Need SOC2/FedRAMP compliance documentation? →" | Strong enterprise signal, alert immediately |

**Design principles for in-product prompts:**
- Never block the user from their current task
- Always provide a "dismiss" or "not now" option
- Show the value of the upgrade, not just the paywall
- Don't show upgrade prompts to users who've already dismissed 3+ times (switch to passive)
- Track impressions, clicks, and dismissals to optimize

---

## 5. Community-to-Commercial Handoff - Process Design

### The Three Handoff Models

**Model A: Automated Nurture → SDR Follow-Up (for Warm PQLs)**
```
PQL detected (score 50-80)
  → Auto-enroll in enterprise email nurture (3-email sequence over 10 days)
  → If email engagement → SDR personalized follow-up
  → If no engagement → Continue monitoring, re-engage on next signal
```

**Model B: SDR Direct Outreach (for Hot PQLs)**
```
PQL detected (score >80 or Tier 1 signal)
  → SDR receives alert with full community context package
  → SDR conducts 10-min account research
  → SDR sends personalized outreach referencing community context
  → Channel: Email + LinkedIn (phone only if relationship warrants)
```

**Model C: DevRel Warm Introduction (for high-relationship accounts)**
```
Community member has strong DevRel relationship + enterprise signals
  → DevRel discusses enterprise needs in natural conversation
  → If interest confirmed → DevRel makes warm intro to SDR/AE
  → SDR/AE receives full context + DevRel's perspective
  → First meeting includes DevRel (for trust continuity) if appropriate
```

### Outreach Templates for Community-to-Commercial

**Email - PQL with deployment signal:**
```
Subject: [Company]'s Fleet deployment

Hi [Name],

I work with the Fleet enterprise team. I noticed [Company] has been
running Fleet across [general deployment context - don't be creepy
about specifics].

A lot of organizations at your stage start looking at [enterprise
capability - SSO, compliance reporting, etc.] - is that on your radar?

If so, happy to walk through how [similar company] handles it.
If not, no worries - just wanted to make sure you knew the option exists.

[Signature]
```

**Email - PQL with community signal:**
```
Subject: Following up on your [community channel] question

Hi [Name],

I saw your question in [#channel] about [topic]. Great question -
it comes up a lot as teams scale their deployments.

For [topic], our enterprise customers typically [brief insight].
[Customer name] wrote about their approach here: [link].

If you'd like to dig deeper into how this works at [Company]'s
scale, happy to set up 20 minutes. Otherwise, hope the resource helps.

[Signature]
```

**What NOT to say:**
- "I see you've been using our product for free..." (makes free feel wrong)
- "Would you like to upgrade?" (too transactional, too early)
- "I noticed your GitHub activity..." (feels surveillance-like)
- "As a valued community member..." (corporate speak that breaks trust)

---

## 6. DevRel Alignment - Operating Model

### DevRel Role Definition

```
PRIMARY MISSION:
  Build and serve a thriving community of practitioners who use,
  contribute to, and advocate for the technology.

SECONDARY MISSION:
  Generate enterprise pipeline through community trust and engagement
  (measured by influence, not direct attribution).

NOT THE MISSION:
  Book meetings, qualify leads, or sell enterprise product.
```

### DevRel Activities and GTM Alignment

| Activity | Community Value | Pipeline Value | Alignment Need |
|----------|----------------|----------------|----------------|
| Community content (tutorials, guides) | High - educates and attracts users | Medium - enterprise users also consume this | Ensure some content addresses enterprise use cases |
| Conference talks | High - builds thought leadership and community | Medium - enterprise prospects attend conferences | Choose conferences where ICP attends |
| Community support | High - retains users, builds trust | Low-Medium - surfaces enterprise signals | Route enterprise signals to GTM automatically |
| Office hours / workshops | High - deep engagement with practitioners | Medium - enterprise teams attend these | Make enterprise-relevant topics available |
| Open-source contribution management | High - product improvement, community health | Low - indirect pipeline contribution | N/A |
| Customer advisory participation | Medium - informs roadmap | High - deepens enterprise relationships | Coordinate with CS on attendee selection |

### DevRel Reporting Structure

**Option A: DevRel reports to Marketing (most common)**
- Pro: Aligns community with demand gen and content
- Con: Risk of pipeline pressure compromising community trust
- Mitigation: Community health metrics weighted >50% of DevRel evaluation

**Option B: DevRel reports to Product (good for OSS-heavy)**
- Pro: Aligns community with product development
- Con: Can become disconnected from GTM entirely
- Mitigation: Dotted-line to Marketing with shared KPIs

**Option C: DevRel reports to CEO/CRO (early-stage)**
- Pro: Community gets executive attention and protection
- Con: Not scalable; executive context-switching
- Mitigation: Transition to Marketing or Product reporting by 50+ employees

---

## 7. Enterprise Nurture for Community Users

### Nurture Sequence Design

**Trigger:** Account crosses "Warm" PQL threshold (score 50-80)

**Sequence (3 emails over 10 days, then SDR follow-up):**

```
Email 1 (Day 0): Enterprise insight
  Subject: How [industry] teams scale [product category]
  Content: Insight article about enterprise deployment patterns.
  No product pitch. No CTA to talk to sales.
  CTA: "Read the full guide" (links to enterprise-relevant content)

Email 2 (Day 4): Peer proof
  Subject: How [similar company] manages [N] devices with [product]
  Content: Case study from a company similar to their ICP segment.
  Light CTA: "Want to see how this would work for [their company]?"

Email 3 (Day 8): Direct value offer
  Subject: Enterprise [product] for [Company]
  Content: Specific enterprise capabilities relevant to their signals.
  CTA: "15 minutes to walk through the enterprise capabilities?
  Or if you prefer, here's a self-guided tour: [link]"

Day 10+: SDR personalized follow-up
  If engaged with any email → Personalized outreach referencing engagement
  If no engagement → Hold. Re-enter on next signal.
```

**Key principles:**
- Never send from a "no-reply" address - send from a real person (SDR or DevRel)
- Content should be genuinely valuable even if they never buy
- Each email should stand alone (don't reference previous emails)
- Respect opt-outs immediately and permanently
- Never enroll the same account in multiple nurture sequences simultaneously

---

## 8. Upgrade Conversation Frameworks

### The Value Expansion Framework

When a community user or free tier customer expresses interest in enterprise:

```
STEP 1: ACKNOWLEDGE THEIR SUCCESS
  "You've been running [product] across [context]. How's it going?"
  WHY: Validates their choice. Shows you know their situation.

STEP 2: EXPLORE THE ENTERPRISE NEED
  "What prompted you to look at the enterprise capabilities?"
  "What's changed in your environment that's creating this need?"
  WHY: Let them tell you why they need enterprise. Don't assume.

STEP 3: MAP VALUE TO THEIR SPECIFIC SITUATION
  "For organizations at your scale with [their specific context], the
   enterprise version typically helps with [2-3 specific capabilities
   mapped to what they told you in step 2]."
  WHY: Personalized value, not a feature list.

STEP 4: QUANTIFY THE GAP
  "Right now, how is your team handling [enterprise capability they lack]?"
  "What does that cost in terms of time / risk / compliance exposure?"
  WHY: Establishes the cost of NOT upgrading.

STEP 5: REDUCE SWITCHING FRICTION
  "The good news is, upgrading from the community version is [process].
   Your existing [configurations/deployments/data] carry over. [Customer]
   completed the upgrade in [timeframe]."
  WHY: The biggest fear isn't "is enterprise better?" - it's "is upgrading painful?"

STEP 6: PROPOSE NEXT STEP
  "Would it be helpful to see how this works in your specific environment?
   We can set up a 30-minute session focused on [their top 1-2 needs]."
  WHY: Specific, low-commitment, focused on their needs.
```

### Common Upgrade Objections

| Objection | What They Mean | Response |
|-----------|---------------|----------|
| "The free version does everything we need" | Enterprise need hasn't surfaced yet, or they're managing without it | "That's great - means the technology is working. Most teams find the enterprise need surfaces when [common trigger: audit, compliance requirement, team growth, incident]. Is any of that on the horizon?" |
| "We can build what we need ourselves" | Engineering team wants to maintain control; DIY culture | "A lot of our enterprise customers started that way. What they found was [specific TCO comparison]. [Customer] estimated they were spending [N hours/month] maintaining their own [capability]." |
| "It's too expensive" | Price-to-value equation isn't clear | "What are you comparing it to? [Pause]. When we break it down per device, it's [$X/device/month]. Is it the total number, or the value-per-dollar question?" |
| "We need to check with [stakeholder]" | Not the decision-maker, or haven't built internal consensus | "That makes sense. What would be most helpful - should we set up a session that includes [stakeholder], or would you prefer to share some materials first? I can put together something specific for [their role]." |

---

## 9. Community Health Metrics

### Community Health Dashboard

| Metric | What It Measures | Healthy | Warning | Critical |
|--------|-----------------|---------|---------|----------|
| Monthly active community members | Engagement breadth | Growing 5%+ MoM | Flat | Declining |
| Community engagement rate | Active / total members | >20% | 10-20% | <10% |
| New member retention (30-day) | Are newcomers sticking? | >40% active at day 30 | 25-40% | <25% |
| Questions answered within 24hr | Community responsiveness | >80% | 60-80% | <60% |
| Contributor growth | People submitting PRs/content | Growing MoM | Flat | Declining |
| Sentiment (qualitative) | Community mood | Positive, collaborative | Mixed | Negative, adversarial |
| Enterprise signal volume | Commercial potential | Growing MoM | Flat | Declining |

### Community Health vs. Pipeline Health Tradeoffs

When community health and pipeline metrics conflict, community health wins in the long term. Short-term pipeline gains from aggressive community monetization destroy long-term pipeline potential.

**Examples of healthy tension:**
- "We want more PQLs" vs. "Community engagement is declining" → Fix community first
- "SDRs want to contact community members directly" vs. "Community trust is high" → Use the handoff protocol
- "Marketing wants to gate community content" vs. "Ungated content drives community growth" → Keep community content ungated; create separate enterprise content

---

## 10. Conversion Benchmarks and Targets

### OSS/PLG Conversion Benchmarks

| Metric | Early (pre-$5M ARR) | Growth ($5-20M ARR) | Scale ($20M+ ARR) |
|--------|---------------------|---------------------|--------------------|
| Signup-to-active-user | 15-25% | 20-30% | 25-35% |
| Active-user-to-PQL | 2-5% | 3-7% | 5-10% |
| PQL-to-meeting | 15-25% | 20-30% | 25-35% |
| PQL-to-opportunity | 10-15% | 12-20% | 15-25% |
| PQL-to-closed-won | 3-8% | 5-12% | 8-15% |
| Time: signup to PQL | 60-180 days | 45-120 days | 30-90 days |
| Time: PQL to closed-won | 60-120 days | 45-90 days | 30-75 days |
| Community-sourced pipeline % | 10-20% of total | 15-30% | 20-40% |

### Setting Realistic Targets

When setting community/PLG pipeline targets:

1. Start with current baseline (even if it's "we don't know")
2. Instrument before you optimize (you can't improve what you can't measure)
3. Set improvement targets, not absolute targets for the first 2 quarters
4. Expect 2-3 quarters of infrastructure building before meaningful pipeline impact
5. Community/PLG pipeline should complement, not replace, outbound and inbound
