style="font-size:15px;"> Style app: Multiple times a day for a few minutes at a time
SaaS tool: Once a week for this user (other users will use multiple times a day)
Determine Future Use
Finally, it’s not enough that people try your product. Great products are things that people develop a relationship with over time. The products change along with the needs of the users to keep people happy over the course of years. You need to understand how your product will stay relevant to your users.
• Why will they keep using it over the course of the next few years?
Style app: Constantly updated with the newest designers
SaaS tool: Will be able to show 20% improvement in ROI on marketing campaigns within the first 6 months
• How will their usage change over the next few months? The next few years?
Style app: Should use more frequently as they find more designers, but may drop off if they age out of the styles
SaaS tool: Will begin to use more comparative reports and require more historical data as it accumulates
• What will be different about the user in the next few months? The next few years?
Style app: Will spend less money at retail stores while feeling happier about wardrobe
SaaS tool: Marketing department will become more efficient while user will spend 50% less time on reporting and managing
How Do You Know You’re Right?
Once you and your team have taken a shot at answering these questions, you’ll probably find that you’ve had to make some guesses. Very few product teams immediately know the answer to all of these questions with any level of confidence.
If you do feel like you know the answers to all of these questions, how do you know that you’re right? Are the answers based on solid qualitative and quantitative feedback? Do you have any evidence that everything you believe is true?
Of course, if you don’t yet have a product, you’re just making up the answers to all of these questions. That’s fine for now, but your next step should be to try to figure out whether the person you’ve just described exists. If you already have a product with users, make sure that your answers are based on current evidence—not research that may have been done years ago or a vague “feeling” that you have from talking to some users occasionally.
And don’t be afraid to say, “I don’t know.” If you don’t know the answers to some of the questions, that’s fine. Just make sure that you’ve got a plan for learning what you don’t know yet.
When you have some evidence that the things you believe to be true really are, you can check the Validated box for that section of the map. This will help you keep track of what you think you know and what you’ve tested.
Map It!
I can’t legally call this a User Map without providing you with some sort of visual representation of your answers. The great thing about this map shown in Figure 2.8 is that it will show you, very clearly, what information you have about your users and what you’re still missing.
FIGURE 2.8 The User Map shows the most important questions you should answer.
I strongly recommend you make a large version of this on a poster of some sort and start covering it with sticky notes with your answers on them. When you have validated something, feel free to write it directly on the map and check the Validated box, but don’t forget to date it (see Figure 2.9). Information about your users has a way of going stale over time.
Also, you’ll want to label the person you’re defining as a User, a Customer, or Both. Remember, the customer is the person who 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
