Talking to users – but how? – Part 3

The previous blog post took care of the differentiation between a “vitamin product” and a “painkiller product”, as well as pointing out how important the right team mindset is for the success of the product. It can be crucial in distinguishing between the success or failure of a product or idea.

Quick link list for all parts:
Mindset “I am the User” – Part 1
Your Product is a Vitamin Or Painkiller? – Part 2
You are reading this: Talking to Users – But How? – Part 3
‎We Made our Homework – What Are the Next Steps? – part 4

This third part deals in more detail with the question of “How do I approach the user?”.

First things first: Find out where you are.

Not every product can be (re-)build from scratch. Don’t panic. There are possibilities to get the product back on track. Your first responsibility as a product manager is to find out where the team stands. Make it your priority to check in regularly and find out how well every member of the team actually knows the user. This knowledge is essential for every person who is participating in building a piece of software for active users with the intention to use it regularly.

Does the team know who the user is, what she/he likes and dislikes, how often does the team talk with her/him and how are you improving the user’s experience? I do not necessarily suggest that every single team member needs to personally speak to a user, but at least one person has to. If everything is happening on paper with pure team imagination, the product will be created for an imaginary user group as well. Every person of the team, at any time, should be aware of the user, who they are creating the product for.

A quick visualization might support the findings. On the left, list all fundamental items the team needs to be able to answer. On the right, list all known answers. The following example uses a coloured indicator for “OK” (green) and “need of improvement” (red). The visualisation is kept very basic for a clear and simple understanding. It shows a possible method to find out if

1. there is an answer to every question
2. the answers are sufficient
3. the need for optimization has been identified

Depending on the answers, optimizations are determined either collaboratively within the team or with the user. Whereby the best case would be a clarification with the user, because the user mainly uses your product, not you or the team.

Creating roots: creating personas and using other tools.

While creating personas for a product, most teams think mainly about possible user scenarios and invent character patterns which rarely include real and authentic user feedback. Because they don’t know a real user. Neither intention, nor motivation behind the user’s action to sign up for a product or quit using it after all. Knowing hopes and dreams, or what the user likes and dislikes, will provide a clearer decision base. Implementing a couple of methods correctly can change that and will moreover support the team’s daily task efficiently.

I am happy to list some of those methods. Please use the comment section below, if you want me to dig deeper into one and include my experiences.

• Creating mood boards (satisfaction surveys) to understand the emotional level of users, e. g. empathy maps . They can be an additional tool for your product with the focus of one person’s feelings and actions. Creating empathy maps allows every single participant in the process to empathize with every single user. For one of my past teams, the empathy map opened the door to feel a deep connection to the user and they even thought about the user when writing code and testing the increment.
  What do empathy maps look like? They contain four quadrants with the user in the middle. Each of the quadrants contains a characteristic, which allows the product team to get a deeper understanding of the user’s mind. They reflect on what the user says, thinks, feels and does.
• 5-Why-Method to understand the motive of the user. This method allows you to understand the main reason or motivation behind actions quicker and therefore creates a deeper understanding of the user. But, be careful when using this method. Market research shows that the word “why” is allegedly understood as a challenge to the user’s decision. Negative bias is definitely not what you want to aim for at this point. Consider rephrasing as “What motivated your action?”, “What was your intent?” or “walk me through the process”, “Tell me about your experiences”.
  The main point is to go deeper into each question or request until you find the core motivation or reason for the user.
• Using NPS (net promoter scores) to measure the user satisfaction could be another option.
• A/B tests to understand the cognitive level of users and the willingness (readiness) to learn new things.
• Surveys and voting to understand the user’s point of interest.
• Different tracking methods which are set up to answer your open questions in order to allow you and the team to complete the persona.
• And many more…

And because personas are so important, some more thoughts on them.

By creating an imaginary friend, you and the team have an anchor point to get inside the user’s head and behavior (habit) at any given time. Personas will help you understand your target user, as well as it’ll help you understand edge cases even better. Software does go live without even thinking about possible edge cases. It happens, I have seen it. To answer the big “why” (“Why did no one think about it in the beginning?” or “Why did no one mention something during the test phase?”) most companies tend to think there is not enough time nor budget left for those steps. I have news. It’s time to shift the mindset. Working for a company where we like to work very closely with clients, I urge everyone to adjust the set of priorities. While a lot of things can be corrected and approved after some time, some things can’t and these usually only have one try. The psychology behind “speed dating”: all it takes are 7 seconds for a person to decide if you like or dislike another person. Sure, this attitude can be readjusted over time, but it’ll take more effort. Same applies for apps and other products. The only difference: it takes only about 50 milliseconds . If the user experience is not good within the first few steps, the user is unlikely to come back or recommend it to other people.

This paragraph considers mostly the beginning of product development. Thinking one step deeper into the development cycle of an already existing product, one is well advised to adapt to an agile mindset. Fail early, fail often. There will barely be time to consider each and every edge case while developing. Some predefined edge cases might not even appear to be a problem to the user. The only way to find out which edge cases are very important for your user and thus for development is to keep trying out and delivering new adjustments or features. As long as you are able to learn and prove whether the predefined edge cases were just ideas or are key elements for users, the product is on the right track.

Trigger the user to use the product.

In the last blog post, I wrote some words about internal and external trigger points for user behaviour. Quick summary: Internal is habit based, e.g. checking the weather or social media in the morning. Whereas external is based on external sources, e.g. an emotionally interpreted picture in the user’s social media stream with a call to action for placing a donation or a picture of an appealing outfit leads to opening an online shop. It seems simple to define and approach internal triggers, but it is actually quite a hard task. Understanding the feelings of a user is key for the definition. Surveys will mostly provide answers about “what does the user want” but not “why they want it”. What is the feeling behind their motivation that drives the user to perform a specific action? How to get those answers? The 5-Why-Method could be one option to get closer to the user’s motive. It was first described by Taiichi Ohno, Toyota, to get closer towards understanding the user’s motive and their “why”.
Why is the user interested in doing that?
Why does the user want to have it?
Why does the user care about it?… etc.

Take a look at the product you are currently working on.

Raise the question of how you would like to trigger the user group(s). This answer is a key definition for further product refinements.

To learn more about how to target those different trigger points, I highly recommend the book “HOOKED” by Nir Eyal. “Companies need to understand two specific basic user behaviour patterns to increase the possibility of user interaction with their product: the effort of actively clicking a button and the user’s motivation behind it.”

Reward the user emotionally.

It will lead to raise the user attention and along with it the user retention. A reward can be an unsurprising positive event. For example, using a little game to add some emotional attention to your product. Thinking about an online shop, the company is very likely interested in a high amount of placed orders. Some people find it difficult to decide whether or not to buy a product. If you as a product manager are able to find out which particular actions could help the user to make the decision for the product and not against it, conversion rates will increase and the product will gain popularity. One possible action to speed up the decision making process could be to allow the user to unlock a little discount for selected items.

Another example of a different product: Let’s consider a sports application whose main goal is to track training results to reveal the user’s progress and suggestions for goal-based training results. One KPI of the application is to increase the user’s activity, another KPI is to keep the user profile up to date at all times, requiring proactive input of training results by the user. One approach to move closer to the goals can be through an interpretation of a gamification concept: transcribing all activities into steps and showing the user how many kilometers she or he has walked today and what it would look like on a map. Earning points for usage and unlocking medals are just another way to reward the user.

Remember internal and external triggers?

When aiming towards a user reaction out of an internal trigger, the product is more likely to be used more often.

Ultimately, rewards are also about addressing the wishes and needs of the user. Studying the user behavior is a loop. It is possible to address every single step within the user’s life cycle with the most values for the user. In fact, rewarding the user with the right assets (trigger points) is the most valuable hook for your product. Regardless which kind of product you are currently developing or polishing. How do you feel when you check a box from your personal to-do list? Feels great, huh? Triggering this feeling in a third person can be very tricky, but if you are able to do so, it is exactly the kind of reward you are looking for to convert your product from irregular use to habitual use.

Focus on the user’s attention.

Let’s be honest: the longer people use a product, the greater the chance for the company to develop a better and deeper understanding of the different types of people using it. Most people will associate a product as great, when it solves the user’s pain while simultaneously creating an association for the user to use your product in order to release the pain. This action can be defined as habit forming and will in the long term create a deeper user connection and easier association with your product.

Now it is the responsibility of the product manager and the team to sort and honestly interpret the collected data. Translating these honest interpretations into product improvements and optimizations will eventually lead to a deeper user connection between you and the user. She/he feels understood. Once a product uses these interpretations effectively, it is much easier for the user to form a habit around that specific product.

Part four will be published on Thursday, 12th of March 2020.

It is about defining concepts and actively implementing them as a result: “What am I going to do?”

• Should I consider all feature requests?
• Should I plan product budget on marketing?
• The importance of testing

Stay tuned.