Feature request
A feature request template that leads with the user's problem, not the solution, plus evidence, alternatives, and how success is measured.
Last updated
Fill in the blanks
Assembled in your browser — nothing you type is stored or sent anywhere.
Your document
How to use it well
- →If the problem section already names a UI, rewrite it - describing the solution before the problem is how teams end up building the wrong fix for the right pain.
- →Usage data beats a strong opinion. A count of accounts hitting the problem turns "I think users want this" into something a roadmap can actually be prioritized against.
- →Write the success measure before building anything - a request with no stated finish line quietly turns into a permanent feature nobody ever confirms was worth it.
Part by part
- ## The problem
- Before the solution, because a request framed as a feature hides the problem it came from — and the problem often has a cheaper answer than the feature.
- ## Evidence it matters
- Turns a preference into a case. Without it, requests are prioritised by who asked most recently rather than by what is costing users most.
- ## Alternatives considered
- Shows the thinking. A request that has already ruled out two options is far more persuasive than one presenting a single answer.
- ## How we'll know it worked
- A success measure defined before building. Without it, shipping is treated as success and nobody checks whether the problem went away.
Common mistakes
Requesting a solution rather than describing a problem.Add a bulk export button constrains the answer to one implementation. Describing what the user is trying to do lets the team find a simpler route, which is frequently available.
Evidence stated as several customers asked.Unfalsifiable and unrankable. Two named accounts with what it costs them is weaker sounding and far more useful, because it can be compared against other requests.
Skipping the success measure.Means the feature can never be evaluated. Shipping becomes the outcome, and a feature that solved nothing looks identical to one that worked.
Questions
Why is problem-first so insisted on?
Because the requested solution is a guess at the answer, made by someone who cannot see the rest of the system. The problem is the durable part; the implementation is the team's to choose.
What counts as evidence?
Support tickets, named accounts, usage data, or a workaround people are visibly maintaining. Anything specific enough that someone could check it, rather than a summary of impressions.
Should I propose a solution at all?
Yes, clearly marked as a proposal. It communicates the shape of what you imagined, which is useful context — as long as the problem section stands on its own without it.
Who should define the success measure?
Ideally the requester, since they know what would change for them. A measure written by the team after the fact tends to describe what was built rather than what was needed.