PM Runbook

Ask first

• Which calls count? (default any call where the customer described a problem)
• Where do your notes live? (a notes app, a document, or a recording that has been written up)
• What do you hand the brief to? (default a designer or a prototype tool)

Needs

• Your notes or a written-up recording of each call
• A place to save the brief
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Every hour on weekdays, find calls that ended in the last two hours and have notes. Keep a list of the items already handled (by their address or id) and skip any that are on it, so the same item never produces a second brief, comment or draft.
2. Pull out the problem as the customer said it, with one exact quote.
3. Name who has it, and write three things a first version must do and what to leave out.
4. Keep it to one page. If the notes describe no problem, say so and write nothing else.

Check

• Run it on a call you remember; the quote appears in your notes word for word
• Confirm the brief names something to leave out
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on an hourly weekday schedule, a one-page brief in my docs

Ask first

• Where is your roadmap and your sprint board? (a spreadsheet, a task tool, a document)
• How big is a sprint, and what is the team's usual capacity in days?
• Where do item sizes come from? (default the size field on each card; if a card has none, ask, and treat it as unsized rather than guessing)
• Who must approve a change? (default you)

Needs

• Read access to the roadmap and the board
• Permission to propose only, never to move a card without a yes
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Every hour, compare the roadmap order to the last saved copy.
2. If the order changed, list the new top items and what is in the sprint now.
3. Propose what to pull in and what to push out so the total stays within capacity, with each item's size.
4. Send it as a message. Move nothing without a reply of yes.

Check

• Change the order of two items in a test copy; confirm the proposal appears with sizes that add up
• Confirm no card moved without a yes
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on an hourly schedule, a proposal as a message

Ask first

• Where do your specs live? (a document tool, a repository)
• How do you mark one ready? (a label, a status)
• What have engineers asked before? (default read from comments on your last five specs)

Needs

• Read access to the specs and permission to comment, never to edit
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Every hour, find specs newly marked ready. Keep a list of the items already handled (by their address or id) and skip any that are on it, so the same item never produces a second brief, comment or draft.
2. Read it for undefined terms, metrics with no target, cases not covered, and anything contradicting an earlier spec.
3. Add the questions engineers asked on your last five specs that this one does not answer.
4. Leave the list as a comment. Change nothing in the spec.

Check

• Run it on an old spec you know was unclear; the gap you remember appears
• Confirm nothing in the spec was edited
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on an hourly schedule, a comment on each ready spec

Ask first

• Which products do you depend on, and where does each publish its release notes? (a link per product; a company blog, a docs page or a GitHub repo all work)
• What should the note flag? (default anything that changes your workflows, triggers or automation)
• Where should it reach you? (default a push to your phone)

Needs

• A list file with one line per product: name, link, and the last version or date you have seen. The last part is filled in for you after the first check
• An assistant that can run daily, read a web page and keep that saved value
• For a page that loads its content with JavaScript: a browser you are signed in to, read as text. For a GitHub repo: its release feed, which needs no browser

Build

1. Each day, for every line on the list, read the page and find the newest entry. Work out whether anything is newer than the saved value.
2. On the first check of a product with no saved value, record the newest entry as the baseline and say nothing.
3. If something is newer, write at most six short lines on what changed, then one line starting "Affects you:" on the things you named. Send it only to yourself, and move the saved value forward only after it was sent.
4. If nothing is newer, send nothing.
5. If a page cannot be read three days in a row, tell the owner once. If its layout changes so no entry can be found, say so once and stop.

Check

• Put two products on the list with different layouts (one with version numbers, one with dates) and a saved value two releases back for one; run once with sending off and confirm the summary and the Affects you line
• Run again with the real saved values and confirm it says nothing

In my version

• A shell script on a daily schedule, 8am Pacific, summary by claude -p, push to my phone; my list holds several products

Ask first

• Which accounts may it read? (default your calendar, mail and texts)
• What counts as an outside meeting? (default timed, not declined, not a family or holiday entry, with an outside person or a video link)
• When should the two cards arrive? (default Sunday evening and Monday morning)
• Where should they land? (default a page you open daily; an email to you if none)
• Do you keep a task list and a fitness app? (default no; those sections are left out)
• How long is "gone quiet"? (default 90 days)

Needs

• Calendar for the week just ended and the week ahead.
• Mail and texts for the same weeks, to find meetings agreed but never booked. Connecting: "It reads for dates people agreed on; it never writes to anyone."
• Optional: a task list for overdue items, a fitness app for training load.
• A page that holds cards, keyed by week, and an archive with one row per week.
• If your assistant can only chat: paste next week's calendar and ask for clashes; paste last week's and ask for the counts.

Build

1. Read (Monday): the week just ended. Count outside meetings (the test above), people spoken to for the first time, messages sent per channel, and overdue tasks, each beside the figure for the week before.
2. Decide (Monday): add people who warmed and who went quiet for 90 days or more, work built, training load if available, and open loops split into owed by the person and owed to them. One sentence on the shape of the week, such as which days were heaviest.
3. Read (Sunday): the week ahead from the calendar, plus mail and texts from the last 30 days.
4. Decide (Sunday): overlaps; back-to-back runs with no travel gap; meetings agreed in mail or texts that are not in the calendar. Keep: "Thursday 3pm works, see you then" with no event. Drop: "let's find a time soon". Quote the sentence the date was read from.
5. Deliver: one card per week, keyed by the week's Monday, so a rebuild replaces the card and never brings back an item already ticked off. Fallback: an email to the person only. Nothing goes to anyone else.
6. Memory: the archive page, one row per week, and the ticked items. Two model calls a week.

Check

• Rebuild a past week with delivery off and compare the counts with your own calendar; each not-booked item quotes the message it came from.
• Run it twice: one card per week.
• Quiet run: a week with no clashes and nothing unbooked gives a Sunday card that says so; the Monday card always has counts.

In my version

• Q, my assistant, Sunday 8pm and Monday 6am Pacific, reading Google Calendar, Gmail and iMessage, with Asana for overdue tasks and Mettle, my training app, for load. Cards on Q's home screen; archive page one row per week. The Sunday card gives one line per day and the shape of the week.

Ask first

• Which companies or products should it listen for? Give a name and, if the name is a common word, a few phrases that show a post is about them and a few that mean something else. (Several is fine.)
• Which sites for each? (default Hacker News, plus Reddit if the company has a community there, plus any review pages you name)
• Where should it reach you? (default a message from your assistant, only when something is new)

Needs

• A list file with one block per company. Adding a company is adding a block; removing one is deleting it. A broken file must be reported, never replaced by a default
• An assistant that can run on a schedule and keep a small store of what it has already shown you
• For sites with no open API: a browser you are signed in to, read as text. If a page shows a login wall or a challenge, stop and say so. Never work around one

Build

1. Each week, for every company on the list, fetch what is new from each of its sites. Hacker News has an open search API. Reddit is slow and gives little, so keep its queries few.
2. Keep only text that is about the right company. Drop job ads and other meanings of the name.
3. Store each item once with its link and date. Never report one twice.
4. Sort each into confusion, complaint, praise, comparison, price or news, with one plain sentence in your own words. The link comes from the page, never from the model.
5. If nothing is new, send nothing. If a site could not be read, say which one and try again later the same day, so a closed browser delays the report and does not lose it.

Check

• Run it once now over a past week with sending off; every line has a company, a site, a date and a link
• Add a second, unrelated company and confirm its posts are kept apart and the first company is not mixed in
• A quiet week sends no message

In my version

• Claude Code on a schedule: every hour on Mondays from 7:30am Pacific until the sources read, G2 and Glassdoor read in my own browser, results to a card and a text

Ask first

• Which of these do you have? Pick any: your notes from calls, the messages customers send you, a support inbox or help desk. (default the ones you have, from the last seven days)
• How can I tell a customer's message from other mail? A folder, a label or a list of their email domains works. (default anyone outside your own company)
• Where should it land? (default a page in your notes)

Needs

• Read access to the sources
• A running list of themes so a theme keeps the same name week to week
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Every Friday afternoon, collect every customer message from the last seven days.
2. Group them into themes. Reuse last week's names where the theme is the same.
3. For each theme: a count of messages that support it with the customers listed beside it, one real quote with its source, and a label. New means it was not in last week's list; growing means more messages than last week; fading means fewer.
4. Put the strongest three at the top, ranked by messages then by number of customers. Never invent a quote. If a customer's exact words are not in your notes, mark that line as paraphrase.
5. Save the theme list for next week.

Check

• Run it on last week; every quote matches a real message
• Confirm a theme from last week keeps the same name
• Confirm a paraphrase is never shown as a quote
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a Friday afternoon schedule, a page in my notes and a link in my weekly update

Ask first

• Which metrics do you own? (default the five you look at most)
• What counts as unusual? (default beyond 15% of the four-week average)
• Where do the numbers live and what changed log should it read? (a sheet, an analytics tool; a launch or campaign calendar)

Needs

• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file
• Read access to the numbers, and a record of what shipped or ran each day
• If your assistant cannot read one of these, paste it into the chat when it asks. A thinner version still works

Build

1. Each Monday, pull the last week and the four-week average for each metric.
2. Flag any beyond the limit. For each, look at what else changed that week and name the most likely cause, marking it a guess.
3. For each likely cause you guessed, write one line saying what would show the guess was wrong, and by when, so the guess can be checked later. Do this only for a metric beyond the limit, never on a quiet week.
4. End with one thing to check. If nothing moved, say so in one line.

Check

• Run it on a past week where you know why a number moved; the likely cause matches
• Confirm a guess is labelled as a guess
• Say whether the writing step ran for real or on sample text. Check that every quote and link on the page matches its source, and drop any that does not

In my version

• Claude Code on a Monday schedule, a note in my docs and a message

Ask first

• Where do customers ask for things? (calls, tickets, email, a feedback form)
• Where is the roadmap? (a document, a task tool)
• How many requests make something worth raising? (default five customers in six weeks)

Needs

• Read access to the feedback sources and the roadmap, or paste both in
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each Monday, collect every request made in the last six weeks and group the same ask under one name.
2. For each group, count the distinct customers and note the latest date.
3. Check each against the roadmap. Keep those with no matching item, or a matching item with no owner.
4. Rank by customers, then recency. Show the top three with who asked and when, and suggest which belong on the agenda.

Check

• Run it over a past quarter; the top ask is one you remember hearing repeatedly
• Confirm an ask already on the roadmap with an owner is not listed
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a Monday schedule, a page in my docs and a message

Ask first

• Which launches should it check? (default anything on your launch calendar with a name and a date)
• What counts as using the feature? (default doing the feature's main action at least once)
• What counts as coming back? (default any session in the 30 days after first use; the check runs at day 30 so the window is complete)
• Where do the numbers live? (a product analytics tool, a database, or a spreadsheet export)

Needs

• Read access to your analytics, or a spreadsheet export you paste in. If your assistant cannot read it, paste it when asked
• A launch calendar with names and dates
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Thirty days after a launch date, count the people who used the feature and the people who did not, and how many of each came back.
2. Compare the two. Also compare against people who were already heavy users before the launch, because they would have come back anyway.
3. Write one page: the two groups with their sizes, the gap, the fairer comparison, and one plain sentence on how far to trust it.
4. If either group is under 100 people, say the result is too small to read and stop.

Check

• Run it on a launch from three months ago whose result you already know; the numbers match your dashboard
• Say whether the writing step ran for real or on sample numbers. Check that every figure on the page matches its source

In my version

• Claude Code on a schedule, a page in my docs 30 days after each launch

Ask first

• What is it for? (a one-page brief, a full document, or a ticket)
• Which headings does your team use? (default problem, goal, in and out, open questions, success)

Needs

• Nothing connected. You paste the notes into the chat
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Read everything pasted. Separate what people said from what you can infer.
2. Write each heading. Quote the source for each claim and mark anything you inferred.
3. List every open question you hit instead of guessing an answer.
4. Keep it to two pages.

Check

• Paste a messy set of notes you know well; every statement is in the notes or marked as inferred
• Confirm the open questions are real gaps
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude in a chat window, on demand