Feature Chaser

When a user requests a feature, you note it. When you ship that feature (or decide not to), the conversation usually ends. A feature chaser survey closes the loop by re-engaging users who made specific requests to validate whether the need still exists, gather updated requirements, and measure satisfaction with shipped features.

This survey turns your feature request backlog from a static list into a dynamic demand signal. Requests age. Priorities shift. What was critical six months ago may be irrelevant today.

When to deploy a feature chaser survey

After shipping a requested feature. Notify users who requested the feature and ask whether the implementation meets their needs. This validates that you built the right thing, not just the right idea.

Before building a requested feature. If a feature has been in your backlog for months, re-validate demand before committing development resources. User needs change. A survey confirming that the request is still relevant saves you from building something nobody uses.

When prioritizing a crowded backlog. If you have dozens of feature requests and limited resources, a feature chaser survey helps you stack-rank by current demand rather than historical request volume.

Feature chaser survey questions

Post-ship follow-up:

1. We recently launched [feature]. Have you had a chance to try it? | Yes / Not yet / Did not know about it | Required
2. How well does [feature] meet your original need? | 1-5 scale (Does not meet my need to Exceeds my expectations) | Conditional on "Yes"
3. What, if anything, is missing from this feature? | Open text | Optional
4. How satisfied are you with this feature? | 1-5 scale | Optional

Pre-build validation:

1. You previously requested [feature]. Is this still important to you? | Very important / Somewhat important / No longer needed | Required
2. If we built this, how often would you use it? | Daily / Weekly / Monthly / Rarely | Conditional on "Very important" or "Somewhat important"
3. Has anything changed about what you need from this feature? | Open text | Optional
4. What would this feature need to do for it to solve your problem? | Open text | Optional

Backlog prioritization:

1. Which of these potential features would be most valuable to you? | Rank order or pick top 3 from list | Required
2. Is there a feature not on this list that you need more urgently? | Open text | Optional

How to use feature chaser data

Validate before building. A feature request from six months ago with 50 upvotes may no longer be relevant if users have found workarounds or if their needs evolved. If fewer than 50% of original requesters say the feature is still important, reconsider the priority.

Measure post-ship satisfaction. If you ship a feature and the original requesters rate it below 3 out of 5, you either misunderstood the requirement or the implementation fell short. Either way, you need another iteration before moving on.

Identify unaware users. "Did not know about it" responses after a feature launch indicate a communication problem. If you built something people wanted but they do not know it exists, your release communication needs work.

Refine requirements. The "what is missing" and "has anything changed" questions capture evolving requirements. Feature needs are not static. Continuous requirement refinement leads to better implementations.

Reduce backlog noise. Feature backlogs accumulate requests that never get cleaned out. Feature chaser surveys identify requests that are no longer relevant, keeping your backlog honest and actionable.

Common mistakes

Not closing the loop at all. Most teams never follow up on feature requests. The act of following up, even if the answer is "we decided not to build this and here is why," builds trust and encourages future feedback.

Building without re-validating. Shipping a feature based on 12-month-old requests without checking current demand risks wasting engineering time on something users have moved past.

Surveying too many features at once. Backlog prioritization surveys should include five to seven features maximum. More than that overwhelms respondents and reduces data quality.

Ignoring "no longer needed." This response is just as valuable as "still important." It tells you the problem resolved itself, either through a workaround, a competing product, or changed priorities.

Set up this survey in Formbricks

Formbricks lets you send targeted surveys to specific user segments, which is ideal for feature chasers. Tag users who submitted feature requests and send them a follow-up survey when the feature ships or when you are evaluating whether to build it.

The template includes both post-ship and pre-build variants. Conditional logic adapts the questions based on whether the user has tried the feature or whether the request is still relevant.

You can schedule recurring feature chaser surveys for your backlog items, automatically re-validating demand on a monthly or quarterly cadence.