product-signallisted

# Product Signal The product function's place in the loop. Marketing has `marketing-feedback`; CS has `account-health`; this is product's. It pulls the signals that should shape what gets built out of the shared log into product's own triage queue, and — for anything shipped — writes the one-line "what this means for the buyer" so a feature doesn't land silently. This closes handoffs **H4** (CS→product) and **H5** (product→GTM) in [`docs/operating-model.md`](../../../docs/operating-model.md). From the shared feedback log (`demo/feedback-log.md`, or your own) and `ops/customers.md`: 1. **Pull the product-shaped signals.** Three kinds belong on the roadmap, not in a meeting note: - `RETENTION-RISK` lines that are really a product gap — adoption friction or a missing capability, not a CS task. - `FEATURE-REQUEST` items that block an adoption or an expansion (the ones tied to a renewal or a second team). - Win/loss reasons that are about the *product*, not the deal — what we couldn't do that cost us, or won us, the deal. 2. **Route each into `ops/roadmap-signals.md`.** One row per signal: the source, the type, the account or pattern it's tied to, where it's routed, and a status (New → Routed → Shipped). This is product's working surface — distinct from the raw log it's pulled from. 3. **Wait for the pattern on anything ambiguous.** A single request isn't a roadmap item; a request that recurs across accounts, or one blocking a real renewal, is. Don't route noise. 4. **