How to Write a Feature Request

The feature requests that get built aren't always the best ideas. They're the ones that are easiest to understand, clearest about the problem, and most specific about the desired outcome. I've seen brilliant suggestions get buried in backlogs because they were written as "make it better" while mediocre ones moved forward because they clearly described a pain point and a solution.

How to write a feature request matters whether you're a user submitting one or a product team designing the submission process. Both sides influence whether a request gets understood, gets votes, and ultimately gets built.

What Makes a Good Feature Request

A good feature request has three elements:

A clear problem statement. Not "add dark mode" but "I work at night and the white background causes eye strain after 30 minutes." The problem is what gets prioritized. The solution is what the team designs. When you lead with the problem, you give the product team room to find the best solution, which might be better than what you originally imagined.

Specificity about impact. "This would help a lot" versus "I hit this issue 3-4 times per week and it adds about 10 minutes each time." Specific impact helps the product team estimate how many users face this problem and how severe it is. It directly feeds into prioritization frameworks like RICE, where Impact is a key scoring dimension.

One request per submission. "Add CSV export AND improve the dashboard AND fix the mobile layout" is three requests. Each one needs its own discussion, its own votes, and its own priority. Bundled requests dilute the signal because voters might agree with one part but not the others.

How to Write a Feature Request (as a User)

Step 1: Describe the Problem, Not Just the Solution

Start with what's frustrating, slow, or impossible today. The problem statement is the most important part of your request because it's what the product team evaluates.

Weak: "Add a Slack integration" Strong: "When a user submits feedback, I have to manually check the dashboard every hour to see new entries. I'd like notifications in Slack so I can respond within minutes instead of hours."

The strong version tells the product team: the core need is real-time notification, Slack is the preferred channel, and the current workaround costs time. They might solve it with Slack, or with email notifications, or with a webhook. Either way, the problem is clear.

Step 2: Explain Who This Affects

Help the product team understand the scope. Are you the only one who needs this, or does your whole team?

• "Our 12-person support team all need this"
• "I manage 3 products and hit this limit on each one"
• "I've seen 5 other users ask about this in the community"

Scope helps with the "Reach" dimension in prioritization. A request that affects one user is valid but may not rank as highly as one that affects an entire team segment. ProductPlan's guide on handling feedback emphasizes that scope context is what separates actionable requests from noise.

Step 3: Include Your Workaround (If Any)

If you've found a hacky way to solve the problem, describe it. This does two things: it proves the need is real enough that you invested effort in working around it, and it gives the product team insight into the current user journey.

"Right now I export to CSV, open in Google Sheets, and manually filter. Takes about 15 minutes per report."

That's a real cost that the product team can quantify. It also suggests what the solution should improve: if the workaround takes 15 minutes, the feature should take seconds.

Step 4: Vote on Existing Requests Before Creating New Ones

Before submitting a new request, search the feedback board for similar ones. If someone already described your problem, vote for their request instead of creating a duplicate.

Votes are the primary demand signal that product teams use to prioritize. One request with 50 votes is far more actionable than 50 separate requests that each describe the same need in slightly different words. Duplicates fragment the signal and make it harder for the team to see true demand.

How to Structure Feature Requests (as a Product Team)

If you're building the submission process, your job is to make it easy for users to write good requests without making them feel like they're filling out a form.

Design the submission flow

Use structured fields that guide users toward specificity:

• Title (required): Short, descriptive summary
• Problem (required): "What problem does this solve?" Not "describe your feature" but "what's frustrating today?"
• Impact (optional): "How often do you hit this problem?" Frequency helps with prioritization
• Proposed solution (optional): Let users suggest what they think the fix looks like, but don't require it. Some users know exactly what they want. Others just know something is broken.

In Feeqd, you can configure this using widget blocks: a text input for the title, a textarea for the problem description, and optional fields for impact and proposed solution. The widget editor supports 18 block types, so you can customize the form to match your needs without code.

Enable voting and prevent duplicates

The most impactful thing you can do is make existing requests visible and votable. When users land on your feedback board and see their problem already described, they vote instead of creating a duplicate. This concentrates signal instead of scattering it.

Display requests sorted by votes by default. This shows new visitors what the community cares about and encourages them to browse before submitting.

Respond to every request

A feedback board where requests go unanswered is a feedback board that stops getting submissions. Acknowledge every request, even if the response is "Thanks, we'll evaluate this in our next planning cycle."

When a request gets enough votes to warrant action, update its status. When it moves to your roadmap, communicate that. When it ships, close the loop. The lifecycle of a feature request doesn't end at submission. It ends when the user knows what happened.

Feature Request Template

If you want a ready-to-use structure, here's a template that works for both formal submissions and quick feedback:

Title: [Short description of what you need]

Problem: What are you trying to do that's difficult, slow, or impossible right now?

Impact: How often do you encounter this? How does it affect your workflow?

Current workaround: How do you handle this today? (If applicable)

Proposed solution: What would the ideal solution look like? (Optional)

This template works as a text form, a widget configuration, or even as guidelines pinned to a feedback board. The key is the problem-first structure: it forces specificity and gives the product team the context they need to evaluate and prioritize the request.

Common Mistakes

Writing solutions instead of problems. "Add a button that does X" skips the most important part. The product team needs to understand why before they design how. Maybe there's a better solution than the button you're imagining.

Being too vague. "Improve the UX" is not a feature request. What specific interaction is frustrating? What did you expect to happen that didn't? Vagueness makes requests unprioritizable because the team can't estimate scope or impact.

Bundling multiple requests. Each problem deserves its own entry so it can accumulate its own votes and be evaluated on its own merits. A bundled request with 30 votes might have 25 votes for one part and only 5 for the other, but you can't tell.

Not searching for duplicates. According to Atlassian's guide on feature requests, duplicate submissions are one of the biggest sources of noise in product backlogs. A quick search before submitting keeps the backlog clean and concentrates voting signal on existing entries.

FAQ

How to write a good feature request?

Lead with the problem, not the solution. Describe what's frustrating, slow, or impossible today, then explain who it affects and how often. Include your current workaround if you have one. Keep it to one request per submission. The best feature requests are specific enough that the product team can estimate impact without a follow-up conversation.

What is a feature request?

A feature request is a structured suggestion from a user asking for new functionality or an improvement to an existing product. It typically includes a problem description, the desired outcome, and optionally a proposed solution. Good feature requests are submitted through feedback boards where other users can vote on them, creating a demand signal that helps product teams prioritize what to build next.

What should a feature request template include?

Five fields: a short title, a problem statement (required), impact description (frequency and severity), current workaround (if any), and proposed solution (optional). The problem statement is the most critical field because it's what gets evaluated during prioritization. The proposed solution should be optional because users often know the problem better than the fix.

How do product teams handle feature requests?

Teams collect requests through feedback boards, let users vote to quantify demand, then evaluate top-voted requests using frameworks like RICE scoring. Requests that make the cut get added to the roadmap, built, and shipped. The best teams then announce the feature back to the users who requested it, completing the feedback loop and encouraging more submissions.