A feature request is a customer telling you about something they cannot do yet and would like to. That is the definition and it is not where anybody gets stuck.
Where people get stuck is the part nobody writes down, which is what actually happens to the request between the moment somebody types it and the moment it either ships or does not.
Most of the damage in this whole subject happens in that gap, so this page walks it step by step on our own board, with what is visible to whom at each point.
What is in a feature request?
Two fields, and there is a good argument for not adding a third.
Ours asks for a heading and a description, and both are required. The heading is capped at two hundred and fifty four characters and the description at two thousand, checked in the form as you type and checked again on the server, because a limit that only exists in a browser is not a limit.
The temptation is to ask for more. A category, a priority, a use case, an area of the product.
Every field you add is a field somebody has to fill in before they can tell you the thing they wanted to tell you, and the people who abandon the form are not a random sample. They are the busy ones, which is to say the ones running the companies that pay you.
The longer version of that argument is in the template, which publishes the fields we would use in a plain file and explains which ones earn their place.
There is a working version of this on the demo board, which is open without an account.
Who can see a request when it arrives?
Nobody except you, and that is on purpose.
A request suggested from the public page arrives unapproved. It is created on the Suggested column with the visitor's identity attached, and with its approved flag set false, and until somebody turns that flag on it is invisible on the board, absent from the public list, absent from the API and absent from the top features rail.
It also cannot be voted on, because it is not there to be voted on.
That ordering matters more than it sounds. Triage happens before anything gets a score rather than after, so a request never accumulates votes and then disappears, which is the worst possible sequence for the person who asked. You are notified when one lands, and the queue of things waiting is a count you can see.
A request you create yourself is approved as it is written, since you are the person who would have been approving it.
What can happen to it next?
Four things, and only two of them are yes. What a request actually looks like when it arrives, written out in full, is worth reading beside this.
Approval. Somebody turns it on and it appears on the board with your name recorded against the approval. From that moment it can be voted on, and the count under it starts meaning something.
Promotion. A request can be moved out of Suggested into a roadmap column, and moving it to Completed sets its progress to full at the same time. That is the yes that has a date attached, or as close as we get to one.
A merge. If it is the same request as something already on the board, the two become one. Anybody who voted for both is counted once, the comments move, and the words the second person used are kept and shown on the survivor. What that does to the numbers is worth knowing before you do it.
A no, or a shelf. Denied is a status and it is public. Archiving is a separate state and it takes the request off the board altogether. Those are two different answers and the difference matters to the person who asked.
Feature request vs user story, what is the difference?
Who wrote it, and what it is allowed to assume.
A feature request is written by the person who wants the thing. It names a want, often names a solution, and carries no estimate, no acceptance criteria and no promise that anybody agrees with it.
A user story is written inside the team, in a fixed grammar naming a role, a want and a reason, and it exists to be estimated and pulled into a sprint.
The two are consecutive rather than alternative. A request is the input and a story is what the team writes after deciding to do something about it, which means a board full of stories has skipped the step where customers say what they need, and a backlog of raw requests is not something anybody can plan from.
The fields on this page are the request side of that line. A heading and a description, both required and nothing else asked for, and neither of them is an estimate or an acceptance criterion.
How do you say no to a feature request?
In the first line, with one clause of why, whether it can change, and what you are doing instead.
Those four things are the whole answer. Refusing is hard because writing them takes five minutes you do not have rather than because it is unpleasant, so the reply does not get written.
The request gets a thumbs up, or a we will consider it, and six weeks of somebody's expectations attach themselves to a sentence written to avoid an awkward two minutes.
Silence is the expensive version of the same mistake. It reads as a no to nobody, as a not yet to almost everybody, and to a few people as contempt. It is the option that requires no effort, which is why it wins so often.
Six situations cover almost every refusal. Each one is written below as the body of a reply, and the greeting is yours.
One. The large customer who has asked for the wrong thing.
We are not going to build this one, and I would rather give you the reason than a maybe. What you have described would work for your team and would break the way three other things behave for everybody else, so it is not a question of when. The problem underneath it is real though, and I would rather fix that than argue about the shape of the fix. Can I show you what we are considering instead, and you can tell me whether it would actually help.
It does not thank them for the feedback, it does not say their input is valuable, and it does not promise to raise it internally. A verdict, a reason that could be argued with, and a next move.
Two. The request that is really a bug.
This one is not a feature, it is broken, and you should not have had to ask for it. I have moved it out of the request list and into the bug queue, which means it gets fixed on its own schedule rather than waiting behind a vote count. Sorry that it took a request to find it.
The last sentence matters more than it looks. Somebody who files a bug as a request has usually assumed the behaviour was intentional, and telling them it was not is the actual answer. The two want different queues.
Three. The duplicate.
Somebody asked for this a while back and there is a longer thread on it with a few people describing the same problem slightly differently. I have merged yours into that one, so your vote is counted there rather than split across two, and you will get the update when it moves. Worth a read, because the version there is more specific than either of us would have written alone.
Four. On the roadmap, but a long way off.
This is on the list and it is not close. I would rather tell you that than say soon, because soon is a word that means nothing and you will plan around it. Two things ahead of it are bigger than it is. If you have a fixed date on your side, tell me what it is and I will tell you plainly whether it is going to make it, which is a more useful answer than a position on a list.
Five. The one that is never going to happen.
No, and it is a no rather than a not yet, so I am not going to leave it sitting open pretending otherwise. It is outside what this product is for, and building it here would produce a bad version that you would end up replacing anyway. Here is what I would use instead, and I mean that as a real recommendation rather than a brush off.
That last clause exists because recommending somebody else sounds like a brush off unless you say it is not, and a person who was going to need that thing anyway will remember who told them.
Six. The request from somebody who does not pay you.
Thank you for writing this up. It is a better description of the problem than most, and I am telling you that because I am about to say no. We are not going to build it, and that is a decision about what we can carry rather than a comment on you or on the idea. The request stays up publicly so that anybody else with the same problem can add themselves to it, and if that number moves the decision moves with it.
The last clause is the honest version of what most teams mean and rarely say, which is that the answer is a function of how many people are asking.
What happens to the card when you decline one?
The reason you type is published on it, and the card moves to the declined column where it stays visible.
It is not a soft delete and it is not a quiet archive. The refusal and the reason sit on the public board next to everything you did build, and the reason has two thousand characters in it, which is more than you should use.
If your reason needs two thousand characters it is probably not a reason yet.
That column is public by default and you can turn it off. Turning it off removes those cards from the public board entirely rather than hiding a heading, which is a legitimate choice and worth knowing is the choice you are making.
One gap is worth stating plainly. Nobody who voted for the request is emailed when it is declined. Publishing a release does email the people whose votes are in it, and declining emails nobody. The card changes, the reason appears, and the people who asked find out by coming back and looking.
The cost of writing a reason down is that it can be quoted back to you. That is an argument for writing one that is true today rather than one you are pretending to hold forever, and for saying not now when you mean not now.
What you get in return is that everything else on the board becomes believable, because a roadmap with nothing declined on it is a wish list and readers work that out quickly.
When does the person who asked hear from you?
Once, and it is at the end.
When a release ships carrying something they voted for, they get an email that names the thing they asked for. Nothing else in the flow sends anything. Approval sends nothing, a status change sends nothing, a merge sends nothing and archiving sends nothing.
There is a second limit on that email worth knowing. Only voters who were signed in receive it, because a person who voted anonymously has no address attached. Anonymous voting is the reason the counts are worth reading and it is also the reason some of your voters cannot be told directly. Both are true.
So the honest position is that the tool closes the loop once, at the point where closing it is easiest and most welcome, and every other message on the way is one you write.
The reader this matters to gets the same request from several people and cannot count them. A team receiving a handful a month can hold that in a document, and the counting only earns its keep once the duplicates outnumber the distinct asks.
Does a vote count mean the request is important?
Not by itself, and this is a company that sells a voting board saying so.
A vote count measures how many people saw the request and cared enough to click. It does not measure how much the request is worth, how hard it is, or whether the people who voted are the people paying you. It is a real signal and it is one variable.
That last part has a fix. A vote can carry the weight of the customer who cast it, so three requests from paying customers can outrank thirty from people who are not. That is the mechanism, and it turns the count from a headcount into something closer to an answer.
One thing worth knowing before you go and collect a lot of these. A queue of requests is additive by construction, and building the top of it every time has a name and a predictable ending, which is written up here.
Do you need a tool or a spreadsheet?
A spreadsheet, while all four of these are still true.
The feedback comes to you. One inbox, one person reading it, and no colleague who needs to know what arrived last week.
You can remember what is on it. Enough that when something arrives you know whether you have seen it before. Most people manage that up to somewhere between thirty and eighty items, and the number depends more on how similar the items are than on how many there are.
Nobody outside needs to see it. No customer is asking where their request went, and nobody is asking what is coming next often enough for it to be a task.
You are not repeating yourself. You are not answering the same question from different people, and you are not telling anybody twice that something shipped.
If all four hold, buy nothing. Open a sheet with four columns, which are the request, who asked, when, and what you decided.
The fourth column is the one people leave out and it is the only one that makes the sheet worth keeping. The roadmap template here is a plain file for exactly that reason, with the effort and priority columns already in it.
Three signs say the sheet has stopped being enough, and any one of them is sufficient on its own.
You searched the sheet before answering a question and could not find the row. Not because it is missing, because you did not remember what words you used. That is the duplicate failure arriving, and from that moment your counts stop meaning anything.
You wrote the same reply twice in a week. Whatever the reply is, it belongs on a page rather than in an inbox.
You shipped something and did not tell anybody who asked for it. Not decided not to. Meant to and did not. That is the one that costs compounding rather than fixed amounts, because a person who tells you something and hears nothing learns that telling you does not work, and then the quiet reads like your customers have run out of ideas rather than like they have stopped bothering. That is the loop nobody closes.
A tool does not make the prioritisation better. It makes it cheaper to keep doing, and that is the difference between a process you run for two months and one you still have in a year.
The board, the roadmap page and the changelog are nine dollars a month, the figures are published, and a card is required for the fourteen day trial.
14 days, a card at signup, then $9 or $39 a month.