I've found customer research helps me improve product in three ways: It allows me to say no to stuff, it helps me map out the problem space, and it defines useful criteria for a solution.

It's easy to get lost when you're building features. Grounding yourself in your user's perspective can let you know when you're barking up the wrong tree.

For example, at Chirr App we let you compose twitter threads. We were considering modifying Twitter's tweet box with our chrome extension so that you could write threads inside the Twitter interface. After speaking to people and listening to how they use our product, it became clear that people value creating content without the distraction of Twitter.

Modifying the native tweet box was easy to get excited about. It sounded like a wicked idea. If we invested a chunk of time into making it happen, we would have let all our lovely users know that we're completely disconnected from how they use our product.

I also use customer research to map out the problem space. It's easy to focus on solutions, people instinctively do too much of this in product teams. Sometimes you need to be able to put all your solutions to one side and ask what problems people care about.

When I process discovery interviews I have four columns: insights, opportunities, verbs and one for my primary research question. Verbs are the things people talk about doing in a product. If clusters or themes begin to appear then I pull the out into their own column.

For example, if 7 of the highlights in the verbs column are about 'editing' then I will make a new 'editing' column and move everything over. Then I rename the tags to describe what it is about the editing experience they're highlighting (it's slow, there's no-redo button, needs autosave, wonky placement, etc).

A blurry example from a real project so you can see how transcript highlights get organised into columns .

This means there's always a place I can turn to when I want to know what customers care about. Instead of worrying about whether we're going to build this feature or that one, you can look at the problem space and see that people think of the product in terms of searching, reading, sending and highlighting. This perspective lets you have a conversation about which one of these experiences you want to improve next. Mapping the problem space makes it easier to think of product improvements in terms of outcomes to the end user experience. 

This isn't some kind of formula, There are always business constraints and realities you have to work within. Having the problem space mapped out and being able to talk about it makes it easier to balance a business-needs-only approach with the stuff your users care about.

Let's say we've decided that the search experience makes the most sense to focus on next. Now we have a list of all the points of friction in the current search experience. Each of the highlights in the "Search" column is a rough edge a real person brought up in conversation with you.

When you don't understand the forces acting on a problem then you inevitably end up casting the net wide. The idea is that if you cover enough territory you're bound to solve the problem. A wide net means building more stuff, which means more moving parts, and that means more things to maintain. You know what I'm talking about.

Understanding all the places people butt up against the current experience exist means I can reference them when I sit down to work on a solution.  I'll add all the feedback I can get from the customer support team, mix it with any business requirement and I end up with a diagram of all the forces that I know are influencing the design space.

To make this less abstract here is an example from an old project where I was improving the search experience.  Some of the nodes here are a customer feedback, some are direct quotes from interviews and other bits are business requirements. All these forces influence what will ultimately determine a good solution.

Once I have all my bits the next step is to figure which bits to focus on first. Jason Fried has a lovely essay where he talks about the obvious, the easy and the possible. I am yet to discover a better way of thinking about the tensions at play here.

You can't make everything obvious. The more things that are, the less obvious they become. As a general rule, the more often something happens, the more obvious it should be. Stuff that just needs to be possible can be tucked away.  Work on figuring out where the easy stuff goes once you've dealt with the obvious stuff.

This is me half way through a design solution that has addressed the most important bits.

A solution won't always address all the forces. It's good to be aware of which elements are not addressed. Sometimes they don't need to be, other times you can pick them up in a separate sprint.

I decided not to address two of the know forces in the final solution I came up with.

Without understanding these forces, you have no criteria by which to judge the success of a solution. Listening to people and documenting what they care about lets you reference the important stuff when you need it. Rich context like this is the antidote to a messy scope. You can stop speculating about X, Y and Z because you know exactly what to include and what you can safely omit.

That's it, that everything I have to share on my journey so far.

Customer research helps you improve products by helping you say no, mapping out the problem space so you can direct your attention towards meaningful outcomes, and by defining clear criteria for solutions.

If you've been speaking to people and then not having a way to connect the research to the product roadmap, hopefully some of this will help you think about ways you can organise your research so that you can rely on it to make better product decisions.


These Hey posts are thoughts-in-progress, they're meant to be conversational. Let me know what you think. Replies to this email go straight to my inbox.