Everything you need to collect a feature request with the right details and answer it at every step. Copy the form fields, the internal doc and the emails, and see them filled in for one real-looking request.
By Martin Lasek · Oct 5, 2026 · 7 min read
A feature request template makes every request arrive with the same details: what the person wants, the problem behind it, how they cope today and how to reach them. Without one, you get "please add X" and a guess about why. With one, you get something you can compare, count and decide on.
This guide has three templates you can copy: a request form for your users, a one-page document for your team, and four reply emails for every decision. Plant Diary, a made-up plant care app, fills them in for one request, the same app as in the prioritization guides.
A good feature request form asks four things: what to build, the problem it would solve, how the person handles it today and how often it comes up, plus an optional email. Inside the team, a one-page doc adds who asked, the evidence, the effort and a decision. Then four short emails close the loop: received, planned, shipped and declined.
Here is the form filled in by a Plant Diary user. Every field earns its place, and none of them asks the user to design the feature:
| Field | Why it's there |
|---|---|
| What should we build? | A short title, so the request can be found, merged and voted on. Keep it under about 50 characters. |
| What problem would it solve? | The problem matters more than the suggested fix. There's often a better solution than the one people ask for. |
| How do you handle it today? | The workaround shows how much it hurts. A clumsy workaround means real demand. |
| How often does it come up? | Weekly pain beats a once-a-year wish. A fixed choice keeps the answers comparable. |
| Email (optional) | So you can send the emails further down. Without it, there's nobody to tell when it ships. |
Copy the fields into whatever you use for forms:
What should we build? One short line, like a title. What problem would it solve for you? Describe what you're trying to do, not how you would build it. How do you handle it today? Your workaround, if you have one. How often does this come up? Every day / Every week / Every month / Rarely Your email (optional) We'll tell you when it ships.
Inside the team, one page per request keeps the discussion short and puts the decision on record. Fill it in when a request gets serious, not for every idea:
Feature request: [short title] Date: [date] Owner: [who looks after it] Problem [What the user can't do today, in their words.] Who asked [Number of requests or votes, which customers, which plans.] Evidence [Quotes, support tickets, reviews, usage data. Link each one.] Current workaround [How people get by today, and what it costs them.] Possible solution [Optional. One paragraph, not a spec.] Effort [A rough estimate in days, and who would build it.] Decision [Planned, not now, or declined. The date, and one sentence on why.]
And the same page filled in for the request above:
Feature request: Custom watering intervals Date: October 5, 2026 Owner: Sam (iOS) Problem Plant Diary uses one watering schedule for every plant. A cactus and a fern can't both be right, so people start ignoring the reminders. Who asked 64 votes on the feedback board this quarter, 20 of them from Pro subscribers. 11 App Store reviews mention it. Evidence Top comment on the board: "One schedule for all my plants means I ignore every reminder." 6 support emails this quarter ask for the same thing. Current workaround People set separate reminders in Apple's Reminders app and stop using Plant Diary's reminders. Possible solution An interval per plant, with presets for the ten most common houseplants. Effort 6 days for one developer. A first version with presets only: 3 days. Decision Planned for version 2.0 (October 5, 2026). The most requested item and the headline of the release.
Most requests get one reply at best. Four short emails, one per decision, tell the person what happened and teach them that asking is worth it:
Hi [Name], Thanks for asking for [feature]. It's on our list now, and other people can vote for it too. We go through new requests every [two weeks]. You'll hear from us again when we decide, whether it's a yes or a not now. [Your name] [App]
Hi [Name], Good news: [feature] is planned for [the next release / month]. [Number] other people asked for it too. If you want to shape it, reply and tell us how you'd use it. The more concrete, the better. [Your name] [App]
Hi [Name], You asked for [feature], and it's out today in version [x.y]. [One sentence on where to find it.] Thank you for taking the time to ask. Requests like yours decide what we build next, so keep them coming. [Your name] [App]
Hi [Name], Thank you for asking for [feature]. We looked at it carefully and decided not to build it [for now / this year]. The reason: [one honest sentence, for example that it would take most of a release and few people use that part of the app]. [If there's a workaround: Here's how to get close today: ...] We'll keep it on our list, and if more people ask for it, we'll look at it again. [Your name] [App]
Keep them short and send them from a real person. Fill in the brackets, and make the declined email honest rather than vague. A clear no with a reason costs you less goodwill than silence.
The hardest field in the document is "who asked". A feature request board fills it as a side effect: people post a request with a title and a description, others vote instead of writing a duplicate, and the count is there when you write the doc.
WishKit works this way for websites and SaaS products, and inside iOS apps with a native SDK. On the web, its form asks for a title, a description and an optional email, with the hint "Get notified when this ships". On Premium, WishKit can send the shipped email for you: turn on Email Notifications for the project, and everyone who voted with an email address is emailed when you move the request to Completed. The received, planned and declined emails are still yours to send.
Once requests arrive in this shape, the next question is which to build first. The guide to feature prioritization compares five ways to decide on one list.
The problem it would solve, how the person handles it today, how often it comes up, and a way to reach them. A short title helps others find it and vote on it.
Describe the problem, not the solution: what you were trying to do, what stopped you, and how you work around it today. One request per feature, with a short title.
Reply at each decision: when you receive it, when you plan it, when it ships, and when you decide not to build it. Keep each reply short and send it from a real person.
Thank the person, say clearly that you won't build it for now, give one honest reason and offer a workaround if there is one. Leave the door open in case more people ask.
A one-page internal summary of a request: the problem, who asked, the evidence, the current workaround, a rough effort and the decision. It keeps the discussion short and the decision on record.
In one place, so duplicates can be merged and counted. A feature request board with voting does both and keeps requests out of support inboxes and app reviews.
Setup takes less than a minute. Free plan included, no credit card required.
Try WishKit for free