How to triage bugs with Claude Code as a product manager

What is a product manager supposed to decide here?

Four things, and a cause is not among them. Is this real and reproducible. Which team owns the code path it comes from. How bad is it for users. Does it block the release. Triage stalls on the second question far more often than the third, which is why a stack trace read in two minutes beats a Slack thread that runs for two hours.

Claude Code is useful here for an unglamorous reason: it can read the repository and the trace at the same time. A file path in a stack trace means nothing on its own, and means a great deal once somebody has checked which part of the codebase it belongs to and who has been committing there.

Is it even a bug?

A large share of what arrives as a bug is a support question, a feature request in disguise, or a user doing something the product never claimed to do. Sorting that out first is cheap and almost nobody does it, which is why engineering queues fill with tickets that die three weeks later marked as working as intended.

The useful test is written, not technical: state what the user expected, state where the product promised that, and see whether the second sentence can be finished. If the promise exists in the interface copy, the documentation or the spec, it is a bug. If the promise only exists in the user's head, it is a design or communication problem, and it belongs in a different queue with a different owner.

An agent helps here by searching the repository and the product copy for the promise. Ask it to find every place the product tells a user what happens after they submit the form, then compare that wording to what the user described. Half the time the answer is that two screens say different things, which is a real defect with a much clearer fix than the one originally reported.

What can you actually read off a stack trace?

Four facts, and none of them require knowing the language. The first frame that points at your own code rather than a framework or vendor library. The file and directory that frame lives in, which usually maps to a team. The class of error: a missing value, a timeout, a permission refusal and a failed parse are four different conversations with four different owners. And whether it happened in the browser or on the server.

Ask for exactly that and nothing else. A request that works: read this stack trace against the repository, tell me which frame is in our own code, which directory it belongs to, what class of error it is, and whether this is client side or server side. Do not propose a cause and do not suggest a fix.

The last sentence is the important one, and it is worth keeping in the prompt permanently.

Why "do not propose a fix" belongs in every triage prompt

Because a fluent wrong theory costs more than no theory. Hand an engineer a diagnosis and they now have two jobs: disproving your explanation and finding the real one. Plausible-sounding causes are precisely what a language model generates well, and a PM has no way to tell a good one from a confident one.

Builders Camp's own practical challenge for Claude Code for Product Managers is built on exactly this asymmetry. A PM asks an agent to add a character counter. The counter works. While adding it, the agent also restructures the submission handler, and every feedback submission afterwards silently fails to save while still showing the user a success message. The diff looked clean. The reviewer skimmed it. The data was gone for a day before anyone noticed.

That is a story about reading generated code carefully, and it is also the best available argument for keeping a PM out of the diagnosis seat. The failure was invisible precisely because the explanation was plausible.

How do you set severity without guessing?

Ask about blast radius, not about the code. Four questions, in this order.

• How many users are hitting it, as a count from logs or support volume rather than an impression.
• Is data being lost or corrupted, which moves a bug up regardless of how few people hit it.
• Is there a workaround, and does support know it.
• Does the failure look like success, which is the question most triage skips.

The last one deserves its own beat. A loud error irritates users and gets reported within minutes. A silent failure that returns a success message produces no reports at all, and the damage accumulates until somebody checks the database. Put silent failures above loud ones by default and argue the exception, not the rule.

What goes in a ticket an engineer will not bounce back?

Reproduction steps, expected versus actual behaviour, environment and version, frequency, first seen, blast radius, and the raw trace or log lines. An agent is good at checking a messy support thread against that list and telling you what is missing. It is dangerous at filling the gaps, because a fabricated reproduction step sends someone chasing a path the user never took.

So use it as a checker. Paste the thread, ask which of those seven fields the thread supports and which are absent, and go get the absent ones from the person who reported it. That round trip takes ten minutes and saves the two days a vague ticket spends bouncing between support and engineering. The definition of done entry covers the related discipline on the other end of the same pipeline.

Where this workflow goes wrong

Stale context is the quiet one. An agent reading a checkout that is three weeks behind the deployed branch will confidently point at a file that has since been refactored, and nothing in the output signals the mismatch. Pull the branch that is actually in production before you ask, or say which commit you are on.

Line numbers drift the same way. A trace from production references the deployed build; the repository in front of you may not be that build. Treat the directory and the file as reliable signals and the line number as a hint.

The third one is social rather than technical. A PM who arrives with a routed, well-evidenced ticket is helping. A PM who arrives with an agent's opinion about someone else's code is doing something else, and the difference is obvious to the engineer receiving it. Working with GitHub Copilot or any other coding assistant raises the same boundary question from the other direction.

Where the delivery half of this lives

Triage is one ritual inside a delivery system, and the system is what decides whether bugs get fixed or accumulate. Project Management for Product covers that layer in 1 week, with 1 live session and 8 microlessons on planning, dependency management, risk and the kind of status communication that names blockers and decisions instead of listing activity. The Product Delivery Specialist Track bundles 6 bootcamps for people who own predictability rather than a single feature.

Claude Code for Product Managers stays on the tool: how to structure context so an agent can reason across a repository and your product documents, how to decompose work, and how to validate output before acting on it. Its practical challenge is rated intermediate and takes about 90 minutes.

Route three old bugs before you change anything

Take three tickets that sat unassigned for more than a week and run only the routing step on each: which frame is ours, which directory, what class of error, client or server. If two of the three were sitting in the wrong queue the whole time, the bottleneck in your triage was never severity or priority. It was that nobody could tell whose problem it was, and that is a two minute question you now have an answer for.

See the Claude Code for Product Managers bootcamp

For the delivery system around triage, Project Management for Product runs 1 week, and the Product Delivery Specialist Track covers planning, cadence and stakeholder communication across 6 bootcamps.