Everyone who makes products knows one thing: That to make them awesome we have to talk to our users.

It’s how we understand their problems and how we make sure we’re solving them. It’s how we identify opportunities and how we validate them.

It’s integral to the way we work at Made by Many.

But how do we make sure we’re learning as much as we can from our users? And that we’re applying what we’ve heard in the right way?

With that in mind, here are three questions you should be asking yourself, before you book your next round of user interviews:

At the very start of a product’s life this can be an enormous list — we’re looking to uncover what we know, what we don’t know and what we’re not quite sure about.

It can be things like: What’s the biggest problem facing our potential customers? Who are our potential customers? How much might they pay for this? What even is this? Is this a good idea? What are they currently using to solve this problem? How do they feel whilst dealing with this problem?

As we get further into a product’s life, these questions can become more granular: Do users understand how this feature works? Do they like the name? Should it feel more like Snapchat or more like the New York Times?

No matter what your questions are, it helps to get it all out there by working with your team to list all of your questions, assumptions and hypotheses — before leaping into your research.

There’s one question I always have in mind when planning research:

“What do we need to learn in order to make progress?”

Sometimes, we actually have everything we need to make the next step, in which case identifying that now is not the time to speak to users is a valuable realisation.

More often we do have something to learn.

These can be our biggest and riskiest questions; the things that are causing contention and long discussions in our team; or where we need more evidence to help decide between two divergent routes for our product.

The important thing is that you should be clear about how you want to use whatever you want to learn in the short-term.

The outcome of your research should be something that can immediately prompt action. It might take the form of insights, design principles, how might we questions or just give us certainty that we’re making the right decisions.

Importantly, nobody wants to finish a round of research, only to still not know enough to make progress.

Thinking about your learning objectives in this way can also help to ensure that you don’t bite off too much at once. In most cases, the more focused your learning objectives are, the easier it’s going to be to plan, conduct, make sense of and apply your research.

It’s only after figuring out what you need to learn now, that you should start thinking about how you go about learning it.

Picking a method could mean choosing between depth interviews, co-creation workshops, home visits or observational studies. Equally, it could mean thinking about meeting with experts, surveys, data analysis or multivariate testing.

The right method will depend on the questions you’re trying to answer. We have a whole arsenal of tools we can use in any given scenario — and we should always be picking the right one for the job.

Whatever you end up doing, or making, it’s worth remembering that you’re designing something to help you learn — not what you think the full, final answer will be.

This might manifest in pushing an idea to an extreme in order to get a reaction, or if you’re making a prototype only focusing on enough of the experience to answer your questions.

Focus on doing the minimum amount of work needed to learn, and remember that in many cases the thing you’re making — whether it’s a prototype, sketch, or simply a set of post-it notes to be sorted — is just a prompt to conversation.

Hopefully, at this point, you have a good idea of what you’re trying to learn, and how you’re going to apply that learning to turn it into action — but it’s always far less painful to think about how you’ll be capturing your research ahead of time.

Personally, in the case of user interviews, I’ll nearly always capture verbatim notes as a starting point (with audio or video as a back up). You never know what unexpected things you might learn from seemingly irrelevant conversations.

Just because you have a learning focus, doesn’t mean you shouldn’t remain curious and open-minded about what you're hearing.

Once you have the full notes — you’ll then want to think about a structured way to approach interpreting your data. My preference is keeping things off screens, making it visual and getting everything up on a wall that allows you to sort, group and see patterns more easily.

The important thing is, that by having an idea of how you’ll approach your synthesis from the start, and knowing why you're doing it in the first place, you can make sure you’re getting the most out of the time you’ve invested in learning (and making your product awesome).