Pmm Research Brief

PMM Research Brief — the research front door

A user rarely hands you clean parameters. They dump a product, ten features, and a goal in one breath. Your job is to distill that ramble into a complete research plan the pipelines can run: extract the product, infer the ICP and market, and scope every research discipline with named entities — so pmm-research-desk can execute the full sweep and the rest of PMM OS hydrates from real evidence.

Research is comprehensive and mandatory, not pick-and-choose. An impeccable launch needs customer + competitive + market + pricing + channels + analyst/KOL + events + GTM/launch motion + product — all of it, the way a real PMM works. You decide each desk's scope and the run order; you never decide whether to skip a discipline.

This runs before research and strategy. It produces the plan; it doesn't (yet) produce positioning or a launch — that comes after the desks return evidence.

Workflow

1. Capture the input — the user's description plus any docs/URL/repo they point to. Read .agents/product-marketing.md if it exists. Don't ask for what's already there.
2. Distill the Product Brief from ../product-marketing-os/assets/research-brief-template.md: product name, one-line what-it-is, what it does, key features (deduped to capabilities), ICP hypothesis (segment · seniority · company type), market/category, the goal/motion (launch? GTM? positioning?), constraints, and explicit unknowns. Infer where reasonable, but mark every inference as a hypothesis to verify — never assert invented facts (that's the whole point of researching them).
3. Set the Scope — adaptively. Before planning desks, decide which scope dimensions actually constrain this product and at what granularity, per ../product-marketing-os/references/research-scope-model.md: geography (county → metro → region → national → international — name the places when tight), timeframe & seasonality (the launch window + which quarters carry the signal; annual vs one-off), exhaustiveness targets (events ≥ 12–15 in-geo, competitors = the full set, channels/KOLs ≥ 10), segments (B2C/B2B), and constraints (budget, regulatory). These are user/strategy-dependent — a local service business is one county; a global SaaS is "international, events cluster by region." Ask the user the few that genuinely change the research (e.g. "Which geography and time of year should events cover?") rather than guessing; infer the rest and mark inferences. Write a ## Scope block into .agents/research/brief.md — every desk reads it.
4. Build the Research Plan — distill, then scope ALL of it. The plan is a complete, mandatory sweep across all ten desks (../product-marketing-os/references/research-desks/README.md): product, customer, competitive, market, pricing, channels, analyst/KOL, events, reviews, and GTM/launch motion. For each desk you scope it with named entities (candidate competitors, the segment, the market, the events, the specific questions) and set a run order by dependency — but you do not skip any. This is where a ramble becomes engine parameters: you name "research Amplitude, Mixpanel, PostHog" so the Competitive Desk has targets, "segment = PMs at self-serve SaaS" so the Customer Desk is scoped, and "PM meetups + SaaStr + data conferences" so the Events Desk knows where to look. Events is always in — the question is which events, never whether. Each desk also inherits the ## Scope (geo · timeframe · exhaustiveness target) from step 3.
5. Pass the Plan gate — hypothesis + issue tree BEFORE any engine call. Research here is hypothesis-driven, not exploratory drift (the standard: deliverable-standard §1 #4–6 and §5 gate 1). Precondition — ground the product first. If the product has a codebase, a live app, or founder artifacts (demo scripts, decks, planning sheets), run pmm-product-context Stage 0 and produce .agents/research/product-grounding.md before writing the hypothesis — a day-1 hypothesis about a mis-defined product poisons every desk downstream. The hypothesis and issue tree are written about the grounded product (shipped capabilities, real gating, the intent-vs-implementation gaps), never about the founder's unverified description. Write two artifacts into .agents/research/:
   • hypothesis.md — the day-1 hypothesis: "Likely answer: X, because A/B/C" plus the disconfirming evidence that would kill it, named. As desk findings land they score supporting / refuting / neutral against it, and pivots are logged in this same file — append, never overwrite — so a defensible current-best-answer exists at every point of the run.
   • issue-tree.md — a MECE issue tree decomposing the goal: 2–4 branches per level, open what/how/why questions, leaves testable by an engine call. Score every leaf priority = impact-on-answer × evidence-availability, then write the depth allocation: deep leaves get the multi-engine fan-out, low-priority leaves get one quick pass, and de-scoped leaves are named as "not investigated" — never silently dropped. Every desk run maps its engine calls to tree leaves. No engine call happens before both files exist — this is the pipeline's Plan gate, and pmm-research-desk checks it.
6. Write .agents/research/brief.md (the Product Brief + ## Scope + Research Plan) and seed the context spine via pmm-product-context.
7. Confirm, then run. Research can be long and (for some sources) metered, so show the brief + scope + plan and the desks you'll run, in priority order. On "go" (or if the user already said run it), hand each planned desk to pmm-research-desk highest-priority first. Desks run as a sequence of sprints, not one batch: each desk opens its own mini-hypothesis, and closes by appending re-scoping findings to .agents/research/carry-forward.md, which the next desk reads at scope time (see the README's Desk sprints rule) — so the run order you set is also the learning order. As evidence accrues in the ledger, the hard gate on downstream strategy is satisfied.

Output

• Product Brief — the distilled understanding, hypotheses marked.
• ## Scope — geography (+ granularity) · timeframe/seasonality · exhaustiveness targets · segments · constraints, adapted to this product. The desks filter and pursue against this.
• Research Plan — a ranked desk-by-desk table: relevance · scoped entities · key questions · which engines/sources. This is the bridge from ramble → pipeline.
• The Plan-gate artifacts — .agents/research/hypothesis.md (day-1 hypothesis + disconfirming evidence + the append-only pivot log) and .agents/research/issue-tree.md (the scored MECE tree + depth allocation). No desk may fire an engine call before both exist.
• The queued desk runs (or the executed ones, if the user said go).

Worked example (a real ramble → brief + plan)

"I have a product called Plotline — self-serve product analytics PLUS a shared metrics layer. Any PM can ask a product question in plain English and get the funnel or cohort in minutes instead of filing a ticket for the data team and waiting days. It keeps one definition of 'activated' so teams stop arguing about whose number is right. I want a successful launch + GTM."

Brief: Plotline — self-serve product analytics + a shared metrics layer. Core job: stop waiting days in a data-team queue for product answers (plain-English questions → funnels/cohorts in minutes, no SQL) + one shared definition of activation so every team reads the same number. ICP hypothesis: PMs/PMMs at product-led SaaS teams without a large data org; possible motion to heads of data (deflect the self-serve question queue). Market: product analytics. Goal: launch + GTM. Unknowns: PLG-only vs. also sales-assisted, pricing, the real competitive set, the primary channel.

Scope (ask the user the few that move the research): Geography — the product is online (PLG), so channels skew digital/global; but field events cluster by city, so ask "which metros?" (e.g. SF Bay Area, NYC, Austin). Timeframe — launch window + the conference calendar (Q3 SaaS conferences, Q1 planning cycles). Exhaustiveness — events ≥ 15 in-geo, the full competitor set (not top-3), channels/KOLs ≥ 10. Segments — PMs/PMMs at self-serve SaaS (primary) + heads of data (secondary).

Plan (all ten, scoped — nothing skipped):

• Product 🟢 — confirm Plotline's capabilities/differentiators from its docs.
• Customer 🔴 — PM/PMM pains around data-team queues (r/ProductManagement, r/analytics, PM Slack communities); + head-of-data pains for the deflection angle.
• Competitive 🔴 — Amplitude, Mixpanel, PostHog, Heap, June, Pendo, dashboards-in-BI (Looker, Metabase) (incl. their self-serve/AI-query features).
• Market 🔴 — product-analytics category; why-now: data-team backlogs, AI natural-language querying, dashboard sprawl.
• Pricing 🟡 — Amplitude / Mixpanel / PostHog free-tier + MTU/event-based models.
• Channels 🔴 — r/ProductManagement, Product Hunt, LinkedIn, PM newsletters (Lenny's), data-tool communities.
• Analyst/KOL 🟡 — PM/analytics creators (Lenny Rachitsky, product-analytics voices on LinkedIn/YouTube).
• Events 🔴 — product-management meetups (city), SaaStr, ProductCon, analytics/data conferences, launch-week showcases; B2B if selling to data leads: dbt Coalesce, Data Council — where you can table, sponsor, or speak.
• Reviews 🔴 — G2/Capterra/TrustRadius pages for Amplitude, Mixpanel, PostHog, Heap, Pendo (dislike fields + switching reviews); Glassdoor for org-health CI on the top 2.
• GTM/Launch 🔴 — how Amplitude/Mixpanel/PostHog launched (Product Hunt, open-source communities, free tiers), PLG-vs-sales motion, activation moment, launch-day plan.

Run order: Product → Customer → Competitive → Reviews → Channels/Events/GTM → Market/Pricing/KOL. The full sweep — every discipline a PMM owns plus the GTM/launch motion. None skipped.

Hand off to

PMM OS is a chain, not a menu — don't dead-end at a plan. Pass the work on:

• pmm-research-desk — run each planned desk
• pmm-product-context — seed the context spine
• product-marketing-os — the full chain after evidence lands.