Claude Code for Product Managers: A Board-First Workflow

Claude Code is useful to a product manager who never writes code, because most product work is reading, sorting and drafting, and Claude Code does all three against real files. The workflow that holds up is board-first: the backlog lives on a shared board, not in your chats; you write cards an assistant can pick up; and you use Claude Code for four jobs around them: drafting specs, analysing feedback files, building throwaway prototypes, and reading what the engineers’ assistants did. The board is where all four end up, so the work is still there when the session is gone.

This is the individual PM’s routine. If you are rolling assistants out across a team, how to use AI agents in project management is the step-by-step plan for that. If you want a subagent that triages the board for you, see building a project manager subagent in Claude Code.

Why the board comes first

A Claude Code session is a conversation on your machine. It ends, it compacts, and nobody else can read it. A backlog is the opposite: a shared list that engineers, their assistants and you all work from for months. If the backlog lives in your sessions, every insight you produce with Claude stays with you. If it lives on the board, every session adds to something the team already reads.

So the rule is simple. Claude Code produces drafts, analyses and prototypes as files; the conclusions go onto cards. A spec becomes a card’s problem statement plus a link to the file. A week of feedback becomes three new cards and comments on five old ones. Nothing important lives only in a transcript.

Setting up, without writing code

Claude Code runs↗ (opens in a new tab) in a terminal, in IDE extensions, in the browser, and in the Claude desktop app, where it sits under the Code tab and needs no separate install. Pick whichever you are comfortable in. Then make a folder for product work and point Claude Code at it:

product/
  CLAUDE.md        how you want Claude to work here
  feedback/        exports: survey CSVs, support tickets, interview notes
  specs/           one Markdown file per spec
  prototypes/      throwaway HTML, never shipped

Connect your board. For fenbs it is one command in a terminal, then /mcp inside Claude Code and a browser sign-in↗ (opens in a new tab); no key is pasted anywhere. Tick read and comment on the approval screen to start with. That is enough for everything below except filing new cards; add the scope to add and change tasks once you are happy with what it proposes.

claude mcp add --transport http fenbs https://fenbs.ai/api/mcp

Then write CLAUDE.md. It is read at the start of every session↗ (opens in a new tab), so it is where you say how you work: “Specs go in specs/, one file each. Never put customer names or email addresses in a card or a comment. Search the board before suggesting a new card. Do not move cards between lanes.”

Write cards an assistant can pick up

Your most valuable output is not a spec; it is a card an engineer’s assistant can start on without asking you anything. On fenbs every task has a kind (feature, enhancement or bug), a priority from 1 to 10, and two boxes. The Problem box is yours: what is wrong or missing, who it affects, why it matters, and how anyone will know it is fixed. The Plan box is for how it will be done, and it is usually the engineer’s, or their assistant’s, to fill in.

• One outcome per card. “Improve onboarding” is a theme; “New users can skip the team invite step” is a card.
• Say where. The screen, the email, the step in the flow. An assistant cannot see the meeting you had.
• Say how it will be checked. “A new account reaches the board in under three screens” is a check; “smoother onboarding” is not.
• Leave the Plan box empty unless you actually know the approach. A PM’s guess in the plan reads as a decision.

Claude Code is good at tightening cards. Ask it to read the To Do lane and, for each card, comment the one question that would make it ready. You answer the questions; it does not rewrite your problem statements. A kanban board for Claude Code goes further into what a finishable card says.

Draft specs from what already exists

A spec drafted from a blank page is generic. One drafted from the related cards, their comments and the last round of feedback is specific. Start in plan mode↗ (opens in a new tab) (press Shift+Tab until the status bar shows ⏸ plan mode on), so Claude reads and proposes an outline before it writes a file, then approve and let it write.

Search the board for cards about CSV export, and read their problems and comments.
Read feedback/2026-09-survey.csv for anything on exporting.
Draft specs/csv-export.md: the problem, who has it (with counts, no names),
what is in scope, what is out, open questions, and how we will know it worked.
Then comment on FET-031 with the file path and the three open questions.

The last line is the board-first part. The spec is a file you will edit; the card gets a pointer to it and the questions that block it, so engineers see them where they already look. Claude Code plan mode covers the approval step and how to turn a plan into cards.

Analyse feedback files

Claude Code reads text files, CSV exports, images and PDFs; longer PDFs are read in ranges of up to 20 pages↗ (opens in a new tab) at a time. That covers most of what feedback arrives as. Put the exports in feedback/, strip or replace customer names and email addresses first, and ask for the analysis in a shape you can check.

1. Ask for themes with counts and two short quotes each, and a list of rows it could not classify. Read those before anything else.
2. Ask it to match each theme against the board with fenbs_search. Themes with a card get a comment on that card: “12 more mentions in the September survey”.
3. Themes without a card become proposed cards: a kind, a one-line problem, a suggested priority. You approve the list; then it files them with fenbs_create_item. If a new card looks like an existing one, fenbs answers created: false with the likely matches instead of filing a duplicate.

Keep the evidence out of the board and the conclusions on it. The CSV stays in your folder; the card says how many people raised it and why it matters.

Prototype, then throw it away

A clickable prototype settles arguments a spec cannot. Ask Claude Code for a single HTML file in prototypes/ that you open in a browser: the three screens of the new flow, fake data, no back end. It takes minutes, and you can change it by describing what is wrong. The rule that keeps this healthy: a prototype is a question, not a delivery. Comment on the card with the file path and what the prototype is meant to test, and let the engineers decide how it gets built.

Read what the engineers’ assistants did

On a shared board, engineers’ assistants are working the same cards you wrote. You do not need their transcripts. The board’s History page lists every change with who made it, and a change made through a connected assistant reads as “Claude via” the person who connected it. Filter History to AI Assistants to see only their changes, or search it for a ref to see one card’s trail.

• Check that what reached Completed is what the problem asked for. The comment says what changed; compare it with your check.
• Look at Testing. Each task records how it was tested: Not tested, Tested, Partly tested, Failed, or Needs owner check. “Completed, not tested” is the question to ask before anything is announced.
• Needs owner check is often you. It marks what only a person can confirm, and a PM is frequently that person.
• Ask Claude Code to summarise the week: “Read the board. List what moved to Completed since Monday, grouped by feature, enhancement and bug, with anything not tested called out.” That is your status update, drafted.

What to leave alone

Do not have your assistant move cards between lanes on a team board; lanes are how engineers claim and finish work, and a PM’s assistant dragging cards around breaks that signal. Do not give it write access to the code repository if you only need it for product work. And keep personal and customer data out of prompts, cards and comments.