Product feedback survey template
You shipped a feature and need to know whether it solved the problem it was built for — not whether people liked it.
What this template is for
Asking whether people like a feature produces agreeable answers from the small group that already adopted it, and silence from everyone else. This template separates the two groups on the first question: people who never used it are asked what stopped them, and people who did are asked what they were trying to finish and whether it happened. A liked feature that finishes nobody’s job is a maintenance cost; this is the survey that tells the two apart.
Questions
Every question below is part of the actual survey definition — the same one the preview and “Use this template” use.
How often do you use this feature?
Single choice · Required
Why this question: The first question splits the audience into two surveys. Without it, non-users either drop out or answer questions about a feature they never opened, which quietly poisons every downstream number.
What stopped you from trying it?
Single choice + Other · Required
Shown when: Has not used the feature
Why this question: Non-adoption has causes that need entirely different responses: "did not know it existed" is a communication problem, "looked like too much work" is an onboarding problem, and "I do not have that problem" means the feature was aimed wrong. Averaging them into "low adoption" loses the distinction.
Watch out: Keep "I do not have that problem" in the list. Removing it forces everyone into blaming discovery, which is the comfortable answer rather than the true one.
What were you mainly trying to get done with it?
Single choice + Other · Required
Shown when: Has used the feature
Why this question: Establishes intent before outcome. The same feature succeeds for one job and fails for another, and without this question the failures appear as random negative scores.
Did it get that done?
Single choice · Required
Shown when: Has used the feature
Why this question: The actual measure. Deliberately separate from satisfaction: people forgive a rough experience that finished the job, and rate a pleasant one that did not as fine while never returning.
Watch out: Keep "Too early to tell" as an option. Without it, undecided users pick "Partly" and inflate the failure count.
What got in the way?
Multiple choice + Other
Shown when: Feature did not fully solve the problem
Why this question: Shown only when the job was not fully done, as countable options. It separates the missing-capability cases (build something) from the confusing-workflow cases (fix the design) — the two most common causes, and they have opposite responses.
How likely are you to keep using it?
Rating · 1–5 · Required
Shown when: Has used the feature
Why this question: Intent to continue is the outcome that matters for a feature; a good first experience with no second use is the most common shape of a failed launch.
What is missing?
Long text · up to 600 characters
Shown when: Has used the feature
Why this question: One open question, asked of users and non-users alike, so the answers include the reason people never started. Kept last so it does not absorb answers belonging in the structured questions.
Did this feature do the job?
How often do you use this feature?
What stopped you from trying it?
What were you mainly trying to get done with it?
Did it get that done?
What got in the way?
How likely are you to keep using it?
What is missing?
When to use this
- Two to six weeks after a feature ships or a beta opens — long enough for a real attempt, recent enough to remember it.
- You can still change the feature. The friction checklist is a roadmap input, and it is worthless if the roadmap is closed.
- You are sending it to everyone who was exposed to the feature, not only to the people who used it.
When not to use this
- You want to decide what to build next from scratch. This survey evaluates something that exists; asking non-users to design a feature produces a wish list nobody will use.
- The feature has been live for a year. By then adoption has selected for the people it suits, and the answers will be positive and useless.
- You need to know why someone cancelled the product entirely. That is a churn survey — the frame is the relationship, not one feature.
Branching
People who have not used the feature answer one question about what stopped them and skip the outcome page entirely. Users are asked their goal, whether it was achieved, and — only if it was not — what got in the way. Nobody is asked to evaluate an experience they did not have.
Validation
Usage, goal, outcome and continuation intent are required for the paths where they apply; the friction checklist is optional, because forcing a cause on someone who does not have one manufactures data. Free text is capped at 600 characters.
What to look at once responses arrive
Report non-adoption before satisfaction
The share who never used the feature, and why, is usually the largest and least examined number in the whole result. It is also the one that decides whether the next step is engineering or communication.
Read outcome by goal, never in aggregate
A feature that reliably finishes one job and fails at another shows up as a mediocre overall success rate. Split by goal and the picture is usually sharp: one segment is done, another was never served.
Separate missing capability from confusing workflow
These two friction causes get the same complaint volume and require opposite responses. Building a capability to fix a workflow problem is the most expensive way to leave the problem in place.
Check continuation intent against actual usage frequency
Frequent users who say they will stop are the clearest early warning available, and they are invisible in usage analytics until they have already gone.
Crosstabs worth running
What were you mainly trying to get done with it? × Did it get that done?
The core read: which jobs the feature actually finishes. A goal with a low success rate is either the next iteration or an audience you should stop targeting.
What got in the way? × How likely are you to keep using it?
Shows which friction causes end usage rather than merely annoying people. Slowness is tolerated far more often than a wrong result.
Charts worth building
bar — What stopped you from trying it?
Why non-users never started, ranked. Compare its total against the number of users before planning anything.
stacked-bar — What were you mainly trying to get done with it? × Did it get that done?
Success rate per intended job, so a feature that works for exactly one audience is visible at a glance.
Customise it with AI
Paste this into SurveyZero’s assistant to adapt the template to your product. It keeps the parts that make the results comparable and changes the parts that should be specific to you.
Adapt this feature feedback survey for an AI writing assistant inside a document editor, sent four weeks after launch to everyone who saw the entry point. Keep the split between users and non-users on the first question, keep the goal → outcome → friction structure, and rewrite the goal options for writing work (draft faster, get unstuck, tighten existing text, match a house style). Add one question about whether the output needed editing before use.
Related templates
- NPS survey template — You need a recommendation score you can track over time, and you need to know what to do about it — not just the number.
- CSAT survey template — You want to measure one specific interaction — usually a support ticket — right after it happens, and act on the bad ones the same week.
- Churn survey template — Customers are cancelling and you need to know which cancellations you could have prevented — not a list of complaints.