Product feedback you can act on

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.

And our definition of perfect will often betray our personal and professional biases. But we should happily take anyone’s feedback any way they want to give it. After that, it’s 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.

Instead of trying to build an elaborate process for synthesizing feedback, we should get a better handle on what we’re trying to accomplish when we ask for feedback. Then practice, practice, practice.

Practice with customers. Practice with colleagues. Significant others. Mirrors. Stuffed animals. Whatever. Just practice.

So what are we trying to accomplish?

We’re trying to separate feedback that’s contextually helpful from the feedback that we can act on in a predictable and reliable way.

Contextually helpful information (but hard to act on)

There are four types of information that help software designers and developers understand the world around a customer, but don’t help us decide what to build.

1. Solutions e.g. “Add a rubberized handle”

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’ve lost the customer.

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

2. Specifications e.g “Give it a wider blade”

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.

Until you can confidently understand the intent behind the specification request, you can’t possibly start to build a good solution.

3. Needs e.g “Make it more dependable”

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’s say a customer wanted a razor that was more dependable – it could mean lasting longer, resisting bending, withstanding moisture, etc. If your perception of dependability relates to withstanding moisture while your customer’s perception of dependability relates to resisting bending, you are going to head off in the wrong direction.

Until you understand the precise dimensions of your customer’s need, you can’t tell if you’re making meaningful improvements.

4. Benefits e.g. “Make it easy to use”

Benefits, like needs, are too imprecise to act upon. A benefit can also be delivered with a multitude of different solutions. Does “easy to use” 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’s perception of the benefit? If they’re not the same, progress will be made along the wrong dimensions.

Until you understand the specific dimensions of the benefit for the customer, you can’t tell if you’re making meaningful improvements.

Actionable feedback (and contextually helpful, too)

There are three types of feedback almost instantly valuable to your product. They might take more work to reveal, but it’s worth it in the long run.

1. Jobs

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:

• the functional job i.e the using of the product – I want to remove hair from face, legs, or wherever.
• the personal job i.e how it makes the customer feel – I want to feel clean and confident.
• the social job i.e how it makes the customer look to those around them – I want to look professional.

Which job is really driving behavior?

Think about a father using a traditional razor when his son is learning to shave. There’s a personal and social driver to using a traditional razor that an electric shaver just can’t beat. In this scenario, if the father were asked if he wanted a faster-charging electric shaver (benefit), of course he would say yes. Nobody would turn down a benefit like that. But it wouldn’t help him teach his son how to shave. Only the traditional razor solves that job.

It’s not uncommon for designers to identify a functional job, believe they have the full story, and act on it – only to end up making something that nobody uses. Keep probing, even when the story seems to be complete.

2. Outcomes

Great products understand how customers measure value for themselves – how they want to get the job done, and what it means to get the job done successfully.

Whatever value is being measured needs to have a direction (e.g. increase, minimize, etc) and a unit of measurement (time, cost, etc). If you can’t find a specific measurement and a way to use it to indicate progress, it should be a signal that you’re talking about a contextual problem, not an actionable problem.

Here are a few examples:

[ minimize ] [ the time it takes ] [ to prepare the skin for hair removal ]
[ minimize ] [ the time it takes ] [ for a parent to explain the process of shaving ]
[ minimize ] [ the cost ] [ of buying razors for two people ]
[ maximize ] [ the time ] [ between shaves ]

Remember, this isn’t a framework to push people through. Rather it’s a way to probe how someone is measuring their perception of success.

3. Constraints

If you look hard enough, there are always constraints preventing people from getting their job done the way they want to. For example, when someone runs out of shaving cream, they can’t use their traditional razor. Making the razor sharper wouldn’t make a difference. Yet when interviewing customers, constraints are rarely mentioned.

A few simple questions can go a long way to uncovering constraints:

• What needs to be true for this to work?
• Do you need someone’s permission?
• How long does it take for other parties to respond?

Get into the habit of sprinkling these questions into a conversation to probe for constraints. And be prepared to repeatedly slap yourself on the forehead.

Receiving software feedback is hard

If you’re just getting started it’ll be clumsy and awkward. That’s okay. That’s how it is for everyone. If you’re a seasoned veteran it’ll be clumsy and awkward. That’s okay. That’s how it is for everyone.

Just be really clear about what you want to accomplish. Then practice. Intercom can help with your customer feedback strategy!

If you’re interested in digging deeper, the book What Customers Want by Tony Ulwick is fantastic. It goes into much more detail about why certain information is more valuable, how to go about getting it, and what to do with it after you get it.

Main illustration: Shawna X