A feature request asks for something the software does not do. Somebody has to decide whether to build it, and they will decide on what you wrote, usually without talking to you. Everything below exists to make that decision possible, and to make it go your way when it deserves to.
The short version
- The problem you have, in your own words, before any solution.
- What you do today instead, and what it costs you.
- Who else has the problem, and how often it comes up.
- What you propose, clearly labelled as one option.
- What would tell you it is solved.
The first item is the one people leave out, and it is the only one the reader cannot reconstruct without you.
The problem before the proposal
Most feature requests arrive as a conclusion: "add a CSV export", "make this a dropdown", "we need a dashboard". The thinking that led there was done privately and never written down, so the reader gets the answer without the question.
That matters because the proposal is one solution among several. The reader may know a cheaper one, or an existing one, and can only offer it if they know what you were trying to do.
Add an "Export to CSV" button on the customers page.
Every Monday I need the customers whose renewal is due this month in a spreadsheet, to pass to the account managers. At the moment I copy the table by hand, which takes about twenty minutes, and I get it wrong maybe once a month.
The second version might still end in a CSV button. It might also end in a scheduled email, a saved filter, or the discovery that the report already exists under another name. All of those were invisible in the first version.
What you do today
The workaround is the most persuasive paragraph in the request, and people rarely write it because it feels like admitting the problem is survivable. Write it anyway. "Twenty minutes every Monday, wrong once a month" is a cost a reader can weigh against the cost of building. "It would be nice to have" is not.
If there is no workaround, say so. "I cannot do this at all" is a different and stronger claim.
Who else, and how often
A request from one person on one occasion is an anecdote. The same request from four people every week is a pattern. You may not know the full picture, but say what you do know: "everyone on the finance team does some version of this", "twice so far this quarter", "a customer asked in the support channel, link attached".
Do not inflate it. "Everyone wants this" with no name attached reads as one person who is annoyed, and it costs you credibility on the next request.
What you propose, labelled as a proposal
Having led with the problem, say what you imagine the fix looks like. It is useful: you know the workflow, and the shape of what you imagined tells the reader what you think is wrong. Just label it as one option rather than the requirement.
"One way to do this would be an export button on the customers page, but anything that gets me the filtered list into a spreadsheet on Monday morning would solve it" gives the reader room to be cleverer than you, which is what you want.
What would tell you it is solved
Finish with the test. Not formal acceptance criteria, just a sentence: "I would know this was fixed when I could get Monday's list without copying anything by hand." It keeps the eventual work honest, and it is what stops a six-week project ending in "not what I meant".
What not to include
Urgency without a reason. "ASAP" and "high priority" carry no information. A date and what happens on it carries a lot: "our audit is on the 30th and I need this list for it".
A design. Mockups are welcome as an illustration of the problem. As a specification they narrow the options before anyone has looked at them.
Several requests in one. If the fix for your second paragraph would not fix your first, they are two requests. Combining them means the easier one waits for the harder one.
A complete example
Problem: every Monday I need the customers whose renewal is due this month as a spreadsheet for the account managers.
Workaround: today I filter the customers page and copy the table by hand. About twenty minutes, and wrong roughly once a month when a row gets missed.
Scale: two other people on the finance team do the same for their regions.
Proposal: an export button on the filtered page would do it, but a weekly email with the list attached would be better still.
Test: I would know it was solved when Monday's list arrived without anyone copying anything.
Five short lines. It can be estimated, it can be declined with a reason, and it can be solved by three different features, one of which may already exist. Most feature requests can be none of those things, and not because their authors wrote too little. They wrote the wrong part.