Run the First-72-Hours Post-Launch Triage Pipeline

Workflow area: Launch & GTM · Tier: Core · Hands-on time: ~40 minutes setup

Launch week feedback arrives through six doors at once: app-store reviews, support tickets, social posts, community threads, sales Slack, and the metrics themselves. No PM can read all of it twice a day, so most teams either drown or go selectively deaf — and the signal that mattered surfaces on day four, expensive. The pipeline's job is compression with severity attached; your job is the verification pass that keeps the compression honest.

When to use — and when not to

• Use it for any launch with real blast radiusnew surface areas, pricing changes, migrations, anything touching existing users' workflows.
• Use it when feedback channels outnumber your reading hoursthe pipeline is compression; if you can genuinely read everything, just read everything.
• Use the twice-daily cadence, not real-time alertsbatch triage at 9am and 5pm beats a firehose that trains everyone to ignore it.
• Skip auto-escalation entirelythe pipeline drafts severity calls; it never pages an engineer or posts to the incident channel on its own. A hallucinated Sev-1 at 2am is how teams turn the pipeline off forever.
• Skip it for silent backend launchesif users can't see the change, watch dashboards and error budgets instead; there's no qualitative firehose to triage.

The recipe

1. 1.

   Wire the inputs before launch day. Use Zapier (or n8n) to collect into one place — a Google Sheet or Slack channel per launch: new app-store reviews mentioning the feature, support tickets tagged to the launch, social and community mentions from your listening tool, and a metrics snapshot (adoption, error rate, support contact rate) exported at 9am and 5pm. Each item keeps its source link. Do a dry run the day before launch with dummy items.

2. 2.

   Define severity in writing. The pipeline is only as good as this rubric, so make it concrete:

   Copy

   SEV-1: data loss, security exposure, payment failures, or a
          crash/blocker pattern reported by 3+ independent sources
   SEV-2: core workflow degraded, workaround exists, or negative
          pattern accelerating across channels
   SEV-3: confusion, friction, missing-doc complaints
   SEV-4: preference feedback, feature requests, praise
   

3. 3.

   Run the triage prompt twice daily. Paste the window's items (or wire the same prompt into a Zapier AI step that drafts the brief for you):

   Copy

   You are triaging post-launch feedback for [FEATURE, one line].
   Time window: [e.g. Tue 5pm – Wed 9am]. Severity rubric:
   [PASTE RUBRIC]
   
   Items (each with ID and source link):
   [PASTE ITEMS]
   
   Produce the triage brief:
   1. HEADLINE: one sentence — is this window better, worse, or the
      same as the last one?
   2. PATTERNS: group items into issues. For each: severity per the
      rubric, count of independent sources, 1-2 verbatim quotes with
      item IDs, and affected segment if stated.
   3. ESCALATION CANDIDATES: only issues meeting SEV-1/SEV-2 per the
      rubric. State exactly which rubric line each one meets.
   4. WATCH LIST: below threshold now, but growing since last window.
   5. METRICS CROSS-CHECK: does the metrics snapshot corroborate or
      contradict the qualitative picture? Say which.
   
   Rules: never infer severity beyond the rubric; count only
   independent sources (10 retweets = 1 source + amplification);
   quotes verbatim with IDs; if evidence is thin, say so.
   

4. 4.

   Verify before anything escalates. For each escalation candidate: open the linked source items and read them — models over-weight vivid single complaints; confirm independence — one angry user across three channels is one source; reproduce or sanity-check against metrics — a "crash wave" that error dashboards don't show is probably one device model. Only then does it go to engineering, with your name on the call. A verified escalation reads:

   Copy

   SEV-2 (rubric: workflow degraded + accelerating): CSV export
   times out for large workspaces. 6 independent sources (4 tickets,
   2 reviews), first seen Tue 22:10, error dashboard corroborates
   (+40% export failures). → Posted to #launch-warroom, tagged @eng-lead.
   

5. 5.

   Close each window with the two-line log. Sev counts, top issue, decision taken. At hour 72, the logs concatenate into a launch health memo almost for free — and the watch list becomes the backlog triage input for pb-17's monthly run.

Make it yours

• PostHog Max as the metrics leg: ask it for the launch cohort's funnel and error events each window, then paste its answer into the metrics cross-check — inspecting its generated query per pb-27's habit.
• The war-room variant: for a high-stakes launch, run the pipeline into a dedicated Slack channel where the 9am and 5pm briefs post as threads and every escalation gets an emoji-vote confirm from a second human before paging.
• Tune the rubric per launch: a pricing change makes billing complaints SEV-2 by default; a mobile release lowers the crash-pattern threshold to 2 sources. Edit the rubric, keep the prompt.

Quality check

• Every escalation was human-verified at the sourceyou read the actual tickets, not the summary of them, before anyone got paged.
• Source counts are independentthe brief distinguishes 12 users from 1 user in 12 places; if it can't, fix the prompt's counting rule.
• Quotes carry item IDs that resolvespot-check two per brief; a quote you can't trace is a quote you can't act on.
• The metrics cross-check ran both waysqualitative noise without metric movement gets a watch, not an escalation; metric movement without complaints still gets investigated.
• False-alarm rate is trackedif more than one in five escalations dissolves on verification, tighten the rubric before the team stops believing the briefs.