Survey template

Feature request survey

A raw feature request is a solution someone guessed at. This template captures the job behind it — what they were trying to do, how they work around it today, and how often the gap hurts — so you prioritize problems instead of building everyone's pet idea.

Best for: PMs and founders triaging and prioritizing inbound feature requests.

The questions

1. What are you trying to accomplish that the product doesn't help with yet?

   Long text

   Asks for the job, not the feature — the request is just their proposed fix.

2. What feature or change do you think would solve it?

   Long text

   Capture their solution too, but treat it as one option, not the spec.

3. How are you working around this today?

   Long text

   The workaround tells you the real cost and the real competitor.

4. How often does this come up for you?

   Single select

   Daily / Weekly / Monthly / Rarely — frequency separates urgent gaps from nice-to-haves.

5. What happens if it stays as it is?

   Long text

   Surfaces the actual consequence — churn risk, lost time, or mild annoyance.

6. How important is this to you?

   Opinion scale

   1-5 — combine with frequency to rank, never use alone.

7. What's your role and company size?

   Short text

   Lets you weight requests by the segment you're targeting.

How to run it well

• Rank by frequency times consequence, not by raw vote count — a painful weekly problem for ten target users beats a mild wish from a hundred.
• Read the workaround answers closely; a heavy, time-consuming workaround is the strongest signal that people will adopt a real fix.
• Cluster requests by the underlying job before you scope anything — five different feature asks often resolve to one problem worth solving once.
• Close the loop with requesters when you ship or decline; it keeps the pipeline of honest requests flowing instead of drying up.

FAQ

Why not just count votes on feature requests?

Vote counts reward whoever shouts loudest and ignores intensity. A feature requested often but mildly can rank below one requested rarely but with a painful workaround. Combine frequency and consequence instead.

How do I stop building the literal feature someone asked for?

Separate the job from the proposed solution in the survey itself. Once you have the underlying problem and the current workaround, you can often solve it more simply than the requested feature would have.

Should every request feed the roadmap?

No. Use the survey to find recurring, high-consequence jobs within your target segment. One-off asks outside your ICP are useful context but rarely belong on the roadmap.

Related templates