User I̶n̶t̶e̶r̶v̶i̶e̶w̶s̶ Conversations by the PMs and for the PMs (#2)
The Hows and the How Nots
Disclaimer: For a better reading experience, I would recommend you spending an extra 5 mins on reading the Part 1 of the blog here, where you’ll find the necessary context that’s good to have for reading the Part 2. Now — let’s dive in!
Right before my interaction with the first user, I was as excited as I was unsure. Excited — because this was my first project as a Product Manager and was a golden opportunity for me to talk to someone who is directly being impacted by the product I am building. Unsure — because of a series of questions. What if the user gets offended by something I say? What if I unknowingly say something that makes the user uncomfortable? What if I don’t know the answer to a question that will be thrown at me from the user side? And the list goes on. Of course, most of it was a consequence of my favourite tendency to overthink a situation, but I mean, some were damn legit doubts/concerns (or so I would like to think!).
My Key Learnings
Finally, all these words now bring me to a place where I can conclude this series of articles with some of my key learnings before, during and after the process of user conversations. Let’s take a look at it one by one —
Before the session:
- Freeze the objective
There can be a hundred reasons to do a user conversation — but you can’t have all the hundred as the reasons for one session. Fixate your reasons — be clear about what you want out of the session. Meet those objectives and bingo, that’s your success metric for the session!
- Plan your users
This was one of the most difficult and time-consuming activities of the entire process for me and also, good learning that I will consciously be implementing when I plan the next series of such sessions. Basically getting the right users for the sessions and making sure that the users selected represent your user base with respect to gender, salary, education, age etc.
- Soft plan the structure of the conversation
The term soft plan is the most important. You don’t want it to be a questionnaire round that has no scope of a “go with the flow” approach. A conversation without such an approach is basically an interview — something you don’t want to do with your users (ref the Part-1 for context).
- Arrange for a comfortable environment
A controlled sound-proof environment works the best for such conversations. You don’t want to overwhelm the user by going extra but you also don’t want to cause any discomfort by going lesser than required.
- One-interviewer-multiple-organisers approach
Trust me — this is a good effort deal. You need to prepare for interviews — logistics, topics, food, permissions, finance etc — and for that, you would need help. Having said that, you don’t want multiple people sitting as interviewers in front of the users as that for sure will overwhelm them. You want to build a rapport with the users and going one-on-one is the best way forward. Again, remember — you need a set of extra hands to prepare such sessions.
During the session:
- Start with easy conversations
Imagine sitting with a stranger in a closed room and the first thing the stranger says is — “What do you think of this product that I made?”. I’d be damned if your first response was not “WTF?”. You don’t want that. You don’t want to be a stranger to the user — for you are banking on them, to be honest, and detailed about what they feel when they use your product later on. Start easy — topics that fill in enthusiasm among the user. And for this — you’ve got to come with your research. Things your users might or might not feel excited about. Use those topics to ease into the main objective of the conversation. (FYI — I spoke to one of the users about how gaming in India is booming, even when I know literally know nothing about gaming— but the good thing is, it worked!)
- Stick to the soft plan prepared
It’s very easy to get distracted and go off-track — but remember to not be too involved in the “go with the flow” approach that you end up discussing random things. Remember, you have got only very limited attention bandwidth of the user which decreases with time — no matter how interesting of a personality you are. So respect the time and effort put in by the user and make the most out of it!
- Let the PM in you take the back seat
This is important. It’s definitely possible that the user might end up not liking a feature you built with your whole heart. Be ready for it before you enter the room. You are not there to provide solutions — you are there to get confused with the user to know the pain points you have to later work on solving after the user conversation.
- Ask for consent to record
Small but an important to-do. You need to ensure that the user is okay with their responses being recorded as part of the user conversation session. Respect their choices.
- Open-ended questions ftw!
Via conducting such user conversations, I learned the importance of open-ended questions for understanding the users better. These questions provide you with dense information as users tend to tell you a story as an answer and that, my fellow PM, is a gold mine!
- Avoid taking notes
While talking to your users, you don’t want any distractions as you speak and emote. It’s important for you to be 100% involved in the conversation and hence, better to record and make notes later, than to pen down your thoughts during the session.
- Summarise and seek feedback
As you reach the end of the conversation, it’s very important that you provide some closure to the user. Ask them how they felt about the session. Thank them for spending their precious time with you. Ask them for any feedback or suggestions or questions that they might have for you.
After the session:
- Put a structure to the information obtained
At end of the session, you will typically have huge amounts of information. Now it is your turn to extract the useful information from all the insights that were recorded. I spent around 1–2 hours after the session just for this and it extremely helped me when I was documenting the results.
- Document the findings
After you have structured the information, document your findings for broader stakeholders in the organisation. What worked? What didn’t work? What to do next? Let the people know what users think of the product they have been working on.
- Let the PM in you take the driver’s seat!
Get that PM back in action — read, process, analyse and act on the information obtained via these sessions. See if you need more such sessions to validate a hypothesis, or are you good to go ahead and implement certain changes based on your findings from the user conversations.
- Look for loopholes and learnings before the next user conversation session
After every conversation, self-introspection is important. It’s important to understand where you could’ve been better, so you know what you have to do when you talk to the next user.
Watch Out For!
To think of it — it would’ve been an interesting scenario where the user asks me a question about the product I am building and I am clueless about the answer, not because I am a bad PM, but because our team never really thought on those lines that the user did. That didn’t happen though — all went fine on that front. But honestly, even if that had happened, I don’t see anything wrong with it. While having such user conversations, I noticed that there are certain things any PM should watch out for. Allow me to explain.
Love for the product
As PMs, we love the product we are building. And rightfully so — we are passionate about it. At times, so much that it tends to blind us to the very evident loophole in our product. And during such conversations, when you get to know of that “evident loophole”, let’s face it — it hurts. However, if you think of it, it’s okay. It’s okay to accept that you messed up. But this acceptance is usually preceded by a state of denial. Wait, this is now sounding like a therapy session — evidently so because we are only humans after all. What even is denial and acceptance in the context of a product? Simply put — it’s about owning up to the fuck ups and learning from them. Another very interesting thing I picked up from my seniors at Refyne is — fucking up is okay, as long as you know how and where you have fucked up.
As we build solutions block by block, it’s normal to get terribly involved in the process. So much that this starts creating a series of biases. And these biases affect our perception of user behaviour and response. It’s important that we consciously make efforts in keeping these biases aside while conducting such user conversations because you would want to come from the most neutral ground ever while trying to get useful and honest insights from the users.
As PMs, we are enthusiastic about looking for solutions to any problems we find. After all, we get paid for that, duh? It’s also very interesting to see how this “healthy” tendency of always looking for solutions can backfire too. When you are sitting in front of a user who is using your product and he/she gets stuck at a flow that has always felt “extremely obvious” to you, there is a huge urge to provide the user with the solution to their confusion. And that dissolves the concept of the user conversations. You are not sitting with the users to help them navigate through your platform. In fact, you are there to do the opposite — to see and let the users get confused/lost in the user journey. And more importantly — understand why exactly they are stuck where they are stuck. Ask them a series of Why(s) throughout the process.
Nah — I missed this during my first conversation and ended up helping the user when I saw them getting stuck at a user flow. I confused the user conversation with user onboarding. There is a very thin line between the two — during user onboarding sessions, you want your users to successfully be onboarded to your platform for whatever it takes, but during user conversations, you want the users to be your product’s best critics for whatever it takes.
Going to sound a bit off but trust me when I say this — if the users are getting stuck in the user flows during such conversations, you are doing good. It’s basically your upcoming quarter projects lining up in the backlog — the projects that can be extremely crucial to your product growth.
Whatever I have covered in a previous couple of articles on user conversations is just the tip of the iceberg. There is so much more to user conversations and user research — in general. I hope to cover that as I get a chance to conduct more facets of such sessions in real life. Until then, ciao folks!