Roadmap Status Definitions: What Each Label Really Means
A roadmap status is a promise about process, not a promise about outcome. "Under Review" means someone is looking at the idea. "Planned" means the team has decided to build it. "In Progress" means work has started. "Shipped" means customers can use it. Everything else you add should be defined just as plainly, and written down where your users can see it.
This guide gives you working definitions for each label, the rules for moving an item from one status to the next, and the wording that keeps a public board from turning into a pile of broken expectations.
TL;DR
- Four statuses cover most teams: Under Review, Planned, In Progress and Shipped. Add more only when a real decision needs its own label.
- A status describes what the team is doing, never what it will eventually do. "Under Review" is not a yes.
- Give every status an entry rule, an exit rule and an owner, and publish the one-line definition next to the board.
- Use broad time horizons such as a quarter instead of exact dates on a public roadmap.
- Pick a status for every closed request, including the ones you decline, so no idea sits in limbo.
Table of Contents
- Why status definitions matter more than the statuses
- The four core statuses, defined
- Optional statuses worth adding
- Workflow: how items move between statuses
- How to talk about time without breaking trust
- Publishing your definitions
- Common mistakes
- Our perspective
- Setting this up on a board
- FAQ
- Sources
Why status definitions matter more than the statuses
Two teams can use the same label and mean opposite things. One team uses "Planned" for anything the product manager finds interesting. Another uses it only after design and engineering have signed off. Customers cannot tell the difference, so they read the label in the most optimistic way available.
That gap costs you in three places:
- Support. Every vague label produces a stream of "is this actually happening?" tickets.
- Trust. A "Planned" item that never moves teaches users to ignore the whole roadmap.
- Internal alignment. Research on roadmap alignment points to departmental silos as a common cause of misalignment, and suggests treating the roadmap as a shared contract that explains the "why" behind priorities to sales, support and engineering alike. Shared definitions are the cheapest way to build that contract.
A definition is short. It needs three parts: what the label means, what must be true before an item enters it, and what moves the item out.
The four core statuses, defined
Here is the set most feedback boards start with. It matches the lifecycle used on Petĩra boards: Under Review, Planned, In Progress and Shipped.
| Status | What it means | Entry rule | Exit rule |
|---|---|---|---|
| Under Review | The team has seen the request and is evaluating it. No decision yet. | Idea is posted and passes moderation | Team decides to build it, park it or decline it |
| Planned | The team has decided to build it. Work is not yet underway. | Scope, owner and rough priority agreed | Someone starts working on it |
| In Progress | Work has started. | First task is active in design or engineering | Released to customers |
| Shipped | Available to users now. | Released to production | Final state, kept as a changelog |
Under Review
This is the status behind the most confused searches. People type "what does under review mean" because the label is borrowed from job applications, journal submissions and permit forms, where it often feels like a polite holding pattern.
On a roadmap it means something narrower. The general meaning is that an item has been received and is being actively examined before a final decision, with no outcome yet. Treat it as a neutral process marker, not a prediction. A request marked Under Review might be built next month, built next year or declined.
A good public definition: "We have read this and are weighing it against other requests. It is not a commitment."
Set an internal rule for how long an item may sit here. Many teams use a review cycle, such as the next monthly planning session. When the cycle ends, the item must move to Planned, to your parked or declined status, or get a comment explaining why it stays.
Planned
Planned is the status that carries risk, because users hear it as a promise. Reserve it for items where the decision to build has been made, an owner exists and the team can describe roughly what "done" looks like.
A good public definition: "We have decided to build this. Work has not started yet, and timing can change."
If you are tempted to mark something Planned just to show a user you listened, use a comment instead. Say thank you, say what you are weighing, and leave the status honest.
In Progress
In Progress should be verifiable. If a developer opened a branch or a designer started a mockup, it qualifies. If the item is merely "next on the list", it does not.
A good public definition: "Someone on the team is working on this right now."
Be careful with long-running items. A feature that sits In Progress for six months looks stalled. Break large work into smaller items that can ship and close, or post an update comment when a milestone lands.
Shipped
Shipped means a customer can use it today. Not "merged", not "in beta for the team", not "rolling out next week". If you release gradually, say so in the comment and move the status once the majority of users have access.
A good public definition: "This is live. See the release note for details."
Shipped is also your best retention content. Everyone who voted on the idea can be notified that their request became real, which turns a one-time vote into a reason to come back. Our guide on feature request email templates includes replies you can reuse when an item ships.
Optional statuses worth adding
Four labels are enough to start. As the board grows, these extras remove ambiguity.
Under Consideration
Some teams use this alongside Under Review. The distinction is subtle but real: Under Review means active screening, while Under Consideration means the idea has passed screening and is being weighed as one option among many. Practitioners recommend that roadmap systems separate the two so customers do not read internal assessment as a commitment to build. If your team will not maintain both, pick one and define it.
On Hold or Later
Use this for work you want to do but cannot schedule. It signals that the idea is alive without implying a date. Attach a condition where possible, such as "revisit after the billing rewrite".
Not Planned or Declined
This is the status teams avoid, and the one that earns the most trust. A clear "no" with a short reason beats a request that sits in review for two years. Users stop voting on dead ideas and you stop answering the same question.
A good public definition: "We have decided not to build this, at least for now. Here is why."
Duplicate or Merged
When two requests describe the same need, merge them so votes combine. Mark the secondary one so it points to the main thread. This keeps vote counts meaningful.
Workflow: how items move between statuses
A status list is only useful if movement follows rules. Here is a simple workflow you can adopt in an afternoon.
- Intake. A user posts an idea. A moderator checks for duplicates, merges if needed and sets the status to Under Review.
- Triage. On a fixed cadence, the product manager reviews items by votes, customer segment and strategic fit. Our piece on bringing evidence to prioritization workshops shows one way to structure that conversation.
- Decision. Each reviewed item goes to Planned, On Hold or Declined. Each move gets a one-sentence comment.
- Delivery. When work starts, move to In Progress. When it releases, move to Shipped and notify voters.
- Hygiene. Once a quarter, audit every item. Anything In Progress with no activity, or Planned with no owner, goes back one step.
Two rules keep this honest. Items never skip backward silently: if something moves from Planned back to Under Review, say why. And no item changes status without a comment, however short.
Matching statuses to roadmap columns
If you also run a Now, Next, Later view, map the labels deliberately. In Progress belongs in Now. Planned items with an owner and a near-term slot belong in Next. Under Review and On Hold usually belong in Later or outside the roadmap view entirely. We describe the governance side of this in our Now, Next, Later playbook, and the risk of the backlog and roadmap drifting apart in this guide to backlog versus roadmap.
How to talk about time without breaking trust
The fastest way to damage a public roadmap is to attach exact dates to statuses. A date on a Planned item becomes a deadline in the customer's mind, and a missed deadline feels like a broken promise even when the work is going fine.
ProductPlan's guidance is that as a roadmap's audience moves from internal teams to public customers, emphasis on specific dates should decrease. Use broad horizons instead. Instead of "October 20", write "Q4" or "second half of this year". Instead of a timeline per item, group by Now, Next and Later.
Here is how that looks in practice:
| Weak wording | Stronger wording |
|---|---|
| Planned for October 20 | Planned, targeting this quarter |
| In Progress, ships next week | In Progress |
| Under Review, answer by Friday | Under Review, next decision in our monthly planning |
| Shipped in v4.2.1 | Shipped, see the release note |
The goal is to be precise about state and loose about calendar.
Publishing your definitions
Definitions that live in a product manager's head do not help anyone. Put them where users look.
- Add a legend to the board. One line per status, in plain words, visible above the list.
- Use the same words everywhere. If the board says "Planned", your changelog, support macros and sales decks should not say "Committed".
- Train support and sales. They are the people customers ask. Give them the legend and a rule: never tell a customer an item will ship unless it is In Progress or Shipped.
- Write comments in the same register. A status change plus one sentence on the reason does more than a long announcement.
Public roadmaps also work as a feedback channel in both directions. ProductPlan notes that sharing a roadmap publicly can validate demand as teams gather reactions to listed items, and that it carries its own risks: listing too much invites copying, while being too generic fails to excite users. Your status set should show enough to build confidence without exposing every half-formed idea. If you are weighing formats, see our overview of four public roadmap formats.
Common mistakes
Using Planned as a courtesy. It dilutes the label for every item that deserves it.
Leaving requests in review forever. A review status without an exit rule is a graveyard. Set a cadence.
Too many statuses. Eight labels with fuzzy edges are worse than four crisp ones. If two labels cannot be told apart by a new teammate in ten seconds, merge them.
No "no". Teams that never decline end up with a board full of hopeful items and a trust problem.
Changing meanings silently. If you redefine a status, announce it and update the legend. Otherwise old items quietly mean something new.
Forgetting private context. Some feedback should not be public at all, such as enterprise requests covered by contract. Keep those on a private board and sync only what is safe to show.
Our perspective
We built Petĩra around a simple belief: the status is the product. Anyone can collect ideas in a spreadsheet. What users remember is whether they ever found out what happened to theirs.
That is why we keep the lifecycle small and readable: Under Review, Planned, In Progress, Shipped. Each one answers a question a customer actually has. Did you see it? Are you doing it? Is anyone working on it? Can I use it?
We also think teams over-worry about saying no. The users who post ideas are not asking for a guarantee. They are asking not to be ignored. A clear status, a short comment and a notification when something changes cost you minutes and buy you months of goodwill.
Finally, we think the public side matters. When users can see the roadmap and vote on it, you stop collecting feedback scattered across emails and chats, and you start seeing what many people want at once. Statuses are what make that view trustworthy.
— Aron
Setting this up on a board
If you want these definitions live this week, Petĩra gives you the status lifecycle, a public roadmap, voting, comments and email notifications in one hosted board. All plans include unlimited users, ideas and votes, and pricing is flat rather than growing with participation. The Free plan costs 0 EUR per month, Pro is 19 EUR per month (or 190 EUR per year), and Team is 49 EUR per month (or 490 EUR per year). You can compare them on the pricing page or see the whole product at petira.io. If you are moving from another tool, you can import from Canny, Fider or CSV, so your existing requests keep their history.
FAQ
What does "under review" mean on a feedback board or roadmap?
It means the team has received the request and is actively evaluating it. No decision has been made, so the idea could be built, postponed or declined. Think of it as a process marker rather than a forecast.
What is the difference between Planned and In Progress?
Planned means the team has decided to build the item but has not started. In Progress means work is happening now. Moving an item between the two should be a real event, such as the first task being picked up.
How many roadmap statuses should I use?
Start with four: Under Review, Planned, In Progress and Shipped. Add a status for declined requests and, if you need it, one for work on hold. Add more only when you can write a definition that does not overlap an existing one.
Should a public roadmap show dates?
Usually not exact ones. As the audience becomes external, guidance recommends fewer specific dates and broader horizons, such as a quarter. Dates turn into deadlines in customers' minds.
Is it okay to decline a request publicly?
Yes, and it usually helps. A short reason lets users move on and stops votes piling onto an idea you will not build. Keep the tone respectful, and say whether you might revisit it.
Sources
- Roadmap Timelines: Do You Need Them? When? | ProductPlan
- When is it Smart to Share Your Roadmap Publicly? | ProductPlan
- Under review definition and meaning | GenieAI
- Product Roadmap Alignment: A Grey Literature Review | PMC