Feature request templates: what to ask, with examples

Your template decides what kind of requests you get. Ask for a solution and you get a pile of button ideas. Ask about the problem and you get something you can actually build from.

What should a feature request template ask?

Three questions do most of the work:

1. What were you trying to do? The goal, in the user's words.
2. What got in the way? The gap between that goal and what the product does today.
3. How do you handle it today? The workaround shows how painful the problem is. "I export to a spreadsheet every Friday and fix it by hand" is a stronger signal than "it would be nice."

Then, optionally:

4. How often does this come up? Daily, weekly, once a quarter.
5. Who else does it affect? Their team, their customers, just them.
6. Any idea how it could work? Last, so it doesn't anchor the request.

What should you leave out?

• Priority dropdowns. People tend to pick "high", so the field tells you little.
• A required solution field. It pushes people to guess at UI instead of describing the problem.
• Anything you already know. Name, email, plan and app version should come from the session, not the form.
• Long checklists. Every required field you add means fewer people finish the form.

What does a good template look like?

How does a template change the request you get?

The same request for a fictional habit-tracker app:

Without a template: "pls add dark mode"

With the template: the user logs habits in bed at night, the bright screen wakes their partner, and their workaround is dimming the phone every evening.

The second version tells you the real need is a low-light screen for one short evening task. Dark mode is one answer; a dim night-logging view is another. A clean title describes the problem, not the guess: "Low-light screen for logging habits at night" rather than "Dark mode."

How should the template change by channel?

• In-app widget: one required question ("What were you trying to do?") and an optional type. See how to add an in-app feedback widget.
• GitHub: use an issue form in .github/ISSUE_TEMPLATE/ with the three core questions as text areas, the first two required and the rest optional.
• Slack and Discord: don't force forms on chat. Pin a message listing the three questions, and ask whichever one is missing as a single follow-up in the thread.
• Sales and success teams: add the account name, what's at stake (a renewal, an expansion, a deal) and any deadline. Keep the customer's own words in a quote field.

How do you fix a request that skipped the template?

Most requests arrive as one line in chat. Don't send people back to a form. Instead:

1. Rewrite the title as a problem.
2. Ask one follow-up for the most important missing piece, usually the workaround.
3. Attach the original message as a quote.
4. Check whether it duplicates an existing request before creating a new one. See how to handle duplicate feature requests.

How do template answers help you prioritize?

They map onto common prioritization inputs. Frequency and "who else" feed reach, the workaround feeds impact, and a clear problem statement makes effort easier to estimate. If you score with RICE, the RICE calculator and the guide on prioritizing feature requests show how to turn those answers into a ranking.

Doing this with Sikia

Sikia captures messages from the Slack and Discord channels you pick, so users don't have to fill in a form there. It writes a clean title, keeps the original wording (translating non-English messages to English), and suggests merging a request into an existing one as a vote with the user's quote attached. When you decide to build something, the get_spec tool on Sikia's MCP server returns a spec with the problem, user quotes and acceptance criteria.

FAQ

Should bugs and feature requests share a template?

No. A bug template asks for steps, expected and actual behavior, and environment. A feature template asks about goals and workarounds. Use a type selector to route people to the right one.

Should users suggest solutions?

Let them, but make it the last optional field. The problem tells you what to solve; the suggestion is one possible answer.

Should I require sign-in to submit a request?

For in-app forms, users are already signed in, so attach their identity automatically. For public boards, a light sign-in such as email or SSO is worth it so you can notify people when their request ships.