Product managers and user research

Eadaoin Doherty

Eadaoin Doherty

Product. Pilates. Soy chai lattes.

I love working with designers, particularly during the discovery phase of a project when we’re doing user research. My skills as a product manager are different but very complementary to those of a designer. I delight in how the collaboration of a product brain and a design brain will always give a better outcome than just one of those brains going solo. However, the reality is, sometimes product peeps have to go it alone when doing user research.

There are several reasons this may happen. It might be because you are a founder in an early stage start-up and you don’t yet have a designer on your team. Or, it might be because your designers are busy on other projects and you can’t get their time when you need to do your research. Or, it may be because there is so much user research to do that you and your designer are going to share the load and you are picking up some of the tasks.

Whatever the reason, I want to reassure you that as a product person, you can do this. Granted, you probably aren’t going to be as ace at this as a designer, but you can still get some really valuable insights by following some basic rules.

At Cogent we have a team of extremely talented designers who are all experts in user research techniques. Here are a few of the guidelines I now follow, thanks to their expert tutelage.

Set a clear hypothesis and base your questions around that

The aim of user research is to learn more about your users, so you can build a great product experience for them. To ensure you use their precious time to maximum effect, you need to be clear about what you want to learn from your research. You’re sure to have a few ‘hunches’ that you need to learn more about, for example, you think you understand a certain user behaviour but you need to validate it, or you think you know what users will value the most about a product, but you really need to check you are right. Once you have identified an assumption you want to validate, take time to write a clear hypothesis you will test during your research.

Gitlab give a great explanation of how to write a strong hypothesis here 

Once you’ve settled on your hypothesis, base all your research questions around it.  Ideally, you should speak to between 5 and 8 people from each user group.

Be concise

I learned this tip with regards to wording in the UI, but it also applies to creating your research questions. Make sure your wording is concise and easy to understand. I worked with a designer recently who was constantly asking, “Is that word really necessary? What is it adding to the users’ understanding?”. She kept stripping out words that weren’t vital to the message; For example; “your car is currently charging” became “your car is charging”.

This focus on simplification was a good lesson for me, but it comes with a couple of health warnings; don’t simplify so much that you are removing required information and causing confusion. Don’t spend too much time on this, don’t let perfection be the enemy of good. A great way to check if your questions make sense is to test them out with a team member or colleague before running your interviews.

Start the discussion with the practical stuff

At the start of user interviews, it’s important to make the interviewee feel comfortable and to help them understand there are no right or wrong answers. Make it clear that you are asking questions to help you improve your product and that you really value their input. 
Give them a rough idea of how the conversation will be conducted, for example, “I’m going to ask 10 questions”. Make sure questions are open and feel free to explore their answers. Tell them how long the discussion will take (never interview for longer than an hour) and ask if they have a hard stop time, so you can finish a little earlier if needed. It’s great to record these sessions so you can listen back later to gather insights. Make sure you get permission if you are going to record. The recording also means you can take fewer notes during the discussion. You can note down the times of particularly good insights which helps you find them faster when listening back to the recording. Always start and end interviews with some general chit chat and always thank people for their time. 

Don’t ask people what they would do, ask them what they actually do

It’s very tempting to ask questions that will simply give you the answers you want to hear. This is dangerous when doing user research. You’ve got to truly understand user behaviour, and the key to this is to not lead the interviewee.

For example, if you ask the question;

‘If you were rewarded for walking to work, would you do it more often?’.

People are likely to answer “Yes”. This is due to the acquiescence bias, which is when an interviewee responds based on how they think you want them to respond. People sometimes have a propensity to agree with things so that they avoid the perception of disappointing people by saying “No”.

Also, saying what they might do, is no indication whether they really will do it.

The best indication of what people might do in the future is what they do today. So change your question to investigate their current behaviour instead. For example;

‘Do you walk to work? Why do you choose walking over other modes of transport? Do you use any apps today that give you rewards for using it?’

Understanding current behaviour will help you uncover if your product would fit into their current lifestyle. And more importantly, if it will solve some of the issues they face with the solutions they use today.

Playback your insights with confidence ratings

After you have done your research, the next step is to review the data you’ve gathered and present your findings back to your team and stakeholders.

There is often a large amount of information to digest before sharing it with your team, and I find a great way to absorb it is to create a matrix. All the questions along the top, all the interviewees down the side. Fill in the responses you got from each interviewee to each question. This is a great way to spot patterns in the responses.

A question/answer matrix can help you spot patterns in the research.

When you’re presenting insights back to your team, it can be beneficial to include a confidence rating with each insight. The confidence rating is an indication as to whether you feel you have done sufficient research in this area, or whether you need to do more. For example, your scale could be;

  • High confidence rating – the same message is coming through in most/all interviews. No further research is required at this time.
  • Medium confidence rating – there is a strong trend coming through, but a little more research would be useful.
  • Low confidence rating – there were some interesting comments made about this topic, but more research is required.

Show your confidence rating with each insight.

Keep practising, keep learning

Not having a designer to lead your user research activities is no excuse to miss out on this vital part of product discovery. Doing user research as a product manager can seem a little daunting at first, but following a few simple guidelines, it can become fun.  

There are lots of resources available to help you with this skill, here are a few:

Want to learn more about what great user research looks like? Get in touch with us 🙂

Liked this post? Share it on…

Share on facebook
Share on twitter
Share on linkedin

Related posts

Scott Rogers

Mapping Team Effectiveness

Having worked with hundreds of product teams in organisations of many shapes and sizes, we’re in a unique position to understand many of the challenges teams face, as well as the ways they might improve. One of the tools we use to identify how teams are working and what might be holding them back is the Competing Values Framework.

Read More