The Ego and the User Interviews

✨ Hi, I’m Sara Tortoli and this is the 1st edition of The Plunge Club, a monthly newsletter dedicated to product and human tinkering.

If you are not a subscriber yet, you are welcome to take the Plunge and join the Club:

On the Ego and the polyamorous nature of problems

I have a love-hate relationship with user interviews. Even though I have done my fair share, both as a Product Manager and for personal projects, including on Product Heroes YouTube Channel, I still approach the task with a sort of sacred fascination drenched in dread.

My ego had lots of issues dealing with user interviews. Because I spent so much time trying to improve the products I managed, I formed an emotional attachment with them. If I was not a little bit in love with the product and with the problem that it solved, then I couldn't be the Product Manager. I wanted users to like my idea and get excited about my product as much as I was. When they didn’t, I felt hurt and even rejected sometimes.

One day I finally figured out the way out of this. It finally sank something that my mentors have been telling me all along and that I could not understand because my ego was too big.

I was in love with the wrong thing. I needed to fall in love with the problem rather than the solution. I also finally saw how my identity was not tied to any particular solution, so that I could stop identifying with it.

Problems are so much more fascinating than solutions. Problems are polyamorous. One problem can have multiple solutions, they don’t feel the slightest jealousy, unlike solutions. Solutions want to be monogamous, they try to capture the problem in a net, and because of this they often end up discarded like boring lovers after a while.

Whenever I get lost in my head and narrow my attention too much on a solution, I now go back to the simple question:

Therefore, when conducting a user interview, I separate problem from solution interviews. The division is pretty straightforward:

• In the problem interviews, you ask users about their problems. The solution doesn’t matter; the problem is what matters. In fact, you don’t even mention the solution; you are totally oblivious to it. Problem interviews are especially useful during the discovery and ideation phase of a new product or idea. Also more mature products can benefit from it. Going back to a problem interview every once in a while is a healthy sanity check that you are going in the right direction.

• In the solution interview, your goal is to get feedback on your product. If you don’t have an actual product yet, you can show a prototype. The point is, you need to have something to show instead of asking users to use their imagination.

The only secret to successful user interviews: becoming egoless

User interviews, or any type of interview, are effective shortcuts to learn more about yourself and human nature in general.

I put a lot of time and mental preparation into an interview. It feels like I am preparing to go into battle. The opponent is my ego, which I battle every single time.

I can summarize the object of contention that arises in every interview in 3 questions:

1. How do I ask the right question, even the scary ones that I don’t want to ask?

2. How do I actually listen to what the user is saying with genuine openness, without injecting biases in the interpretation?

3. How do I avoid the vanity trap, guiding the conversation where I want, to assuage my ego?

In other words:

User interviews have been more effective than meditation in becoming more present and aware. This is because to succeed in an interview you have to:

1. Live in the present moment and actually listen. I stop thinking about myself, what I am going to eat for dinner, about the email I got from my boss, or about what I am going to say next in the conversation, as it happens sometimes when I am talking in my day to day life. In an interview I am fully present, I do not exist, and the person I interview is my only focus.

2. Face my fears and ask the scary questions. You know that question you are really, really afraid to ask because it might destroy all your assumptions? That’s the one you need to ask 😉

3. Be open to change without getting attached. No matter how much I love my idea, during an interview I have to set it aside and accept the fact that it might get trumped and destroyed in seconds. I need to put emotional distance between myself and my thoughts.

Interviews are mentally exhausting and incredibly enriching at the same time. They force you into an unnatural state, where you try to disappear and only focus on someone other than yourself. When you do, magic happens.

⚠️ A word of caution. This magic does not always score in your favor, especially when you realize that your idea is not a good fit for the problem. Still, doing your research before building anything will save you from enormous pains afterward. It is still a win even if it might not seem so at the beginning.

But cheer up, from any idea that gets killed during a user interview, another improved, shinier version pops up to replace it.

How to set up a user interview

To illustrate how to set up a problem interview, I will take as an example an interview I did recently on self-tracking and enhancing health.

Step 1: write the objective and the hypothesis

1. The first thing when setting a problem interview is defining the problem you are after. What are you trying to solve? Since this is a problem interview, you don’t need to have a well-defined solution yet. In fact, it is probably better if you don’t. What you need to validate is if indeed you are chasing after the right problem.

2. Who are the people that feel this pain? Can you narrow down a niche? Where do they hang out? Once you figure this out, start hanging around where they are to get a better idea of what they are talking about and what “keeps them up at night”.

3. Set some operational hypotheses regarding the problem and how you think your users are currently solving it. You can also add how your solution will help, however, don’t get too attached to what you have written. As it happened to me, after the user interview I found out I was off on the wrong path and had to start all over again 😩

Below an example of how I set objectives and the “hypothesis space” in Notion.

Step 2: how to ask the right questions

This is the most important and the trickiest part of all. In the end, it all comes down to the question you ask and even more on how you phrase your questions. I spend a lot of time thinking about which question I want to ask. I rephrase them multiple times before I get them just right.

This is because the quality of the answers you get depends on the quality of the question you ask. This is where the ego usually sneaks in. Since we are afraid to have our hopes crushed, we craft the so-called “leading questions”. Leading questions are questions that already imply that there is a right answer to give, like asking “will you pay for my product?” with huge puppy eyes 🥺. The other person is going to say yes even if he/she doesn’t want to.

There are a few cardinal rules in user interviews and in phrasing questions:

• Ask open-ended questions, rather than yes or no questions.

• In a problem interview, only try to better understand problems and current solutions. Don’t look to validate your own.

• Keep in mind the objective of the interview, what you are trying to validate.

• Ask one question at a time.

• Ask about their stories in concrete examples. This is where the best answers are usually hidden

Good questions might start with something like “can you tell me about a time….” “do you remember…..”, “what did you do in that particular situation?”, “Why did you do it?”, “Can you walk me through…..”

Below a snapshot of some general questions to ask. Also, a book that I usually recommend on the topic is called “The Mom Test”

Step 3: Finding users to interview

I usually find users to interview in Facebook and Reddit Groups dedicated to the specific topics I am trying to validate. I look for people that are active in the community, that comment on posts, and that are asking for advices on how to solve the problem. I would then send them a private message along these lines:

Hi ……, My name is Sara and I am a fellow {name of the group} from Berlin, nice to meet you! I saw your replies to a post in the group regarding {whatever they have posted about} that I found very insightful. I am a Product Manager and I am conducting a user research to validate an idea that {describe your idea in 2 lines max}. I would like to know more about your difficulties, victories, and your story as a …… I believe you have extensive knowledge on the topic and would love to learn more from you! Would you be up for a short video call? If yes, let me know a couple of days/times that it will work best for you, and I will arrange all the rest!  

Step 4: The interviews

Here are a few tips for the actual interview:

• Record all the interviews and ask for permission before starting. This is very useful because you don't have to worry about taking notes and you can fully focus on the interviewee.

• Ideally, interview with another person: one acts as the actual interviewer, the other acts as the note-taker.

• If possible ask users to share their screen to show you their workflow/method.

• Be there. You don't have to do anything, your only job is to listen with an open mind. As I mentioned above, become egoless.

After the interview, I set aside one more hour to go back to the recording and start taking notes. If I performed the interview with a note-taker, we debrief while our memories are still fresh.

Step 5: Putting all together and gaining insights

I usually perform anywhere from 10 to 20 interviews. It is a mentally intensive and time-consuming process. Between the actual interview and the debrief it takes me almost 2 hours. Why bother then? Because it is important to gather a reasonable amount of interviews to try to spot patterns and trends to prove (or disprove) the hypotheses. As it turns out, the disproving part happens quite often. It's best to spot this early on, instead of committing to build something users don't want.

To put all my findings together, I use a Miro board.

Step 6: After the interview

A problem interview has 3 possible outcomes:

1. The hypothesis is rejected and you are back to square 1. In this case, you need to formulate new hypotheses and start again with other interviews.

2. Your hypothesis is partially proved however you need to reframe some elements. In this example, I realized that while the problem is real, the angle I had in mind to tackle it and some of the underline hypotheses were not quite right. In the process, I also realized I was not the right person to solve the problem that way. All of this without 0 effort in actually building something.

3. Your hypothesis is proven and you can move on to the next stage 🎉

If you are curious about what the mysterious “next stage” is, I will write about it in another issue, while I progress with this project 😉

The “Now” section

🎧 What I am listening to: Ricardo Semler on an old Tim Ferris podcast episode.

My key takeaway: we are focusing on processes, on the “how-to”, instead of the wisdom of things and the deep why. This goes for both business and personal life. “How-tos” are fine as long as we still keep questioning the deep why and the wisdom behind things. A simple way to look for wisdom is to ask ourselves 3 times why, starting with our daily habits.

📚 What I am reading: Radical Acceptance by Tara Brach. Despite the new age title, it is a very solid book on how to cope with our shortcomings.

🥁 What I am doing: I almost completed the Udacity Data Product Manager Nano Degree Program. I found some modules to be interesting, while others were a bit slow. I still need to complete the last assignment.

🧐 Question I am asking myself: I believe that the ability to come up with better questions to ask ourselves is the key to self-improvement. Every night, before I go to bed, I ask myself one question. Lately, this is the question that I am asking myself the most, which I got from Tony Robbins:

This question is designed to investigate unhelpful behaviors that we carry from childhood to adulthood.