In response to my blog post about taking feedback, Bryan started off with the following:

Reading your post about how some developers can’t take “constructive criticism” or as you wrote, “feedback,”

I view “feedback” as a superset of “constructive criticism”.  Not all feedback is constructive (nor, of course, is it criticism).  Regardless of whether the feedback is positive or negative, or whether it’s critical or supportive, you’ve got to learn how to listen to it and decide what to do about it.

Listening to feedback and figuring out what to do about it is my job as a researcher.  I do this all day, every day.  Some of it is formal and follows a research methodology; much of it is informal, simply listening to the zeitgeist, understanding it, and applying it when it comes time to do more formal research.  If you don’t have the luxury of having me around, there are some researcher skills that can help you in listening to and acting appropriately on feedback¹.

Negative feedback hurts.  This is true whether or not it’s constructive.  We want to do well.  When we’ve worked on something, when we’ve poured our blood, sweat, and tears into our application, we want that work to be recognized.  If the feedback is constructive, it’s somewhat easier to take to heart.  If the feedback is just of the form YOUR APP SUCKS, it’s easy to blow it off.

For constructive criticism, you probably have less work to do to try to understand that feedback.  The person giving you the constructive criticism has taken the time to consider what they’re experiencing and how to share that message with you.  You probably still have an emotional response to the constructive criticism, and that’s yours to deal with.  After you’ve dealt with that emotional response, deciding what to do about it is easier because the other person has already done a lot of the work for you.

When feedback is negative, you’re hit with a double whammy.  You’ve got your own emotional response to deal with, and you don’t have a clear path forward.  To be more accurate: you have one obvious path forward, which is to blow off the feedback.  After all, if someone is just telling you YOUR APP SUCKS and you’re pretty convinced that your app doesn’t suck (and how could it? you’re poured your entire being into that app!), blowing it off isn’t hard.

Blowing off feedback because you don’t like it is the wrong path.  Constructive criticism takes time and effort on the part of the person giving it to you.  You can’t reasonably expect that everyone who uses your app is going to spend that much time on it.  You get much more feedback than you do constructive criticism.  Constructive criticism doesn’t tell you the whole story, it only tells you the story from the people who are so invested that they’ll tell you what they perceive is their story.  There’s much more out there.  You want the whole story, so you’ve got to find out why you’re getting the YOUR APP SUCKS feedback.  You’re going to have to do a lot of work to understand what that feedback means and what you should do about it.

This isn’t to say that you act on all feedback that you get.  There are plenty of great reasons that you won’t.  When you don’t act on feedback, you need to be able to both clearly articulate the problem that’s been shared with you and why you’ve chosen not to do anything about it.  Own this, and love this.  Knowing what you won’t do is powerful, and is ultimately part of you making an awesome app.

Taking the time to consider feedback will help you make better stuff.  You have to let go of your ego, and you have to dust off your detective skills.  Feedback is a gift.  Take the time to unwrap it.