A public roadmap is a strange piece of marketing. It's published by product, maintained by product, and read by people who mostly aren't in a buying mood — existing customers checking whether their request is coming, and evaluators trying to figure out whether a missing feature is a dealbreaker.
Because it gets steady traffic, sooner or later someone suggests adding testimonials. That instinct is half right. Customer voice genuinely belongs on a roadmap. Testimonials, in the usual sense, mostly don't.
The difference is where they sit and what they claim.
Who reads a public roadmap
Three readers account for nearly all of it:
- Existing customers looking for a specific item. They arrive from a support reply, a community thread or a changelog link. They want to know status and, ideally, timing.
- Evaluators in a late-stage deal checking for a feature they need. Often they were sent the link by your own sales team, with a line like "it's on the roadmap."
- Prospects doing early research, trying to judge how active the product is and which direction it's going.
The first two groups read the roadmap as a set of commitments. That's the constraint everything else follows from: anything placed next to a roadmap item will be read as part of the commitment.
The rule: no quotes in "Planned" or "In progress"
Most public roadmaps use three or four columns — something like Under consideration, Planned, In progress, Shipped. Keep testimonials entirely out of the middle two.
A customer quote placed beside a planned item — "we can't wait for SSO support!" — does two damaging things. It implies the item is more certain than it is, because customers are now publicly waiting for it. And if the item slips or gets cut, the quote remains as a visible record of a disappointed customer, attributed by name or role.
For an evaluator in a deal, it's worse. They may treat a planned item with visible customer demand as effectively promised, and write that assumption into their internal business case. If it doesn't ship on their timeline, the trust damage lands on your sales team, not your roadmap.
Where quotes do belong: the "Shipped" column
The shipped column is the one place on a roadmap where a testimonial carries no risk and real persuasive weight. The item exists. A customer can speak to what it changed.
The most effective format is a short quote attached to the shipped item itself, from someone who asked for it:
"We requested bulk editing in January. It shipped in April, and it's taken our weekly cleanup from an afternoon to about twenty minutes." — Operations manager, 60-person agency
This quote is doing roadmap work, not sales work. It shows the full loop — request, build, result — which is the single most persuasive thing a roadmap can demonstrate: that customer requests actually turn into product. Every prospect reading the page learns that asking for something here is not a dead end.
Two practical notes:
- Keep it to one quote per shipped item, and only on items where you have a genuine one. Adding quotes to every shipped card turns the column into a testimonial wall.
- Collect it from the requester. The person who asked is the most credible voice and the most willing to give it. We cover the ask in how to collect a testimonial from a customer whose feature request you shipped.
The page-level slot: explaining how the roadmap works
Good public roadmaps have a short intro block explaining how items are prioritized and how customers can contribute. That's the second place customer voice fits — not about a feature, but about the process:
"I've submitted six requests over two years. Three shipped, two are planned, and for the one they turned down, they explained why. That's more than any other vendor we use." — Head of IT, regional healthcare group
This quote works because it includes a rejection. A process testimonial that claims every request was built is implausible, and on a roadmap page the reader can check the columns and see it isn't true.
Place this below the intro and above the columns. It's the only quote on the page that isn't attached to a specific item, and it sets expectations for everything the reader is about to see.
Using demand signals instead of quotes in upper columns
Customer voice still has a role in Under consideration and Planned — it just shouldn't be a quote.
Vote counts, request counts, or a neutral label like "requested by 40+ customers" communicate demand without attaching a named person to a promise. They also age gracefully: if the item gets cut, a vote count is simply history, while an attributed quote reads as a customer let down in public.
If you use vote counts, keep them honest. Don't hide low-count items that are actually planned, and don't inflate items you already intended to build. Readers who follow the roadmap over time notice when counts don't match what ships.
Where the rest of the proof should go
The testimonials someone wanted to put on the roadmap page usually have better homes:
Release notes. A quote about a newly shipped feature does its best work where the announcement lives, and it will be seen by more active users than the roadmap card. Placement specifics are in where to place testimonials on a changelog or release notes page.
Beta and early access pages. Quotes about what it's like to use features before they're finished belong with the program that recruits early users — see where to place testimonials on a beta or early access page.
Enterprise and evaluation pages. If evaluators keep landing on your roadmap looking for a capability, the real fix is a page that documents what you support today, with proof. The slot mechanics are in where to place testimonials on an enterprise page.
A note for sales teams
"It's on the roadmap" is one of the most common phrases in late-stage deals, and a public roadmap with testimonials in the wrong columns makes it more dangerous. Agree internally on one rule: sales can link to shipped items with quotes freely, and can link to planned items only with the explicit reminder that the roadmap shows direction, not dates. Put that same sentence in the roadmap's intro block so the page says it for them.
A quick audit
- Are there any quotes attached to Planned or In progress items? Move or remove them.
- Does each quote in Shipped come from someone who actually requested or used that item?
- Is there a single process quote near the intro, ideally one that acknowledges not everything gets built?
- Are upper-column demand signals shown as counts rather than attributed quotes?
- Does the intro state plainly that the roadmap is not a delivery commitment?
A public roadmap earns trust by closing loops visibly. Put customer voice where the loop has closed, and keep it away from promises that haven't.