Feature Request

People who use a product are always asking for more of it. The trouble was never a shortage of requests — it was that they arrived in different places and stayed there. A request typed into a support conversation lived in the memory of whoever answered it. A request made in a meeting ended up in a sales rep's notebook. A request posted in a community forum slid down the page within a few days and was never seen again.

So the meeting where a team decided what to build turned into a contest of recall. Someone would ask whether people had really been asking to move folders in bulk, someone else would say they thought so too, and then the question "how many times?" would land in silence. Nobody had counted, because nothing had been written down in a countable form. Without evidence, one customer met last week carried more weight than a hundred customers who had said the same thing over the past six months.

A feature request is the unit invented to fix that. Out of everything customers say, you pull the items that arrive as "please build X," and you write each one into a fixed set of fields.

A single request is six fields. The tool underneath can be a spreadsheet tab or one item in an issue tracker. What you record outlasts where you record it.

1. The raw wording. Copy what the customer actually wrote or said. The moment someone summarizes, that person's judgment enters the record, and there's no way to tell later which parts were the customer and which were the paraphrase.
2. Where it came from. Note the feedback channel it arrived through — a support ticket filed one at a time, the free-text box in a Net Promoter Score (NPS) survey that asks how likely someone is to recommend you on a scale of 0 to 10, or a note taken during a sales meeting. The channel tells you something about the person behind the words.
3. Who said it. Which customer, on which plan, with how many seats. Twenty identical requests that all come from individuals on the free plan are not the same number as twenty where four came from paying teams of twenty seats each.
4. What they were stuck on. Write down what the person was trying to do when they hit the wall. Next to "let us export to Excel" goes "spends two hours a month retyping the monthly report by hand."
5. An area tag. Which part of the product this is about. Agree on the tag list before you start tagging. Invent tags as you go and different people will use different names for the same thing, which makes this quarter impossible to compare against the next one.
6. Status and date. Logged, under review, shipped, or decided against — plus the date it changed. This field is what gives you something to say back to the customer months later.

Field 4 is the one most often left blank, and it's also the one that costs the most when it's missing. A request is not a problem statement; it's a solution the customer designed alone, using whatever they already know. Export to Excel, an automated report, and an integration with an outside tool read as three unrelated asks on paper. Fill in field 4 and all three collapse into one problem — the monthly report.

The person writing is usually not the customer. Put a request button inside the product and some customers will file their own, but most of what accumulates was written on someone's behalf by whoever heard them say it: the support agent who handled the conversation, the sales rep who was in the meeting, the customer success manager on a quarterly check-in.

Because it's written secondhand, the only chance to fill in field 4 is in that original conversation. When a customer says "we need an Excel export," the one person who can ask "what are you doing with those numbers today?" is the person already on the call.

Three groups read it. A product manager reads it as an input to prioritization, grouping requests by tag before a planning session. A support agent who receives the same request again reads it to find out whether it's already logged, already shipped, or already declined, so the answer given to this customer matches the one given to the last. And the customer who made the request reads it indirectly — they never open the table, but the reply that comes back through the feedback loop is assembled from these fields.

A request that gets approved stops being a request and moves into a user story or a product requirements document (PRD). From that point on it is a specification of what to build rather than a record of what a customer said.

"I'll log that as a feature request. It won't make this quarter's plan, though."

It's being recorded but not built now. Without the second sentence, customers hear "yes, soon."

"Don't just look at the request count — look at who's asking."

The same twenty requests carry different weight depending on which customers they came from.

"That's not a feature request, that's a bug."

Nobody is asking for something new; something that was supposed to work doesn't. It should be fixed without waiting for a prioritization meeting.

At Pagedeck, Sofia logs a line after every customer meeting. The team's rule is that she fills in the "stuck on" field at the same time, so next to "split approval into two steps" sits "approvals stall whenever the team lead is out." Before each quarter starts, Mia reads the whole table and groups it by tag before the prioritization meeting.

The most common misreading is that the requests with the highest counts are the ones to build. There are numbers in the table, so working down from the top looks like the obvious move. But the people who bother to file a request are a small slice of your users, and they skew heavily toward those already deep in the product. Follow the counts alone and you keep making things nicer for people who already stayed, while the person who signed up, got stuck on day three, and left never appears in the table at all. They don't write requests — they just leave, and the only trace of them shows up in churn reason records.

Reading the request as a build spec is the other common mistake, and it comes from the same place. It feels efficient when the customer has handed you the solution. But customers design solutions from inside the tools they already know. Someone coming from Excel asks for an Excel export; someone coming from a competitor asks for that competitor's button by name. Build it literally and the requester is happy, every other customer with the same underlying problem is still stuck, and the product carries one more narrow feature forever.