.

writes the checks, and the user is the person who interacts with your product. Sometimes that’s the same person, but generally, in Enterprise especially, it’s not. Go ahead and make one of these for every different type of user you have.

FIGURE 2.9 Record your answers on sticky notes so you can update your User Maps easily.

       Why Did You Do That Exercise?

      While personas can be useful for expressing the behaviors and needs of a particular user, they are a little limited. They create a picture of a user at a specific point in time.

      The User Map, on the other hand, can help you identify several specific traits of your user that you’ll need to know. Once you think you have a good idea of who your user really is, try making a User Map in order to find the gaps in your knowledge.

The Dangers of Defining Your User

      There are really remarkably few dangers involved with getting to know more about your users, but there are some things that you can get wrong. Generally, the biggest problems spring from not defining your user well enough, or from not validating that the people for whom you’re building your product really exist.

      It’s not enough to describe the person you think will be your customers. You need to do the work to understand the humans who are using your product.

       Stopping at the Provisional Persona

      I’m always a little nervous when I explain the concept of the provisional persona to new teams, because so many teams want to jump ahead after creating one. While creating a provisional persona is a useful exercise, it’s quite dangerous without validation.

      Creating an artifact like a provisional persona or an invalidated User Map can lead to a false sense of understanding. The fact that the team agreed that this is the right type of user to target may lead the team to believe that they’re free to go ahead and start building features for this person. You need to resist this urge.

      The validation and problem finding steps are far more important than creating the provisional persona or the map. You’ve probably noticed that it’s also a lot harder. Do it anyway.

      Until you’ve gotten out of the building and started listening to real or potential users, all of your hypotheses about your user are no better than guesses. They’re stories that you made up to tell yourself or your team. If you’re a very good storyteller, it can be easy to delude yourself into believing that you know what your customer really wants. That’s how you end up building products that never get used or that don’t solve real problems for real people.

      Go ahead and create all the provisional personas and User Maps you want, but don’t stop talking to users and iterating on the documents until you have solid evidence that they represent actual users.

       Confirmation Bias

      Humans are never unbiased. We all go into situations with certain beliefs that can be very hard to change.

      Unfortunately, this applies when trying to do user research, and it seems to apply doubly for startup founders. When you spend every single moment of your day trying to convince people that your idea is absolute genius, taking that step back and admitting to yourself that you have things to learn can be psychologically exhausting.

      Nevertheless, you need to overcome your desire to hear nothing but, “You’re right!” and “Of course I would buy this product!” Your goal during this phase is to learn new things, not just confirm what you think you already know.

      In order to combat this very human tendency to hear nothing but what you want to hear, you should never conduct research alone. You’ll learn more about how to talk to users in Chapter 3, “Do Better Research,” but the best advice for now is to always take a buddy.

      At the end of every research session, having another person who saw the same research you did will help you make sure that you both heard the same things. Take 15 minutes after each discussion with a user and debrief with someone whose only job it was to observe. Or, if you’re having a very hard time being neutral, let another person lead the interviews while you grit your teeth and keep your mouth shut. You’ll get much better results.

       Jumping to Solutions

      Once you start seeing problem patterns, you’re going to want to solve those problems. It’s natural. You see something that is causing pain to somebody, and your instinct will be to try to fix it. You’re not a monster.

      Sadly, you’ll have to suppress that desire to fix things for longer than you might like. This phase of the project, while it doesn’t have to take very long, does have to be entirely focused on identifying and validating problems rather than generating solutions.

      I know it’s tempting to solve the first problem you see, but don’t jump to the solution space just yet. You’ll find that people can have endless problems, and you’re never going to be able to solve all of them. As the person in charge of making product decisions, you’re going to have to prioritize, and sometimes that means seeing people struggle with something and deciding not to solve it just yet. Besides, we don’t get to prioritization until Chapter 6, “Prioritize Better.”

EXPERT ADVICE from Cindy Alvarez

      Understanding your user is critical to success, and few people know more about learning who your customer really is than Cindy Alvarez, Director of UX at Yammer—a Microsoft Company. She shared advice on the mistakes that teams make about their users and how to avoid them.

      “Teams often misunderstand their customers in one of two ways,” Cindy explained. “Some, especially those who set out to solve their own problem, substitute their own opinions and wants and needs for those of the customer. The other problem is when teams listen to the most vocal customers’ unsolicited feedback. In both cases, this leads to a skewed view of what customers truly value.” To avoid those traps, you need to focus on the right customers and the right questions.

       What You Need to Know About Your Customer

      According to Cindy, there are two questions that teams need to answer about their customers:

      • Who is getting the most value from our product?

      • How can we learn more about what they need so that we can retain and monetize them and acquire more customers like them?

      To answer these questions, Cindy recommends a three-step process that combines both quantitative and qualitative methods.

       STEP 1: Find Your Heaviest Users

      If you have the data, start looking for customers who are using the product constantly. These are your power users.

      Who is on the platform every day? Who is contributing most? Who is configuring the most reports? Who is sending the most messages? Who is coming back two, three, or four times more often than average? Whatever it is your product does, you’re looking for the people who are doing it the most.

       STEP 2: Ask a Single Question

      Next, use email, text, or a lightweight, in-product chat service like Qualaroo or Olark to send a single question