How to Write a Feature Request (Examples and Template)

Author: Inputly

How do you write a feature request that gets built?

You write the problem, not the solution. Product teams triage hundreds of requests, and the ones that survive describe the job to be done: "We lose an hour a week re-entering invoices" beats "Add an invoice API." A strong request has four parts: the problem you hit, who hits it with you, the workaround you use today, and the solution you imagine. The first three parts tell the team how important the request is; the fourth is a bonus, because the team may solve your problem better than your proposed solution.

Why do most feature requests disappear?

Because they arrive as one-line wishes with no context. "Add a mobile app" and "Integrate with Slack" are submitted by thousands of users who never say what they would do with the feature, so the team cannot judge whether the effort is worth it. Worse, users submit the same wish separately instead of voting, splitting the demand into five weak copies. The requests that get built are the ones that make prioritization easy: specific, quantified and already endorsed by votes. Write your request like you are helping the team say yes, because you are.

The feature request template

**Problem**
[What happened? Be specific. Include the moment, the task and the friction.]

**Who it affects**
[Just you, your whole team, or every user who does X? Estimate how often it happens.]

**Current workaround**
[What do you do today instead? This shows the team the real cost.]

**Proposed solution**
[Optional: what you imagine. Keep it flexible, the team may find a better path.]

**Example**
[A short real story of the problem, one or two sentences.]

Example: "We export our roadmap to CSV every Friday for a board meeting. It takes two people twenty minutes, and exports miss the latest status changes. A one-click CSV export button on the roadmap page would save us that every week."

Good versus bad feature requests

Bad: "Add dark mode." That is a solution with no context, submitted by someone the team knows nothing about.

Good: "I work late and my team is distributed across time zones. The white screen at night is uncomfortable and I avoid the dashboard after 8pm. A dark theme would let me check feedback without the glare, and I would use the product more at night."

Same request, different fate. The good version tells the team who wants it, why it matters and what it changes. It also demonstrates the request is about real usage, not a preference checklist. When in doubt, add the word "because" and finish the sentence.

Where should you submit a feature request?

To the product's public feedback board, if they have one, because that is where requests get votes and statuses. Search the board first: if your request exists, vote and comment with your use case instead of duplicating. If the product has no board, send the request through their official channel and ask what happens next. Then track your request the way you would track a bug: check the status, comment when it moves, and celebrate publicly when it ships, because products that close the loop reward the users who wrote the clearest requests.

Frequently Asked Questions

1. How do I know if my feature request will be built? Watch the status. Products that use visible statuses (New, Planned, Shipped) are telling you the truth. Products that never change a status are telling you something too.
2. Can one good request beat a hundred votes? Rarely. Votes are the demand signal, but one detailed request from a paying team with a real workflow can unlock an enterprise deal. Write well and vote too.
3. Should I ask for a roadmap commitment? Politely, once. "Is this on your roadmap?" is a fair question. Demanding dates for every request makes you the user the team stops wanting to hear from.
4. What if my request is rejected? Ask why, respectfully. Rejections with reasoning are gifts: they tell you the product's direction, and sometimes a small change to your request aligns it with their strategy.
5. Do product teams actually read feature requests? The good ones do, every week, sorted by votes. That is exactly why your job is to make yours readable, votable and impossible to misread.

Write the request that gets built. If you are a product team, set up a free voting board on Inputly so your users can tell you exactly what they need.