Personas in Roadmap Reviews: Using Them to Kill Features, Not Decorate Slides
In most roadmap reviews the persona slide appears early, gets nodded at, and is never mentioned again while the real argument happens over engineering cost and executive preference. That is a persona failing at its only job. In a review, a persona is not context. It is a filter: it should be able to kill a feature whose problem nobody can attach to a real user with real evidence.
The three questions every item should face
Whose problem is this, in persona terms, and which claim on that persona says so? How strong is that claim, observed evidence or workshop opinion? And what happens to this persona if we do nothing for another quarter? An item that cannot survive those three questions in five minutes is not ready for the roadmap, whatever its internal sponsor thinks.
Notice what the questions exclude. Market size, competitor movement, and strategic fit are real arguments, but they are different arguments. Letting them wear persona clothing, we built it because users need it, corrupts both. If the reason is competitive, say competitive, and let the persona testify only about users.
Using personas to sequence, not just to select
Roadmaps are mostly ordering decisions: everything on the list is arguably worth doing eventually. Personas help by showing which segment carries the quarter's risk. If churn interviews point at one persona's core workflow breaking, that persona's items go first, and the review should be able to say so in one sentence a customer would recognise.
They also expose fake breadth. A roadmap where every item claims to serve every persona serves none of them in particular, and usually means the items were written before the audience was considered. Force a primary persona per item. Secondary beneficiaries can be noted, but one name goes in the first column.
The kill list is the deliverable
A review that only adds and orders is unfinished. Each cycle, the persona pass should produce explicit kills: items dropped because the problem was a guess that research has since failed to confirm, items deferred because the affected persona's evidence points at a bigger problem upstream, items merged because two personas' requests described the same workflow in different words.
Record the kills with their reasons where the team can find them. Without a record, killed items return next quarter with a new sponsor and no memory, and the review relitigates them at full price. With a record, the answer is one line: killed in March, problem unconfirmed, reopen when the interviews say otherwise.
Keeping the review honest
Rotate who argues the persona's side. If the same researcher always defends the user, the room learns to treat it as a role to be waited out. Have the item's own sponsor state the persona case and its evidence rating before anyone else speaks. Sponsors who must say the weak parts out loud write better proposals next quarter.
End the persona pass with the research gaps the review exposed: which decisions leaned on guesses, and what will be done before the next review to settle them. A roadmap process that generates its own research agenda is one where personas compound in value instead of expiring on a shared drive.
Keep reading
Related guides on this site: Recruiting for Persona Interviews: Finding People Who Will Tell You the Truth Persona Adoption: Why Good Decks Get Ignored and How Teams Actually Use Them Practical answers about personalization.
Frequently asked questions
What should a persona contribute to a roadmap review?
A filter, not decoration. For each item: which persona has this problem, which persona claim evidences it and how strongly, and what happens to that persona if the item waits. Items that cannot answer should not pass on user grounds.
How do personas help order a roadmap, not just fill it?
By showing which segment carries the current risk, from churn, support, or sales evidence, so that segment's items sequence first. Requiring one primary persona per item also exposes proposals written for everyone, which usually means no one in particular.
Why record killed roadmap items?
Because unrecorded kills return. A short log, item, date, reason, and the condition for reopening, stops the team relitigating dead proposals every quarter and turns the kill list into a research agenda.
What if an item is justified strategically, not by users?
Say so plainly. Competitive or strategic items are legitimate, but dressing them as user needs corrupts the persona evidence for everything else. Keep the justification categories separate and let each item win on its real argument.