When to send it
Ask about a feature once people have had a real chance to use it: one to three weeks after release for something used daily, longer for a monthly task. Show the survey inside your product, near the feature, so the people answering are the ones who have just seen it. An inline embed on the feature's settings or help page works on every plan. On Pro, a slide-in on that screen catches people in context without blocking their work.
Before sending, replace "the new feature" in the title and questions with its actual name. People answer more precisely when they know exactly which part of the product you mean.
Why these questions
The first question splits the audience. Some people who see the survey will never have opened the feature, and their answers are as useful as the users'. If they haven't tried it, they're asked why: they didn't know it existed, they had no reason to, it doesn't fit how they work, or they weren't sure how to start. Each answer points to a different fix, from an announcement to better empty screens to a rethink of who the feature is for.
People who have used it rate their satisfaction on the standard five-point CSAT scale and say what they used it for. That second answer is often the most surprising one: customers regularly use features for jobs their makers never planned, and those jobs can shape the next version.
Everyone gets the last question, which asks for a single change. Limiting it to one forces a priority, so you hear about the thing that matters instead of receiving a wish list.
No coupon for this one
Feature feedback comes from people already using your product, and the quality of the answers depends on them caring about the feature rather than about a reward. Keep it short and show that you act on it.
What to do with the answers
Start with the split between "not yet" and everyone else. If most people who saw the survey haven't tried the feature, the problem is discovery, and clearer copy, an in-app tip or a changelog email will do more than design work. Among users, sort the "used it for" answers into jobs and check whether the feature serves the most common one well. Group the change requests and look for the idea that shows up in different words from different people.
Close the loop. When you ship a change because of this survey, say so in your changelog; it's the strongest reason for people to answer the next one. To choose between several ideas rather than refine one, use Feature priorities. For something still in testing, Beta program feedback fits better.