{"id":9241,"date":"2016-05-03T09:15:03","date_gmt":"2016-05-03T16:15:03","guid":{"rendered":"http:\/\/intercom.com\/blog\/?p=9241"},"modified":"2020-07-30T13:02:13","modified_gmt":"2020-07-30T12:02:13","slug":"product-feedback-you-can-act-on","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/product-feedback-you-can-act-on\/","title":{"rendered":"Product feedback you can act on"},"content":{"rendered":"

First things first: there is no right way for someone to give feedback. But as a professional designer or developer it can be challenging to receive feedback from people who may not have the context or vocabulary to express it perfectly.<\/p>\n

And our definition of perfect will often betray our personal and professional biases. But we should happily take anyone\u2019s feedback any way they want to give it. After that, it\u2019s our job to continue the conversation and make sure we have the right information, and enough of it, to make a good choice on what to change in our products.<\/p>\n

Instead of trying to build an elaborate process for synthesizing feedback, we should get a better handle on what we\u2019re trying to accomplish when we ask for feedback. Then practice, practice, practice.<\/p>\n

Practice with customers. Practice with colleagues. Significant others. Mirrors. Stuffed animals. Whatever. Just practice.<\/p>\n

So what are we trying to accomplish?<\/p>\n

We\u2019re trying to separate feedback that’s contextually helpful from the feedback that we can act on in a predictable and reliable way.<\/p>\n

Contextually helpful information (but hard to act on)<\/h2>\n

There are four types of information that help software designers and developers understand the world around a customer, but don\u2019t help us decide what to build.<\/p>\n

1. Solutions e.g. \u201cAdd a rubberized handle\u201d<\/h3>\n

\"\"<\/p>\n

When considering whether to build a solution, it can be difficult to understand how it will impact other dimensions of the product. Take this rubberized handle. It might provide a better shaving experience, but it will also increase the cost of the razor. If this increase in cost is greater than the value the rubberized handle brings, you\u2019ve lost the customer.<\/p>\n

Until you can confidently understand what value the solution is providing, you can’t compare it to the costs and make an informed choice.<\/p>\n

2. Specifications e.g \u201cGive it a wider blade\u201d<\/h3>\n

\"\"<\/p>\n

Some customers might tell you they want a wider, lighter, or sharper blade. But before you go off and build a wider blade, understand you may be attempting to solve a problem that can be solved in a better way. For example, a customer might want a wider blade to reduce the number of passes over the skin and prevent irritation. In this scenario, a good solution might not be a wider blade at all. A different cream or lotion might address this more effectively.<\/p>\n

Until you can confidently understand the intent behind the specification request, you can’t possibly start to build a good solution.<\/p>\n

3. Needs e.g \u201cMake it more dependable\u201d<\/h3>\n

\"\"<\/p>\n

Customer needs are a notoriously imprecise gauge of what you should be building. One need could actually result in a multitude of different solutions. Let\u2019s say a customer wanted a razor that was more dependable \u2013 it could mean lasting longer, resisting bending, withstanding moisture, etc. If your perception of dependability relates to withstanding moisture while your customer\u2019s perception of dependability relates to resisting bending, you are going to head off in the wrong direction.<\/p>\n

Until you understand the precise dimensions of your customer\u2019s need, you can’t tell if you\u2019re making meaningful improvements.<\/p>\n

4. Benefits e.g. \u201cMake it easy to use\u201d<\/h3>\n

\"\"<\/p>\n

Benefits, like needs, are too imprecise to act upon. A benefit can also be delivered with a multitude of different solutions. Does \u201ceasy to use\u201d relate to the time it takes to finish shaving, the amount of time it takes to put the razor together, or reducing errors while shaving? What is your perception of the benefit? What is your customer\u2019s perception of the benefit? If they\u2019re not the same, progress will be made along the wrong dimensions.<\/p>\n

Until you understand the specific dimensions of the benefit for the customer, you can’t tell if you\u2019re making meaningful improvements.<\/p>\n

Actionable feedback (and contextually helpful, too)<\/h2>\n

There are three types of feedback almost instantly valuable to your product. They might take more work to reveal, but it\u2019s worth it in the long run.<\/p>\n

1. Jobs<\/h3>\n

A job is what someone is trying to carry out. It sounds easy, but can be surprisingly tricky to properly identify. There is almost always a combination of three jobs when people are using a product:<\/p>\n