# Playbook: PLG Product-Signal CRM

**School:** Kyle Poyar (OpenView / Growth Unhinged), the PLG / product-qualified-lead school. Thesis: the product itself is the best lead source — a PQL (a real usage threshold crossed) outperforms an MQL (a form filled) because usage is a behavioral proof of intent that no form can fake.

**Deliverable type:** `journey-map` keyed to product events, plus an `automation-spec` stating the exact usage threshold that fires a sales touch.

---

## When to use this

- There is an actual product surface emitting usage telemetry — a free tier, a tool, an assessment, an app. For 19Keys: ZIION funnel tools and the Cognitive Wealth Key assessment both qualify.
- You want sales touches to fire on demonstrated behavior (a user hit a paywall, ran an assessment twice, invited a teammate) rather than on a static form-fill that may or may not indicate real intent.
- You already have (or are willing to build) an event-tracking layer feeding the CRM (pairs naturally with `cdp-event-journeys`).

## When NOT to use this

- There's no product usage surface at all — a pure content/lead-magnet funnel has nothing to instrument here; use lead-scoring-routing or lifecycle-stage-orchestration instead.
- The product usage events are too sparse or too rare to define a meaningful threshold (a tool used once a year can't anchor a live PQL trigger).
- Sales touching every active user regardless of depth would be the wrong motion (self-serve businesses sometimes want *fewer* sales touches, not more — check this isn't actually working against a self-serve strategy).

## Step-by-step build

1. **Inventory the product events worth tracking.** Not every click — pick the handful that correlate with buying intent (hit a usage cap, completed a core action N times, invited a collaborator, viewed pricing from inside the product).
2. **Define the event schema.** Each event needs a name, the identify key it's attached to, and any payload fields needed for scoring (e.g., `assessment_completed` with a `result_type` field).
3. **Set the PQL threshold as a machine-evaluable rule.** Not "actively engaged" — e.g., "completed the Cognitive Wealth Key assessment AND returned to view results a second time within 7 days."
4. **Combine with firmographic/intent signals where available** — Poyar's model blends usage with fit, it doesn't rely on usage alone for B2B-flavored motions.
5. **Wire the threshold to a lifecycle-stage transition.** Crossing the PQL threshold should move `lifecycle_stage` forward (e.g., to MQL-equivalent or a dedicated PQL stage) exactly like a form-fill would in the lead-scoring-routing playbook — same spine, different trigger source.
6. **Write the automation-spec for the resulting sales touch**, with the usual mandatory EXIT (stop touching once the user converts, churns the product, or opts out) and idempotency (don't re-fire the same PQL touch every time the threshold-crossing event re-fires).
7. **Instrument PQL→SQO conversion** as the quality counter-metric — track it separately from PQL volume so a loosened event definition doesn't get away with inflating volume unnoticed (Goodhart, MANUAL §2.2.G).

## Worked mini-example

Event: `cwk_assessment_completed` fires when a user finishes the Cognitive Wealth Key assessment, with payload `result_type` (one of the 6 cognitive types). PQL threshold: `cwk_assessment_completed` AND a second session viewing the results page within 7 days of completion (signals real interest, not a one-and-done click-through). On threshold-cross, `lifecycle_stage` moves to "PQL," and an automation-spec fires: a personalized email referencing the user's specific `result_type`, with a booking link, sent within 30 minutes of the threshold event (fast, though not the hard 5-minute inbound-lead SLA — this is a warm nurture touch, not a raw speed-to-lead moment). EXIT: stops if the user books a call or if 30 days pass with no further engagement (moves to a slower nurture track instead of the active PQL sequence).

## How the verify gate applies

The `journey-map` linter requires the product-event-keyed stages to have entry criteria stated as machine-evaluable rules (a named event + payload condition, not "engaged users"). Every automation touching this journey must be listed with its spec-file reference. The `automation-spec` for the sales touch still needs its mandatory EXIT and idempotency note — a PQL automation that re-fires every time the qualifying event re-triggers (e.g., the user completes a second assessment) without an idempotency guard will spam a converted user, which is exactly the "no exit" failure mode banned in MANUAL §8.1.