Everybody Has One: Dealing With User Feedback

(originally posted on my Blogger blog)

“A mystic isn’t a special kind of person. Every person is a special kind of mystic.” — Brother David Stendl-Rast

Look at you. You magnificent thing. You are not just the sum of ears and nose and skin and bones and teeth…. You are an inspired being…at least on your best days. You have things that motivate you at work, at home, in the world. You have a vision for who you want to be to your friends, to your co-workers, to your family, and as a citizen in your physical and digital communities.

Much the same could be said of the work you do and the products you build. The hope for those of us who work in the technology space is that what we make will be more than the sum of a reasonably sturdy database, many lines of code, a handful of API calls, and the latest Javascript framework hanging out front smiling it’s biggest freakiest smile at the world. You hope you’re building something that will matter, that will be used and loved and help people accomplish what they couldn’t accomplish before… or as quickly…or as elegantly. As creators, we, of, course need to get past the ugly MVP phase and we want to be responsive to feedback from our users so we can continue to course correct all throughout the product cycle. For that reason, how we take in that feedback is no trivial matter. In fact, if done without care and process it can have monstrous consequences.

So I wanted to share a few tips on how to receive and respond to Product feedback.

First Of All, If It’s Broken Fix It
So they found a bug. Yes, these things happen to the best of us. This should go without saying but if something doesn’t work. Just fix it. The speed at which you fix it is up to you and your team but if something isn’t working the way you intended it to, then you should probably just fix it.

Beware of “People Said” or “Our Users Said”
How many people does it take to turn a feature request into a product requirement? 2? 50? 100? 1 if it the person is a really powerful and monied customer? It’s important to figure out that number and how you will weight and respond to feedback as well as the value of the feature. Implementing a feature or letting one really squeaky wheel get all the grease can make the whole effort run off the rails.Which people said what and when? How big of a deal is it really?

Have (And Continue To Iterate on) A Roadmap
What is the vision for your org? Your product? How and where is it articulated for your employees. Do your devs know what and where it is? Nevermind whether they care.

This vision for where you are trying to go and/or who (you hope) you are being and what (you hope) you are doing is hopefully clearly typed out somewhere and is given legs through your roadmap, which should be a living breathing document that all the team can access and have some input on.

While not set in stone (see: bug fixes, market forces, new! hotness!) that document should be your guide. Our intrepid devs should be allowed and even encouraged to tinker, but it is helpful to reiterate priorities. How does this align with what we’ve said we really want to do/ be doing? Revisiting that question is crucial, because you really don’t want to get hung up implementing something that you don’t wanna do but then feel you *have to* do because someone spent all weekend hacking on it and now it’s built and it looks like it works. Is this something you *really* want or need or is it just something that can exist in a feature branch and visited at a later date?

Your Backlog Is Not Your Roadmap

Oh, the backlog! Depending on how well your backlog is managed, it can either be Easy Street or a Boulevard of Broken Dreams. A jumble of half-formed ideas and rambling fever dreams. I can’t stress enough that your roadmap needs to be more than a shoving together of Stuff We Didn’t Do Yet but rather a cleared out path of Where We Want To Go. Your roadmap can certainly be stored in your project management tool but it is not just an export of The Undone.

Don’t Just Say Thank You
So you know better now. You aren’t going to just let your product be a plastic bag blowing in the wind of customer whims. You have a vision and you’re going to stand up for it! So how *do* you respond to product feedback/feature requests then? Do you dash them off with a one sentence email and a thank you? Well, I certainly hope not. In her excellent book, Lean Customer Development, Cindy Alvarez suggests asking users:

“ If you had (requested feature) today, how would that make your life better?”

I also like “Can you tell me more about how (highlighted issue) is a blocker for you?” as well as “How are you working around the lack of (requested feature)?” Product feedback and feature requests give us awareness of a potential issue. Asking a question like one of the above gives us understanding. Only after we have awareness and understanding should we feel equipped to chart a course of action. Springing into a flurry of whiteboarding and keytapping can be perilous without stepping back and truly finding out what the user is trying to accomplish and why.

Get Customer Success
Feel like you don’t have the time or bandwidth to tackle the growing pile of feedback and feature requests? Well then I highly suggest you engage your customer success manager/ team! Don’t have a customer success person/team? Well then I highly recommend checking out this post from the excellent Support Driven blog to get your awareness and understanding of this crucial role at the intersection of product development, customer support, account management, and user experience.

Together we can keep these visions alive!!