Intent to Solve

Written by: Laura Klein

When we’re building products for people, designers often do something called “needs finding” which translates roughly into “looking for problems in users’ lives that we can solve.” But there’s a problem with this. It’s a widely held belief that, if a company can find a problem that is bad enough, people will buy a product that solves it.

That’s often true. But sometimes it isn’t. And when it isn’t true, that’s when really well designed, well intentioned products can fail to find a market.

When isn’t it true?

When I tell product managers and entrepreneurs that their dream customers might not buy this product—even if the product solves a problem—sometimes they get angry.

“No!” the managers and entrepreneurs yell. “This is a serious problem for my users! They struggle with this thing every day! They told us this. We saw them struggling with it. We did our research!”

But think about all of the problems that you encounter in a day. Some of them are almost entirely in your control, like deciding how to feed yourself. Some of them are largely out of your control, like sitting in traffic on the way to work. Some of them are almost entirely out of your control, like certain types of health problems.

So, there you are. Sitting in traffic, with a migraine, and trying to figure out what you want for lunch. Which problem do you solve?

Do you solve the worst one? The one that happens every day? The easiest one? Do you give up entirely and just turn around and go back to bed? The only thing that most people won’t do is to solve all of them all at once.

In other words, every day, humans use their limited emotional resources to solve specific problems while they choose to live with other problems or put off solving them until another day.

This tendency of humans to not always solve their worst problems is incredibly important for you to recognize when you’re doing early user research because it has implications for your product. Just because you’ve identified a serious problem doesn’t mean that anybody will pay you to solve it for them.

And remember, when we’re talking about “payment,” we’re not necessarily just talking about money. Free products are often only free if your time has no value. Sure, some products cost money, but people also pay with their time, attention, and effort. If you’re asking somebody to spend hours learning how to use your product, you’ve just charged them a fairly high hourly rate for your free product. You’d better make it worth their while.

You can do something about this

So, how can you separate out the problems that people will pay you to solve from the problems they won’t? Sure, intensity, frequency, and difficulty of solving the problem can influence whether a user will try to solve it. But there’s an even more important thing to look for: Intent to solve.

For example, if you’re a gym owner, and you talk to three women, all of whom say they want to get into better shape, which of the following sounds like the person most likely to join your gym?

a) I’m in terrible shape, and it’s really affecting my health. I’ve never joined a gym, but I’m definitely going to do it this year.
b) I really love running and swimming at my neighborhood pool, and I consider myself to be in pretty good shape. But I’m not a fan of gyms.
c) I’m in ok shape. I’ve belonged to several gyms in the past, but I don’t currently belong to one.

Did you say C? You should have.

Sure, A specifically states that she is going to join a gym and her perceived problem is larger than the other two, but we’ve all declared that we’re absolutely going to do something this year and then not done it. That’s what New Year’s resolutions are. B seems perfectly happy with her routine and doesn’t really have the problem that we’re solving.

C, on the other hand, shows both motivation and a past intent to solve the problem in the way that you, as a gym owner, would like. In other words, she has previously sought ways to get into better shape and has even spent money on gyms. She has shown an intent to solve in the past which is an excellent predictor of her behavior in the future.

There is one notable exception

But hang on. I know what you’re thinking. You’re thinking “but what about Twitter?” Or maybe Snapchat, or WhatsApp, or a dozen other products that solve problems that people didn’t know they had.

It’s true, there are products that don’t solve an obvious problem. Things like Twitter create new behaviors (sort of) and don’t seem to solve anything that anybody ever intended to solve before Twitter came along.

Now, we could argue all day about whether or not Twitter solves a specific problem or perhaps many problems—or even creates problems. The important thing to point out here is that, when you’re creating a product that is truly going to create a new behavior, it is just much, much harder to validate before you build. That’s doubly true if the product relies on network effects, like Twitter does.

Honestly, there may simply be no way to tell if something like Twitter is going to take off before you build anything at all. That’s why, although we do have things like Twitter, we also have tens of thousands of social networking sites and apps that nobody’s ever heard of.

What to look for

If your product does solve a problem that people likely knows exists, though, there’s a very useful technique for figuring out if it’s a good one to solve.

We’ll assume for the moment that you’re already doing user research and customer development. You’re building something, so obviously you’re talking to people who you think might be in the market for such a product—or at least people who have the problem that your product solves.

Just talking to people though, isn’t enough; you have to ask them the right questions. Instead of just asking them questions designed to confirm whether or not they have a specific problem, you need to ask questions designed to find out if they have already shown an “intent to solve” that problem.

What you’re looking for is not just a problem—in the case of the gym owner, a potential user wanting to get into better shape—you’re also looking for a previous behavior of trying to solve the problem. Bonus points if they have spent money trying to solve the problem.

When you find a serious problem that people have tried and failed to solve, you can generally count on their trying to solve it again in the future. Ideally, you want something that they’re actively searching for a solution to right now.

If you want to convince somebody to join your gym, it’s much easier to start with somebody who already wants to join a gym. At that point, you’re being compared to all other gyms. You’re not being compared to literally everything else that the user could do with her money and time.

Humans encounter all sorts of problems every day. Most, we just ignore or deal with. Only a few reach a level that we will spend our precious resources to solve. If you find a problem that is serious enough that people have already shown an intent to solve, it will be far easier to convince people to try your solution.

If you think you have a brilliant idea for a product that creates a brand new form of user behavior and may or may not solve a particular problem, more power to you. It’s not impossible to make it work, but it’s significantly harder to get it adopted than the millions of things that solve real problems that people encounter every day.

For the rest of you who want to make sure a problem really exists before you try to solve it, try evaluating your user’s intent to solve before you build anything. It’ll give you tremendous insight into whether or not your product will be adopted.

The Right Way to Do Lean Research

Written by: Laura Klein

StartX, a nonprofit startup accelerator, recently devoted an entire day to the role of design in early-stage companies. One panel included Laura Klein, Todd Zaki-Warfel, Christina Wodtke, and Mike Long.

Each panelist had made their mark on how design is done in start-ups: Laura wrote the influential O’Reilly book on UX for Lean Startups, and Todd penned the bestselling Rosenfeld Media Prototyping book. Christina has been cross-teaching design to entrepreneurs and entrepreneurship to designers at institutions such as California College for the Arts, General Assembly, Copenhagen Institute of Interaction Design, and Stanford. Mike founded an influential Lean UX community in San Francisco.  

Although the conversation ranged widely, they kept coming back to research: the heart of the lean build-measure-learn cycle. As the hour-long panel drew to a close, Christina jumped up and scribbled on the board the key themes of the conversation: right questions, right people, right test, right place, right attitude and right documentation.

Below is Laura Klein expounds on these key themes of lean research. Boxes and Arrows is grateful for her time.

Right questions: Make sure you know what you need to know

Too many people just “do research” or “talk to customers” without having a plan for what they want to learn. What they end up with is a mass of information with no way of parsing it.

Sure, you can learn things just by chatting with your users, but too often what you’ll get is a combination of bug reports, random observations, feature suggestions, and other bits and bobs that will be very difficult to act on.

A better approach is to think about what you’re interested in learning ahead of time and plan the questions that you want to ask. For example, if you need to know about a particular user behavior, come up with a set of questions that is designed to elicit information about that behavior. If you’re interested in learning about the usage of a new feature, ask research participants to show you how they use the feature.

The biggest benefit to planning your research and writing questions ahead of time is that you’ll need to talk to far fewer people to learn something actionable. It will be quicker and easier to learn what you need to know, make a design change, and then test that change, since you will see patterns much more quickly when you ask everyone the same set of questions.

Right people: Talk to people like your users

Let’s say you’re building a brand new product. You want to get everybody’s opinion about it, right? Wrong! You want to get the opinions of people who might actually use the product, and nobody else.

Why? Well, it’s pretty obvious if you think about it. If you’re building a product for astronauts, you almost certainly don’t want to know whether I like the product. I’m not an astronaut. If you make any changes to your product based on anything I say, there is still no conceivable way that I’m going to buy your product. I am not your user.

Yet, this happens over and over. Founders solicit feedback about their product from friends, family, investors…pretty much anybody they can get their hands on. What they get is a mashup of conflicting advice, none of it from the people who are at all likely to buy the product. And all the time you spend building things for people who aren’t your customer is time you’re not spending building things for people who are your customer.

So, stop wasting your time talking to people who are never going to buy your product.

Right test/methodology: Sometimes prototypes, sometimes Wizard of Oz

Figuring out the right type of test means understanding what you want to learn.

For example, if you want to learn more about your user–their problems, their habits, the context in which they’ll use your product–you’re very likely to do some sort of ethnographic research. You’ll want to run a contextual inquiry or an observational study of some sort.

If, on the other hand, you want to learn about your product–whether it’s usable, whether the features are discoverable, whether parts of it are incredibly confusing–you’ll want to do some sort of usability testing. You might do task based usability testing, where you give the user specific tasks to perform, or you might try observational testing, where you simply watch people interact with your product.

There is another type of testing that is not quite as well understood, and that’s validation testing. Sometimes I like to call it “finding out if your idea is stupid” testing. This type of testing could take many forms, but the goal is always to validate (or invalidate) an idea or assumption. For example, you might test whether people want a particular feature with a fake door. Or you might learn whether a particular feature is useful with a concierge test. Or you could gauge whether you’re likely to have a big enough market with audience building. Or you could test to see whether your messaging is clear with a five second test.

All of these approaches are useful, but the trick is to pick the right one for your particular stage of product development. A five second test won’t do you any good if what you want to learn is whether your user is primarily mobile. A concierge test doesn’t make sense for many simple consumer applications. Whatever method you use, make sure that the results will give you the insights you need in order to take your product to the next level.

Right place: When do you go onsite?

If you talk to serious researchers, they will often tell you that you’ll never get good data without being in the same room with your subject. You’ll learn so much more being able to see the context in which your participant is using the product, they’ll tell you.

And they’re right. You do learn more. You also spend more. Kind of a lot more, in some cases.

So, what do you do if you don’t have an infinite budget? What do you do if you have users on multiple continents? What do you do if, in short, you are a typical startup trying to make decisions about a product before going out of business. You do what people have been doing since the dawn of time: You compromise.

Part of deciding whether or not to do remote research has to do with the difficulty of the remote research and what you need to learn. For example, it’s much harder at the moment to do remote research on mobile products, not just because there isn’t great screen sharing software but also because mobile products are often used while…well, mobile. If you simply can’t do an in person observation though, consider doing something like a diary study or tracking behaviors through analytics and then doing a follow up phone interview with the user.

Other types of research, on the other hand, are pretty trivial to do remotely. Something like straightforward, task based, web usability testing is almost as effective through screensharing as it is in person. In some cases, it can be more effective, because it allows the participant to use her own computer while still allowing you to record the session.

Also, consider if you’re truly choosing between remote testing and in-person testing. If you don’t have the budget to travel to different countries to test international users, you may be choosing between remote testing and no testing at all. I’ll take suboptimal remote testing over nothing any day of the week.

Choosing whether your testing is going to be remote, in person, or in a lab setting all comes down to your individual circumstances. Sure, it would be better if we could do all of our testing in the perfect conditions. But don’t be afraid to take 80% of the benefit for 20% of the cost and time.

Right attitude: Listen, don’t sell

I feel very strongly that the person making product decisions should be the person who is in charge of research. This could mean a designer, a product owner, an entrepreneur, or an engineer. Whatever your title, if you’re responsible for deciding what to make next, you should be the one responsible for understanding your user’s needs.

Unfortunately, people who don’t have a lot of experience with research often struggle with getting feedback. The most common problem I see when entrepreneurs talk to users is the seemingly overwhelming desire to pitch. I get it. You love this idea. You’ve probably spent the last year pitching it to anybody who would listen to you. You’ve been in and out of VC offices, trying to sell them on your brilliant solution.

Now stop it. Research isn’t about selling. It’s about learning. Somehow, you’re going to have to change your mode from “telling people your product is amazing” to “learning more about your user and her needs.”

The other problem I see all the time is defensiveness. I know, I know. It’s hard to just sit there and listen to someone tell you your baby is ugly. But wouldn’t you really rather hear that its ugly before you spend several million dollars on building a really ugly baby?

If you open yourself up to the possibility that your idea may be flawed, you have a chance of fixing the things that don’t work. Then your baby will be pretty, and everybody will want to buy it. Ok, the metaphor gets a little creepy, but the point is that you should stop being so defensive.

Right documentation: Record!

You should be taking all of this down. Specifically, you should be recording whatever you can. Obviously, you need to get permission if you’re going to record people, but if that’s at all possible, do it.

The main reason recording is so important is so that you can be more present while interviewing. If you’re not busy writing everything down, you can spend time actually having a conversation with the participant. It makes for a better experience for everybody.

If you can’t get everything on video, or really even if you can, it’s also good to have someone in the room with you taking extensive notes. You’re not going for a transcript, necessarily, but just having somebody record what was said and what was done can be immensely helpful in analyzing the sessions later.

Another important tactic for remembering what was said is the post-session debrief. After conducting the interview or observation, spend 15 minutes with any other observers and write down the top five or ten take-aways. Do it independently. Then, compare notes with the other observers and see if you all learned the same things from the session. You may be surprised at how often other people will have a different understanding of the same interview.


Boxes and Arrows thanks Laura for sharing these insights with our readers! If you want to learn more about fast and effective research, we strongly recommend her book UX for Lean Startups: Faster, Smarter User Experience Research and Design and her talk “Beyond Landing Pages” from the 2013 Lean Startup Conference.