A problem pattern is simply an important, predictable problem that is shared across a large percentage of your market. It’s useful to identify problem patterns because it allows you to be more confident that your market is, in fact, a single market where everyone might want to buy your solution to their problem.
RUN THE EXERCISE: IDENTIFYING PROBLEM PATTERNS
TIME TO RUN
Several hours over multiple days
MATERIALS NEEDED
Video camera for recording sessions (optional), sticky notes, Sharpies, whiteboard
PEOPLE INVOLVED
Product managers, designers, researchers, engineers
EXERCISE GOAL
Gather and synthesize user research to develop a better understanding of your product’s users.
When we spoke with eBay sellers for the financial product I mentioned earlier, we saw several problem patterns around things like tracking cost of goods and inventory management. These were problem patterns that we specifically did not see among consultants who sold their time rather than physical products.
PRO TIP
I often get asked, “How many people do I need to interview before I’ll know the answer to the question I’m asking?” The answer is “Five. And then another five. Until you start to be able to predict what you’re going to hear.”
This is less of an exercise and more of a way of life for a user-centered product manager or designer. Expect to do a lot of this.
STEP 1: Iterative Interviewing
The first step is to recruit some folks who fit the provisional persona that you created. Your goal is to find people who match most of the criteria in the demographic and behavior sections of the persona document. So, if you decided that the person most likely to have the problems that your product will solve is a single, left-handed dentist in Boise, Idaho, who owns her own dental practice, has a problem finding good dental equipment designed for lefties, and loves her iPhone, then you’re going to start looking for people who match that description as closely as possible.
This also applies if you’re talking to real users of your product. Depending on the persona you’ve created, you may only want to talk to administrators or people who have used your product for more than a year, or users who have accessed a specific feature in the last three weeks. You shouldn’t interview just anybody who uses your product. You need to focus on the type of person whose behavior you’re planning to change with a new feature or fix.
Whatever the screening criteria is, you want to find five of these folks who will talk to you for between 30 and 60 minutes as soon as you can get them scheduled. There are lots of techniques for making sure that you get good research participants. I’m not going to go into them in detail here.
PRO TIP
Sometimes finding people for research can be challenging, especially for new products that don’t have users yet. On the other hand, at some point you’re going to have to find hundreds, thousands, or maybe even millions of people who want to buy your product. If you can’t find five who will talk to you for 30 minutes about it, maybe it’s not a great market for you.
Once you find five people in your target persona to talk to you, you’re not going to talk about just anything, and you’re certainly not going to ask them what they’d like you to build. Instead, you’re going talk to them about their problems, behaviors, needs, and goals.
If you’ve already got a product with users, your specific questions and methodology will be a bit different than if you’re working on something entirely new, but the target is the same. You’re looking for patterns by asking about problems and how they’ve attempted to solve the problems in the past. You’re trying to find out what goals they’re trying to reach and how they’ve been prevented from reaching them in the past.
As an example, let’s look at the type of questions you might ask eBay sellers who are trying to track their sales. These are not the only possible questions, but it’s a good selection of the type you’ll want to ask.
Sample questions:
• Tell me about your business on eBay.
• How do you currently keep track of your business?
• How do you know how much money you’re making? How about how much you’re spending?
• Have you had any problems or issues with this system? If so, what?
• How did you decide to track things this way?
• Have you used any other systems to track this sort of thing in the past? If so, how did they work for you? Why did you stop using them?
• Will you show me what sorts of things you do on a typical day of your business?
If you’re talking to a current user of your product, you’d make sure to also ask whether they used anything in addition to your product, or if there were any related things that they did on a regular basis for which they couldn’t use your product.
There’s more about good interviewing techniques in the next chapter, but these are the types of open-ended, problem-finding questions that will get you a lot of useful information and help you spot patterns quickly.
The most important thing is to remember that this is your chance to listen and learn—not to sell. Selling comes later.
STEP 2: Recording and Synthesizing the Data
As you ask these questions, it’s a good idea to have somebody else on your team along for the research. It doesn’t matter who it is, and it’s always a good idea to bring different people along so that more people get exposed to the research process. Anybody who makes decisions should be involved to some extent in the research and should absolutely participate in the synthesis of the results. If you have a researcher, that person may be the one asking the questions, but product managers and designers should also participate directly in the vast majority of research sessions, if not all of them.
At the end of each research session, take 15 minutes and a stack of sticky notes. Everybody on the team who viewed the session should spend about 10 minutes writing down what they heard, one idea per sticky note.
Next, write down the answers to specific questions you asked. Try to capture problems you identified, big complaints that the participant had, and anything interesting or related that you observed.
After you’ve written down all of your observations, separate the problems from the behaviors.
An example of an interesting behavior might be something like, “The participant recorded all her cost of goods in a custom Excel spreadsheet that she updated once a week.” A problem might be, “The participant often finds discrepancies between her bank statement and what she’s recorded.”
Problems will help you find gaps in your current product or in the market for you to fill with new features. Behaviors, on the other hand, will help you understand your users better and design something that fits nicely into their lives. For example, if you find that people always use your product while commuting, that’s a behavior. It won’t necessarily help you decide exactly what product or feature to build first, but it might help you decide to focus more on mobile or to make design decisions that allow for