Skip to content

Product Metrics Weekly Narrative

Example prompt: "Every Monday morning, look at last week's numbers in our metrics Google Sheet alongside the pull requests we merged on GitHub, and post a short narrative to #product on Slack tying what changed in the numbers to what we shipped, so the team can read the story behind the week."

The Problem

Most product teams have a metrics dashboard and a deployment log; very few have anyone joining them up in plain English on a regular cadence. So engineers see the dashboard wobble and assume the wobble is unrelated to their PR, the PM mentally tracks both but does not write anything down, and the team's read on whether shipped work is moving the numbers ends up being whoever is loudest in standup. A weekly five-minute narrative — "signups up 4%, activation flat, here's what we shipped" — would be the cheapest and most-read product writing the team produces, and yet on the Monday morning it needs to happen the PM is in a planning meeting.

How GloriaMundo Solves It

We build a workflow that runs every Monday morning. An integration step reads last week's row and the prior week's row from the metrics Google Sheet — signups, activation rate, weekly active accounts, and any other top-level numbers the team tracks. A second integration step lists pull requests merged to the main branch on GitHub between the previous Monday and yesterday, filtered to those affecting user-visible code. A code step computes week-on-week deltas for each metric and groups the PRs by area. An LLM step writes a 200-300 word narrative in the team's voice — a headline sentence on direction of travel, two or three paragraphs linking specific metric movements to plausible shipped work (without overclaiming causation), and one or two open questions for the team to answer in standup. An integration step posts the narrative to the #product Slack channel, and a second integration step appends it as a dated section in the "Weekly Product Narratives" Notion page so the history is browseable. Glass Box preview shows the narrative and the underlying numbers and PRs before anything is posted.

Example Workflow Steps

  1. Trigger (scheduled): Runs every Monday at 09:00.
  2. Step 1 (integration): Read last week's row and the prior week's row from the metrics Google Sheet.
  3. Step 2 (integration): List GitHub pull requests merged to main in the last seven days with the "user-facing" label.
  4. Step 3 (code): Compute week-on-week deltas for each metric and group the PRs by feature area.
  5. Step 4 (LLM): Write a 200-300 word narrative — headline, paragraphs linking metric movements to shipped work without overclaiming causation, and one or two open questions for standup.
  6. Step 5 (integration): Post the narrative to #product in Slack.
  7. Step 6 (integration): Append the same narrative as a dated section in the "Weekly Product Narratives" Notion page.

Integrations Used

  • Google Sheets — source of the team's top-level product metrics
  • GitHub — source of the week's user-visible deployments
  • Slack — where the narrative reaches the team
  • Notion — week-by-week archive of narratives for trend review

Who This Is For

Product managers at companies where a metrics dashboard exists but nobody writes regularly about what it shows. Especially useful in teams of 5-30 engineers shipping multiple PRs a day, where the gap between "what we did" and "what moved" is wide enough to be informative but narrow enough that nobody bothers to close it.

Time & Cost Saved

Reading the metrics, the deploy log, and writing 250 words on the connection between them takes a PM 30-60 minutes on a Monday, which is why the narrative is the first thing dropped when the calendar fills. The workflow makes the narrative routine and the PM's time goes into the conversations it triggers, not the assembly.