Four statuses are enough for a public roadmap
In Review, Planned, In Progress, Shipped. What each one promises the person who asked, and why adding a fifth makes the roadmap worse.
fedo ships exactly four statuses for a feedback item: In Review, Planned, In Progress, and Shipped. That is the whole state machine, and it is deliberately smaller than what most teams would design for themselves.
The reason is that a public roadmap status is not a project management field. It is a promise made to a specific person who asked for a specific thing, and promises get less useful the more of them you make.
Key takeaways
- Each status answers one question: is anyone going to do this, and has it started?
- Four states is the minimum that distinguishes "we saw it" from "we agreed" from "it is happening" from "it is done."
- A status is a commitment to the requester, not a column in your sprint board — do not mirror your internal workflow.
- The hard one is In Review, because it is where things sit when the honest answer is "probably never."
- Statuses gate what the requester can still edit, so moving an item is not purely cosmetic.
What each one actually promises
In Review — we have seen it and have not decided. This is the default and the largest bucket. It says a human will look, and nothing more.
Planned — we agreed to build it, and it has not started. This is the only status that is a real commitment, and it should be the hardest to grant.
In Progress — someone is working on it now. It converts an abstract agreement into a thing with momentum, which is why it is worth being separate from Planned.
Shipped — it exists in a release. The item stops being a request and becomes a receipt.
Read as a sequence, they answer escalating questions: did you see it, do you agree, has it started, is it out. Every one of them is a question a user actually asks. That is the test for whether a status earns its place.
Why not more
The temptation is to add the states your team already uses. In Design. In QA. Blocked. Needs Spec. Up Next.
Each of those is real internally and useless externally, for two different reasons.
The first is that they leak your process to people who did not ask for it. A user who requested dark mode does not benefit from learning it is in code review. From outside, In Design and In QA both mean "in progress," and splitting them creates the appearance of information without adding any.
The second is worse: internal states change for internal reasons. An item bouncing from In QA back to In Progress and forward again generates status churn that, to the requester, looks like the project is in trouble. You have made a public signal out of a private detail, and now it moves without meaning anything.
The test: if a status changes for a reason the requester does not care about, it should not be a public status. Track it internally and map it onto one of the four.
Blocked deserves its own mention because it is the most tempting addition and the most harmful. It looks like transparency. What it actually communicates is "this is stuck and we are not telling you why," which is worse for the requester than either Planned or In Review. If work has genuinely stopped, the honest move is to put it back to In Review, not to invent a status that means "yes but no."
The problem with In Review
The four statuses have one real weakness and it is worth naming rather than hiding: In Review is where things go when the honest answer is "probably never."
Nobody wants to reject a feature request. Rejection is a conversation, and the status field is not where you want to have it. So items accumulate in In Review — the ones genuinely awaiting a decision, and the ones quietly declined but never marked as such — and over time the largest bucket on the board becomes the least informative one.
I do not have a clean fix for this, and I would rather say so than pretend the four-state model has no downside. The partial answer is that the comment thread is the right place for a real decline, because "we are not doing this, here is why" is a sentence, not a state. A status cannot carry a reason. A reply can.
An explicit Declined status is a plausible fifth. The argument against it is that it is one of the few statuses that will be read as a verdict on the person, not the idea, and a board where users watch their requests get publicly stamped Declined is a board people stop posting to. That tradeoff is not obviously resolved, and it is the change I would most likely revisit.
Status gates what can still be edited
One thing that is easy to miss: statuses are not purely decorative. Inside the SDK, a user can edit or delete their own feedback when its status allows it.
That constraint exists because an item that has been agreed to or built has other people attached to it. Once something is Planned, its votes were cast on the text as written, and letting the original author rewrite it after the fact means the votes now support something nobody read. Editing a typo in an In Review item is harmless. Rewriting a Planned item changes what a dozen people endorsed.
So the status field carries a permission as well as a promise. That is a good reason to move items deliberately rather than in a weekly cleanup pass.
Ordering by votes, not by status
The last thing worth saying is what statuses are not for: they are not a priority order.
The dashboard sorts by vote count, because votes are the signal about what users want and status is the record of what you decided. Keeping those separate is the point. When the top-voted item has been In Review for three months, that is information — a visible gap between what people are asking for and what you agreed to do. Sorting by status would hide exactly that gap behind a tidy set of columns.
More on how requests get collected in the first place in In-app feedback beats a feedback portal.
