How to synthesise a roadmap with Claude Code, and where the agent must not decide

What is actually hard about roadmap synthesis?

Not the writing. The hard part is that the inputs arrive in different shapes from people with different incentives, and by the time they reach a planning document most of them have lost their provenance. Someone says enterprise customers need audit logs. Three weeks later that is a roadmap line item, and nobody can now say whether it came from two deals or twenty, or whether the two deals closed anyway.

That is the job an agent is genuinely good at: reading everything, producing one list, and keeping a pointer from each item back to whichever file argued for it. It is unglamorous, it is the part that gets skipped under time pressure, and doing it properly changes the quality of the meeting more than any framework does.

What goes into the folder before you start?

Everything that currently argues for something being built, as files with dates. The feedback themes from your last triage pass, the closed-lost reasons from sales, the support escalations, the engineering list of things that will break if untouched, last quarter's OKRs and their actual results, and whatever strategy document exists even if it is a year old.

The gaps in that folder are informative in themselves. If there is no strategy document, the synthesis will produce a candidate list with nothing to test it against, which is worth discovering now rather than in the review. If the only customer input is support tickets, the roadmap is about to be shaped entirely by the customers who complain, and naming that before you start is cheaper than discovering it afterwards.

What should the synthesis prompt ask for, and what should it refuse to ask for?

Ask for three artefacts: a deduplicated candidate list where each item names the files that argued for it, a tensions section listing where two inputs point in opposite directions, and a gaps section naming the questions none of the inputs answer.

Do not ask for a ranking. A model asked to prioritise will produce one, confidently, using weights nobody chose, and the result is far more dangerous than an obviously wrong order because it looks like analysis. Anthropic's guidance about giving an agent a way to verify its work is relevant here in the negative: there is no check a model can run that tells it whether your company should bet on retention or acquisition this quarter, so the stop condition is "looks done" and nothing more.

The tensions section is where the value concentrates. Sales pushing for enterprise controls while your support volume concentrates in first-week onboarding is not a scheduling conflict, it is a question about who the product is for, and it usually surfaces halfway through the quarter instead of at the start of planning.

What should a candidate item look like on the page?

One line per item, with four things attached: the problem it addresses, the files that argued for it, how many distinct sources those files represent, and the outcome it is supposed to move. An item that cannot fill the fourth field is not a roadmap candidate yet, it is a request, and keeping the two visually separate saves an argument later.

The source count is the field that does quiet work. Three separate inputs pointing at the same problem is a different object from one input mentioning it three times, and a list that shows only a total will merge those two into the same number. Ask for distinct sources rather than mentions, and the top of the candidate list rearranges itself more than you expect.

Keep the wording of each item as the problem, not the solution. "Customers cannot tell which invoice a charge belongs to" survives contact with a designer and an engineer who might both have a better idea than the one implied by "add invoice reference to charge list". This is the same discipline that makes a feedback theme useful, and it matters more on a roadmap, because a roadmap written in solutions has already closed off the cheapest options before anyone looked at them.

Where must the agent not decide?

Three places, and they are all the same place from different angles:

• Sequencing, because the order encodes what the company is betting on and who carries the risk if the bet is wrong.
• Trade-offs between segments, because choosing which customers to disappoint is a strategy decision that the inputs cannot resolve on their own.
• Anything involving a commitment already made to a customer or a board, because the files will not contain the context and the model has no way to know it is missing.

The general principle behind those three is the one Builders Camp's AI product curriculum applies to agent design: deciding how much rope to give a model, and when a human must approve, is a product choice rather than a technical one, and most failures trace to missing guardrails rather than weak models. A roadmap is a high-stakes action with a slow feedback loop, which is the worst possible combination for unattended judgement.

How do you turn the candidate list into a defensible sequence?

By making the weighting explicit and human. Take the candidate list, write down the two or three things the company is trying to move this cycle, and sort against those by hand. The agent can then do a second useful pass: check the sequence you produced against the inputs and tell you which candidate items your order implicitly deprioritised, and which of them had the strongest evidence behind them.

That inversion is the real trick. Instead of asking the model to decide, you ask it to argue against the decision you made, with the evidence it has. What comes back is either reassurance or the objection that was going to be raised in the review anyway, arriving early enough to do something about.

Builders Camp's Product Strategy bootcamp covers the layer this sits on: making strategic choices you can defend, translating bets into sequencing and milestones, and communicating strategy in a way that reduces debate rather than restarting it. It runs 2 weeks across 4 live sessions of 120 minutes, with a practical challenge and a graded quiz.

What does this look like on the second run?

Much cheaper, and more useful. The instruction file stays, the folder structure stays, and the rerun is mostly refreshing inputs. The interesting output stops being the candidate list and becomes the diff: which items appeared this cycle, which disappeared without anyone deciding to drop them, and which tension from last quarter is still unresolved.

That third one is the finding that tends to matter. A tension carried across two planning cycles without a decision is not an open question, it is a decision being made by default, and seeing it in writing twice is usually what forces it into the open.

The habit this depends on

All of this rests on reading an agent's output for what is not supported rather than for whether it reads well, which is a trainable skill and not an obvious one. Builders Camp's Claude Code for Product Managers bootcamp is built on that habit, in 1 week across 2 live sessions and 8 self-paced microlessons, with a microlesson on integrating the tool into discovery, roadmap planning and experimentation without replacing human judgement, and a practical challenge on catching the change an agent made while you were looking somewhere else.

See the Claude Code for Product Managers bootcamp

For attaching the sequence to outcomes rather than to a task list, How to Design OKRs covers objective crafting, key results and the cadence that keeps them alive. For the documentation side of the same workflow, see Notion for product managers, and for the wider toolkit, the best AI tools for product managers. The structure that makes a rerun cheap is covered in context architecture.