Handling user feedback as an indie hacker

By James Kenny
5 min read

Table of Contents

When users sign up to use or try your product, getting feedback from these users or potential users can be really helpful. It's a golden opportunity to refine and grow your product. Getting users that are willing to send you feedback is a way to build your ultimate fans.

Getting Feedback

I'm not going to go into getting feedback in this post. There are so many other great resources out there for that. I will recommend one book though.

The Mom Test by Rob Fitzpatrick - I found it a great book for helping me figure out how to talk to users better. Getting a better understanding of what users think.

The Feedback

I do two things here, One I have an email address for feedback but I also have a form in the app.

Send Feedback option in Audience

When I get this feedback, I reply with something along the lines of "Thank you for your feedback, I'm delighted you are trying it out and look forward having you as a customer" I write the email myself so the words will change depending on how many coffee's I had that day, but generally that's the idea behind it.

I will generally read the feedback quickly and decide what group it falls into.

Not all feedback is equal!

  • Paying customers feedback
  • Potential customer feedback
  • Mean / bad / junk feedback

Mean / Bad / Junk Feedback

Lets get this one out of the way first. You will get mean feedback, you will get bad feedback.

You will not get away from this, it will happen but you can put filters in place to try and protect your own mental health and I can't stress enough how important that is.

If it falls into this category, I might or might not reply, but I will delete the feedback and move on.

I am also open to blocking, banning and kicking users. Life is way to short to put up with people like that.

Doesn't make it easy and will usually put me in a bad mood but between coffee, photography and a beach I've found ways to get through that sort of feedback. I might write more about that some other time.

Paying Customer Feedback

Your most important feedback is from paying customers. You will have to make a decision on what is feedback and what's a bug in your product.

How you handle these can be really important, ignoring paying customers will just mean they start looking for something else. Something that has the features they want and good customer service.

Potential Customer feedback

The feedback from users on trials or even before the trial is really interesting. On one hand should you ignore it because they aren't paying for the product. But then the opposite is true, they could be customers and maybe something is missing that could open a whole market for you.

I don't have the right answer for this. From my personal view, if someone has taken the time to send me feedback, I should give them a few minutes of my time to read it.

Is it a bug or is it feedback

So sometimes you will get feedback about a feature that's actually a bug, the user won't know it's a bug they think the feature is supposed to do that. But you will know that's not how you planned it. This has happened to me a few times in the past and to be honest it will happen again.

For me I make a decision if it's vital it goes onto my main list for the sprint and I'll try to fix it as soon as possible. If it's not vital I put it with the rest of the feedback and review it later.

Collecting Feedback

After I take a quick read over the feedback sent in, I reply to them to say thank you and then I collect the feedback.

I use notion for this part. In notion I have a page "Feedback" I copy and paste all the feedback I get into that page. Add a few notes:

  • Who sent it in
  • Are they paying / potential
  • When the feedback was sent in.

Then I leave it there. I should really do an "To be continued" here.

Reviewing Feedback

I don't deal with feedback right away, I batch them up. So I will pick a day in the future and then put that in my calendar and block out a few hours as "Feedback Review".

Then with a pot of coffee at my side, I start at the start and review all the feedback.

First thing I look at is, does this feedback fit in with my vision for the product. I have to admit something here, I have in the past acted on paying and potential customer feedback and wreaked my own products. Sometimes they want features that only they will ever use. So you end up spending a lot of time and energy on something that isn't useful or good.

So now I look at feedback far more critically,

  • Is it in line with where I see the product going?
  • Is it something a few users will be interested in?

So I sort the feedback like that, it doesn't matter where the feedback came from if they are paying or potential. If it fits where I want to go with the product, then it's valuable feedback.

Then I sort the feedback by user type, Paying user feedback is first always.

Roadmap to the rescue

I have a roadmap, as of writing this it isn't public but I do have a road map, I put all the feedback I think is useful onto that roadmap.

But I also look at the features and ideas on the roadmap, I take the feedback and see if they align with any of the features I already have planned or if the feedback will improve something I had already thought about doing, this happens more than you think.

If a paying user has sent in the feedback, it will go top of the list of the roadmap.

Notice I still haven't done any specs or design around the feedback. I find this part is the important bit. Because I take my time and organise and group the feedback around it lets me see how it all fits together.

Sometimes different bits of feedback can all fit together, by reviewing them together with the existing roadmap it helps me get a fuller picture for what users are after and how they see the product being able to help them and give them value.

Thank you for reading. I hope it helps in some way if you have any ideas or thoughts to share hit me up on twitter @jamesmkenny. This post is part of a series I've been doing on how I build applications on the internet, going from idea to a working product. These are mostly just things I've picked up along the way and wanted to share.

Last Update: March 16, 2022

About the Author