Talking to your customers is one of the most effective things you can do to grow your business. This is very common advice, and it's very good advice. But it's incomplete.
These people bought your product - your demo, marketing, and their overall experience was good enough to get the sale. Whatever feedback they give you to improve that process won't push the needle very far.
What will push the needle is talking to people who went to the trouble of trying your product and then didn't buy it. People who tried it and couldn't figure it out, who wanted it to do something it couldn't do, or who wanted it to do something it actually can do but they didn't know that it did. Those are the users you need to find and talk to.
How do you do it? Capture email addresses for users who demo your product and then personally email everyone who didn't buy. And then turn your product into one they want to buy.
The general idea is very simple - set up a form to collect their email, and then set the form to redirect to your product demo. There are a lot of forms plugins out there, and I'm pretty sure you can do this with any of them:
1) Create a new form with an email field
2) Set successful form entries to redirect to your product demo
3) Add the form shortcode to a page one your site.
So, now in less than a minute you are capturing emails for every single user who tries your product.
Wait about one day, and then go through Gravity Forms and check every single email address against your ecommerce software so you can make a list of everyone who didn't buy.
It helps to have a boilerplate email you can send to people, but don't get carried away. Keep it simple and natural.
Here's an example of the kind of email you should be sending:
I saw you tried out WP All Import but didn't end up buying it. What were you trying to use WP All Import to do?
We are always looking to improve and love getting feedback from users.
There's three sentences in there. The first one provides context - why are you emailing me? The second sentence is our question. And the third sentence assures the reader that this isn't a sales pitch, we aren't going to try to convince them why they should've bought our product.
That's all you need to do.
After you send these emails one of three things will happen, listed in order of likelihood:
1) They won't reply.
2) They will reply with 1-3 sentences.
3) They will reply with 1-∞ very detailed and enthusiastic paragraphs.
Don't worry about #1. Take every #2, read it over a few times, and then email back a short thank you, or maybe 1-2 follow up questions. For #3, skim it and don't bother sending any follow up questions. You already have more than enough information from them.
When you read these emails, here's what you want to pay attention to:
1) Things they want to do that your product can't do
2) Things they want to do that you product can do but is bad at
Ignore pretty much everything else.
What you want to do is identify the problem they had that your product wasn't able to solve. Do your best to ignore feature requests and small improvements. Take a step back and focus on the big picture.
Somewhere in your project management tools or notes you should have a list of tasks or features that you want to implement in the future, a product roadmap. After you've read someone's email and identified the problem they had that your product couldn't solve, go to your roadmap.
First, check over your existing tasks - would any of these solve their problem?
If so, open the task and read through your notes on how you want to implement it. If one of the user's problems would be solved by this task, great. If not, add some notes to flesh out the problem your user had.
If there is no existing task that would solve their problem, don't bother creating one. Instead, create a task that is a vague description of their problem. Eventually you'll understand this problem well enough that you'll know exactly what to build. But in order to get there you have to focus on the problem they're having.
So, now we have a list of tasks and a list of vague problems. Don't bother coming up with a system to quantify how important each task is, or get too caught up on numerical data. If you read these emails a couple times a week it will be painfully obvious what you need to do next.
You'll open a new email and before you actually start reading it your brain will identify enough keywords for you to know exactly what problem they ran in to and exactly which feature you should implement to solve it.
When it comes time to build out these solutions, the specs will write themselves because you have heard people complaining about it over and over and over again. It will feel like common sense.
Very often you'll find that the solution you end building was never actually requested by anyone. This is why you want to focus on the problems people are having. If you do that long enough the solution will be obvious to you. This doesn't mean that your users are stupid and their ideas are stupid, it just means that they don't have enough data to come up with a solution that will solve anyone's problem but their own.
And all of this starts by talking to users who tried your product and didn't buy it.