The roadmap scenario test
A three-lens prompt drill I run before any roadmap review, so the meeting is not the first time the plan gets stress-tested.
Last week I wrote about experimentation. This week, the drill I run before any roadmap review, because most reviews I have sat through do not fail on the deck. They fail because nobody stress-tested the plan before it was defended.
Roadmap reviews are theater when they are done well and interrogation when they are done badly. Neither is where the roadmap actually gets better. The roadmap gets better in the quiet hour before, when somebody with no ego and no political stake in the outcome asks the three questions the room will not ask with the same honesty. That somebody used to be a peer you trusted. Now it can be three prompts.
I own roadmap decisions for employees, customers, partners, and technical communities. The plan touches labs, assessments, content workflows, and the tooling that keeps a large catalog alive. Before any serious review, I now feed the roadmap into three separate model sessions with three different system prompts. Each one plays an adversarial lens. Together they give me the pre-mortem the room will not.
Here is the drill.
Why three lenses, not ten
You could invent ten personas. Do not. Every lens you add dilutes the signal and burns your own reading time. Three lenses is the smallest number that covers the three trade-offs a roadmap has to survive.
Cost defensibility. Is every eng-month on this plan buying something a rational finance leader would fund again next year.
Customer value. Does the plan solve the problem the person actually using the platform would name if you asked them.
Competitive exposure. Does the plan leave a door open that a serious competitor would walk through.
If a roadmap item cannot survive at least two of the three, it is a candidate to cut, defer, or reshape. If it fails all three, you are keeping it for internal reasons that deserve to be named out loud.
Lens 1, the skeptical CFO
The point is not to model a real CFO. The point is to force yourself to answer, in plain language, why the money is well spent.
The system prompt I use:
You are a skeptical CFO reviewing a product roadmap. You are not
hostile, but you have seen too many plans that spent engineering
months on work that did not defensibly move revenue, retention,
cost, or risk within four quarters. Your job in this review is:
1. For each roadmap item, ask the single sharpest question you
would ask if you had to defend this line in the annual
planning cycle.
2. Flag any item where the mechanism from work to business
outcome is more than two steps long, or depends on an
assumption the PM has not stated.
3. Group items into: clear defensible spend, defensible with
caveats, and unclear. Do not soften “unclear.”
4. Ignore emotional framing. If a phrase reads like advocacy
(”critical,” “must-have,” “foundational”), replace it with
a neutral description of what the work does.
Output: the three groups above, plus your one sharpest question
per item, plus a short section titled “the two items I would
cut first and why.”What this catches, in my experience, is the item that survived last planning because everybody was tired, the item that describes a capability instead of an outcome, and the “foundational work” that never traces back to a metric anyone tracks. It also catches the two items I quietly know are weak but was hoping the room would let slide.
What it misses: political context. A CFO model does not know that item four exists because a partner made a commitment two quarters ago, or that item seven is the price of keeping a senior engineer engaged. That context is your job to add on top.
Lens 2, the frustrated customer
Not any customer. The one who is on the platform right now, using the thing, and who would give you the ninety-second version of what is broken if you cornered them at a conference.
The system prompt:
You are a senior technical practitioner who uses this platform
weekly. You are frustrated but constructive. You do not care
about the roadmap themes or the strategic narrative. You care
about the moments that make you sigh, close the tab, or send
a Teams message asking somebody else to fix it.
Your job:
1. Read the roadmap. For each item, say in one sentence what
friction, failure, or unmet need it resolves for a user
like you. If it does not resolve one, say so plainly.
2. Then, ignore the roadmap and list the five things about
the platform that make you sigh, in order of severity.
3. Cross-reference: which of your five sighs does the
roadmap address, and which does it not.
4. Do not be polite about the gap. Do not invent problems
that are not in the reference material provided.
Output: the per-item resolution, the five-sigh list, and the
gap analysis. End with the one thing you would ship first if
you were the PM.What this catches: the plan that is full of interesting projects and empty of the boring five things that would make the platform noticeably less annoying. Every roadmap I have ever run has at least one of these. The lens does not invent the sighs. It surfaces the sighs implicit in the material you gave it (support themes, feedback tickets, past release notes if you paste them in).
What it misses: the customer model does not know what is technically feasible in the window. Some of the five sighs are hard problems that will take three quarters, and the roadmap is honest about that. Read the gap as a prompt, not a verdict.
Lens 3, the hostile competitor
The point is not paranoia. The point is to look at your own plan the way someone who wanted to displace you would.
The system prompt:
You are a product strategist at a serious competitor. You do
not have unlimited resources, you have to pick your fights.
You just got a copy of this roadmap. You have thirty minutes
to write an internal memo for your team titled “where they
are leaving the door open.”
Your job:
1. Identify the two or three areas where the roadmap is
silent, thin, or scheduled far enough out that a fast
mover could ship first.
2. Identify any strategic assumption in the plan that, if
wrong, breaks the plan. Name the assumption in one
sentence.
3. Pick the one wedge you would build if you wanted to peel
off their most valuable segment in the next twelve months,
based only on what this roadmap shows and does not show.
4. Be specific. “They are weak on AI” is not useful. Name
the surface, the workflow, or the segment.
Output: the three-point memo above. End with the single
sentence you would put at the top of the memo for your CEO.What this catches: the silences. Roadmap conversations spend most of their time on what is in the plan. This lens spends all of its time on what is not, and where the silence is dangerous. The best output I have gotten from this prompt was a three-sentence description of a workflow we had deprioritized because it was hard, which a competitor could ship as a hero feature.
What it misses: the model has no idea what is on your competitors’ actual roadmaps. It is not competitive intelligence. It is a pre-mortem for the plan you are about to defend, run by someone assigned to poke it.
What the three lenses do together
Any one of them can be dismissed. All three at once, on the same roadmap, in the same afternoon, is uncomfortable in a way that is useful.
I read the three outputs in order (CFO, customer, competitor), highlight anything two of them flag independently, and mark those items for hard conversation. Convergence is the signal. If the CFO thinks item four is weak, the customer does not see themselves in it, and the competitor sees it as a place they would attack, the item does not go into the review as-is. It either gets reshaped, deferred, or cut, and the cut gets named honestly in the room.
The residual is what you defend. The items every lens can articulate a reason for. Those are the items you can walk into the review already knowing how you will answer the hardest question in the room, because a version of it has already been asked.
Where this workflow is wrong
Three honest limits, so you do not over-trust the output.
It cannot see culture. The plan carries commitments to specific people, teams, and partners that a model cannot read. Item seven exists because a senior engineer wants to build it and losing them costs more than the item saves. That is a real reason. Just make sure it is the reason, and that you have named it.
It cannot see sequence dependencies. A model reading a roadmap as a flat list can call item three low-value on its own without seeing that item three unblocks item nine, which is the biggest bet on the plan. Bring your own dependency map to the reading.
It can invent confidence. The output looks decisive. The confidence is a stylistic artifact of the model, not evidence. Treat every “the two items I would cut first” as a prompt for a real conversation, not a verdict.
Nothing in this workflow makes the roadmap smarter on its own. What it does is force you to answer three questions before the room does. It surfaces the items you were hoping nobody would ask about. It names the silences. It gives you a chance to reshape the plan while you can still reshape it cheaply, in a text file, at a desk, instead of expensively, in a review, in front of an audience.
The chart is not the decision. The plan is not the decision. The decision is what you can still defend after somebody who is not on the team, does not owe you anything, and does not care about your quarter, has poked at it. That used to require three people. Now it takes three prompts and a quiet hour.
See you next Tuesday (sorry, busy day yesterday and I'm late).
Luiz
If you run this on your own roadmap this week, I want to hear which of the three lenses was the most uncomfortable, and what it flagged. Reply or drop it in the comments.
Views are my own and do not represent Microsoft.