Six Prompts for Reading an Engineering Roadmap
When you need to come up to speed quickly on a project, a team, or some piece of work, you can have Claude analyze the documents and ask…
Six Prompts for Reading an Engineering Roadmap
Long Beach
When you need to come up to speed quickly on a project, a team, or some piece of work, you can have Claude analyze the documents and ask questions first, then go back and read the source yourself to verify the analysis was correct. It gives you a starting point and generates a lot of clarifying questions you wouldn’t have thought to ask cold.
The prompts below are the six I run, in order, every time. By the time I’m done, I either understand the roadmap well enough to walk into the meeting, or I know which pieces are vague enough that I know what questions I need to ask to understand the roadmap and goals.
Here are the six.
1. Give me a detailed summary of the current timeline and milestones, dependencies, blockers, and risks. Be detailed, reference the doc, and cite sources
Roadmap docs bury the timeline. It’s split across phase headings, embedded in tables, mentioned in passing in commitment sections, and then contradicted by a Gantt chart on page 31.
What I want from this prompt is one thing: a single coherent timeline. Q1 milestones, Q2 milestones, dependencies between them, hard deadlines versus soft ones. I want it back as a list, in order, with dates.
What I’m actually checking for is whether the dates internally agree. When the doc says “GA in Q3” and the dependencies require something that doesn’t ship until late Q3, is that called out? Half the time, no. Claude surfaces the inconsistency without being asked, because it’s reading the whole thing at once, and I’m not.
I follow up with: “What’s missing or vague?” That’s the second half of the prompt. Real roadmaps are full of milestones with no owner, no acceptance criteria, and no verb. “Improve onboarding” is not a milestone. Claude will list these.
2. Rank the deliverables by ROI over effort
This is where the prompt earns its keep.
The way I phrase it: “Rank every deliverable in the roadmap by ROI over effort. Effort is engineering weeks. ROI is the impact on the goals stated in the doc. Build a matrix with effort on the X axis and ROI on the Y axis. Place each deliverable on the matrix and explain why.”
A few things happen.
First, Claude has to commit to estimates. It’s working from the doc, not from team knowledge, so the estimates are rough. That’s fine. I’m not using them for planning. I’m using the matrix as a conversation starter.
Second, you find out fast which deliverables the doc is selling and which it’s hiding. The big bet that takes up six pages of justification often lands in low-ROI/high-effort. The thing buried in an appendix turns out to be the highest-leverage item on the page. This happens often enough that I now expect it.
Third, you get a quadrant chart. I screenshot the description, sometimes ask Claude to render it as ASCII or as a small SVG, and I bring it to the next review. Not as a verdict. As a question: “Are we sure this is in the right quadrant?”
3. Walk me through the proposed architecture. Identify scaling bottlenecks
Most roadmaps include an architecture section. Usually, it’s a diagram with boxes and arrows and almost no annotation about what fails first.
The prompt: “Walk me through the proposed architecture. Identify scaling bottlenecks at 10x current load. Identify cost drivers and which ones grow nonlinearly. Where are the tradeoffs the doc isn’t naming, and what would the alternative look like?”
The 10x clause matters. It forces Claude past the diagram and into reasoning about what happens when traffic, data volume, or fanout actually grows. If the doc proposes a new write path through DynamoDB on-demand with a Lambda fanout, Claude will name both the cost cliff and the throttling profile. If the doc waves at “horizontal scaling” without specifying which component is the bottleneck, Claude will point that out.
“What tradeoffs is the doc not naming?” is the line I care about most. Every architecture choice has a cost that the author did not write down. Claude is good at surfacing the unnamed cost, because it has no stake in the proposal.
None of this is ground truth. It’s a list of questions I now know to ask. The distinction matters.
4. What can be done in parallel, given this engineering team
This one assumes you’ve given Claude two things: the roadmap and a description of the team. Roles, headcount, current ownership areas, anything you know about how the team is organized.
The prompt: “Given the team described, identify what work can run in parallel versus what has hard sequential dependencies. Where are we constrained by people rather than by technical dependencies? Where could we add a person and shorten the timeline, and where would adding people make it slower?”
The last clause is the one that catches managers off guard. The instinct when you see a long timeline is to ask where to add headcount. The harder question is where adding headcount would make things worse. Onboarding cost, communication overhead, contention on shared interfaces, and code review bandwidth. Claude will name these if you ask.
The output is usually a small dependency graph and three or four “if you only had one more engineer, put them here” candidates. I don’t take any of it as a plan. I take it as a check on the schedule the doc is proposing. If Claude says half the work in Q2 can run in parallel with Q1, but the doc says it's strictly sequential, that’s a question for the next review.
5. What’s already been built that we can leverage
The prompt: “Research existing libraries and recent work that overlaps with the deliverables in this roadmap. For each match, describe what’s reusable as-is, what we’d have to build on top, and what it would save in time or cost.”
This is the prompt that catches “we should build it ourselves” the most often. Engineering teams write proposals against a blank page. The doc describes the system as if nothing like it already exists. Sometimes that’s accurate. More often the comparison just wasn’t in the doc.
What I want is the comparison the doc skipped. If the roadmap proposes building a job scheduler from scratch, I want a list of the schedulers that already exist and what each one wouldn’t do. If it proposes a custom feature flag system, I want the off-the-shelf options and the specific reason each one fails for our case. The answer might still be “build it.” Now the choice is documented instead of assumed.
This prompt works best with internal web search turned on. Without it, Claude is reasoning from training data and can miss the project that shipped six months ago and changed the calculus. Turn it on, point at the deliverable, and ask what’s been built in the last twelve months that overlaps.
The output I bring to the review is rarely “use this off-the-shelf thing.” It’s usually a question: did the doc consider any of these, and if not, why not? That tends to be enough to push the team to do the comparison they skipped.
6. What parts of this can be developed with AI
The prompt: “Look at every deliverable in the roadmap. Identify which ones could be partially or fully built using AI coding tools or coding agents today. For each candidate, describe what the AI does well, where a human still has to drive, and roughly how much of the engineering time you’d expect it to absorb.”
This is the prompt that has changed the most over the past year. The boundary keeps moving. Two quarters ago, the answer was mostly scaffolding and tests. Now it includes migration scripts, glue code between services, internal admin tools, documentation passes, schema, and IaC generation, dashboards built off existing telemetry. The list will keep growing.
What I’m looking for is not “replace the engineer.” I’m looking for the deliverables where the doc has assumed a six-week build that’s actually a two-week build with the right tooling. Or the deliverables where the team plans to write something custom because they didn’t notice it’s a job a coding agent does well already.
The trap is letting the answer turn into a list of vague “AI-assisted” claims. I push back. If Claude can’t name the file, the interface, the test surface, the deliverable isn’t actually a candidate yet.
Output goes in two buckets. Bucket one: use AI to compress this. Bucket two: this looked AI-assistable and isn’t, and here’s why. The second bucket is the more useful one to bring to the review, because it pushes back on the optimistic version of the same prompt the team has probably already run themselves.
Limits
This does not replace reading the doc. I still read the doc. The order changed. Claude does a structured pass first, then I read with a list of things to verify.
Talking to the team still matters too. Claude doesn’t know that the senior engineer on Service B is about to go on leave, or that the dependency on the platform team is a fiction because they’ve quietly stopped supporting that interface. Those facts come from people. The roadmap doc rarely captures them. Claude can’t either.
What you do get: you walk into the review with the matrix already in your head. The timeline, the high-ROI candidates, the architectural questions worth asking.
A note on what to paste
If your roadmap is internal, sanitize it before pasting it into a public model, or use whatever enterprise tooling your company has set up. I work in security. For me this is not optional. The six prompts work just as well on a sanitized version. You’re asking structural questions, not retrieving secrets.
The whole workflow depends on having the doc, the team, and the goals in one place while you ask questions you’d otherwise ask in four different meetings spread across two weeks. That’s the actual trick. The prompts are scaffolding for that, nothing more.
By Joshua McDonald on April 30, 2026.
Exported from Medium on August 26, 2026.
Reader discussion