A monthly-cycling product backlog where every idea has a known stage, every scored item has a comparable score, every shipped item has a learning, and every month ends with honest data on what we said we'd ship vs. what we actually shipped.
A monthly-cycling product backlog where every idea has a known stage, every scored item has a comparable score, every shipped item has a learning, and every month ends with honest data on what we said we'd ship vs. what we actually shipped.
TimeOngoing, ~1 hr/week + 2 hr at month endDifficultybeginnerForProduct teams of 1-10 people running an ongoing roadmap.
How this works
Open it, hand it to your agent, walk the steps.
Paste this to your agent (Claude / Cursor / Codex)
You are the agent running on the "Product backlog grooming" template workspace. The user (PM) has connected you via MCP at your-org/product-backlog-grooming.
Your job: operate the monthly grooming cycle. Triage intake, draft Tuesday memos, flag stale items, draft month retro.
User-loop protocol:
- You propose. The user decides stage transitions. Never move a Backlog row from Idea to Qualified, Qualified to In progress, or In progress to Shipped/Killed without explicit user confirmation.
- When a new Backlog row lands (stage=Idea), search Backlog for duplicates by title + summary. If duplicate, comment on the new row "possible duplicate of [link]". If unique, comment with the 3 questions the Scoring rubric needs answered for Qualified (problem, evidence, target user).
- Every Tuesday morning (or "draft tuesday memo"), read Backlog rows changed since last Tuesday, flag rows where last_touched > 14 days and stage in (Qualified, In progress). Draft Tuesday memo doc, section "Week of $monday-date". Structure: (1) What moved, (2) Stale items + reason for staleness, (3) New ideas worth discussing, (4) Decisions needed at grooming.
- When the user marks a row Shipped, ask them via comment: "2-sentence learning?" When they reply, create a Ship log row: shipped_date, item, owner, impact_metric, learning.
- At month-end (or "month retro"), read Backlog + Ship log. Compute: items started this month, items shipped, items killed, items still in progress. Draft Month retro: said-vs-shipped (compared to last month's "we'll ship" list), themes, calibration data, proposals for next month.
- End of every working session, write 1-paragraph Status note: what you triaged, what's pending, what to pick up next.
Don't touch:
- Backlog.stage (always user's call).
- Scoring rubric doc (locked once team agrees).
- Ship log rows once created (they're historical).
First MCP tool calls:
1. list_surfaces(workspace_slug="product-backlog-grooming")
2. list_rows(workspace_slug="product-backlog-grooming", surface_slug="backlog")
3. get_doc(workspace_slug="product-backlog-grooming", surface_slug="scoring-rubric")
4. get_doc(workspace_slug="product-backlog-grooming", surface_slug="status")
Top to bottom. Each step has tasks, pointers, gotchas.
01 / 04
Lock the Scoring rubric
1 hr (the team conversation) + 15 min (lock the doc)
The Scoring rubric is the team's agreed formula for ranking ideas. Default: RICE (Reach × Impact × Confidence ÷ Effort). If your team uses a different formula (ICE, MoSCoW, weighted by strategic priority), replace the default doc. The rubric becomes locked: your intake agent uses it to ask the right questions on every new Idea, and the Tuesday memo uses it to highlight high-score / low-score items.
Tasks
Read the default RICE rubric in Scoring rubric doc
Decide if RICE is right for your team or replace with your formula
Define each variable: what counts as Reach (users? events?), what counts as Impact (revenue? activation rate?), Effort (eng days? sprints?)
Lock the doc by marking it Read-only after team sign-off
Gotchas
Don't pick a formula nobody understands. RICE is the default because it's transparent: any PM can re-derive a score from the row data.
If you change the rubric mid-cycle, every score becomes incomparable. Change at the fork boundary, not mid-month.
02 / 04
Seed Backlog with the live state
1-3 hr
Populate Backlog with the items the team is actively considering or working on right now. This is the calibration moment: stage every item correctly (Idea, Qualified, In progress, Shipped, Killed) and assign each a score using the rubric. Don't backfill ancient ideas; only what's live or recently shipped.
Tasks
List every item the team is actively considering (Idea), has scored (Qualified), or is shipping (In progress)
Pull the last 2 weeks of Linear shipped tickets into stage=Shipped
For each, fill: title, summary, owner, stage, score, last_touched
Skip items >3 months stale; if it didn't ship and isn't being discussed, archive it (don't recreate)
Gotchas
Don't dump every Slack-suggested idea in. The Backlog is for items someone has put non-trivial thought into. Slack-suggestions get filtered by the intake agent before they get a row.
Killed items should keep their kill_reason in the row notes. If you don't, the same idea comes back in 4 weeks.
03 / 04
Walk one Tuesday memo with your agent
1 hr (week 1 calibration)
Trigger a memo draft on a real Tuesday with a real week behind it. Read what your agent wrote. Push back on framing, missing items, wrong tone. The memo's value is in surfacing decisions that need to happen at the grooming meeting; if it reads like a status report, push back.
Tasks
Pick a Tuesday with a real week of Backlog changes behind it
Ask your agent: 'Draft this Tuesday's memo'
Read the draft; mark up: what should be a decision instead of a status update
Re-ask: 'Apply comments and replace the section'
Sign off; bring the memo to the grooming meeting
Gotchas
Don't let the memo become a backlog dump. The point is decisions, not inventory.
If everything is stale, the team is bottlenecked on capacity, not grooming. Surface that as a meta-observation.
Agent prompt for this step
Read Backlog rows where last_touched >= today - 7 days OR stage_changed_at >= today - 7 days.
Compute: rows that moved Idea → Qualified, Qualified → In progress, In progress → Shipped, In progress → Killed (count per transition).
Identify stale rows: stage in (Qualified, In progress) AND last_touched < today - 14 days.
Draft Tuesday memo section "Week of {monday_date}". Structure:
1. **What moved** (stage transitions, with row links)
2. **Stale** (rows that haven't moved in 14+ days, each with 1-line probable reason)
3. **New ideas worth discussing** (top 3 new Idea-stage rows by initial score)
4. **Decisions needed at grooming** (3-5 specific decisions: should we kill X? should we prioritize Y over Z?)
Keep it under 250 words. The PM reads this 30 min before grooming.
04 / 04
Run the month retro + fork
1 hr drafting + 1 hr meeting + 30 min forking
Last working day of the month, your agent drafts the month retro. The honest data here is said-vs-shipped: at the start of the month we said we'd ship X, Y, Z; we actually shipped Y, half of X, and a thing we didn't predict. Use this to calibrate the team's planning realism over time.
Tasks
Ask your agent: 'Draft Month retro'
Review the said-vs-shipped section honestly
Hold a 1-hr retro: what blocked items, what surprised us, what to change
Fork the workspace, name it 'Product backlog, $next-month'
Confirm the fork carried Backlog (excluding Shipped + Killed, which stay archived) + seeded Status with the retro
Gotchas
The said-vs-shipped delta will look bad in month 1. That's normal. Track the trend, not the absolute number.
Don't blame missed predictions on individual engineers. Reframe as scoping or dependency issues; that's what the data actually shows.
Agent prompt for this step
Read Backlog and Ship log for this month.
Compute:
- Items started in stage=Qualified at month start, count
- Items now in stage=Shipped this month, count
- Items now in stage=Killed this month, count
- Items still in stage=In progress at month end, count
- Said-vs-shipped: pull last month's retro "Next month proposed shipping" list, compare against actual Ship log this month
Draft Month retro doc:
1. **The month in numbers** (started / shipped / killed / carried over)
2. **Said-vs-shipped** (what we predicted vs. what landed; surface the delta with 1-line reasons)
3. **What got blocked** (items still In progress + reason)
4. **Patterns** (3 bullets: scope-creep, dependency-stalls, prioritization shifts)
5. **Proposed next month** (top 5 candidates for the next month's "we'll ship" list, marked "Proposal:")
Stop before "Decisions made". The PM and team make those at the retro meeting.
FAQ
Common questions on this template.
Why a workspace if we already have Linear?
Linear is for engineering execution: tickets, sprints, status. The Backlog is for the layer above: ideas that haven't been turned into tickets yet, killed-with-reason items so they don't come back, the said-vs-shipped retro Linear can't compute. The two systems work together: items move from Backlog (stage=In progress) into Linear when engineering picks them up, and the Tuesday memo references Linear ticket links.
Do all ideas go in here?
No, by design. The intake agent filters: it asks the submitter the 3 rubric questions before a row gets promoted from Idea to Qualified. If they don't answer, the row sits in Idea. After 30 days of no answer, the row gets archived. This filters out the half-formed Slack-thoughts without the PM having to be the bad cop.
What if our team uses ICE not RICE?
Replace the Scoring rubric doc with your formula. The intake agent reads whatever's in that doc to know what questions to ask, and the Tuesday memo reads whatever scores are in Backlog rows. The cycle works for any rubric as long as it's locked at the start of the month and not changed mid-cycle.
Can I split this by team or product line?
Yes. Either fork the workspace per team (each team has their own Backlog, Tuesday memo, retro) or add a `team` column to Backlog and filter by it. Fork-per-team is cleaner if teams have different rubrics; column-filter is cleaner if teams share rubric and you want a global view.
Open this template as a workspace.
We mint a fresh copy in your org with the steps as table rows, the pointers as a separate table, and the brief as a doc. Bring your agents, start checking off boxes.