Validating the Problem

It might seem like the most obvious step of all, but you'd be amazed how many people skip it. No matter how confident you are in your product idea, you first need to figure out whether the problem is a real one that needs solving.

To do this, your best option is to talk to potential users directly. Our focus here is on getting qualitative validation of the product idea. The goal is to ask open-ended questions and listen and learn from user responses.

First, we start with a small number of properly sampled, representative users and verify that the problem exists for them. Then, we optimise and verify this later on with more users and at greater scale.

The learning you take from these interviews will give you the confidence you need to move your idea forward. Or they'll teach you that you need to pivot your idea as you learn more about the real underlying problems.

The techniques described below are meant to be used individually, but they form a suite of methods that can provide a better picture of the problem you’re trying to validate.

Technique #1: Find-5-people-who-are-in

This is a simple method to get a feel for whether your idea is worthwhile. All you need to do is find 5 people who say they would be keen to use your hypothetical product.

While it doesn’t necessarily guarantee that the problem actually exists or that your proposed solution is good or valuable, it’s the simplest way to begin validating the problem you’ve identified.

By setting yourself a firm goal of 5 users, you have a target to hit before you can complete this stage.

Here's an example from Rob Walling, creator of an email-marketing tool called Drip:

"I wanted to find 10 people who would be willing to pay a specific amount for the product once it was complete. This forced me to not think about features, but to distill the idea down to its core value: a single reason someone would be willing to pay me for the product. I took that and emailed 17 people I knew, or had at least heard of, who may have shared the same pain. This way, I not only had my initial customers who could provide me feedback on the details of how Drip should work, I had the start of an early base of revenue I could use to start growing the product."

If you can build a good rapport with these users and keep hold of their contact information, they might even be willing to be your first 5 customers.

Technique #2: User interviews

By sitting down with people and interviewing them, you will likely learn a lot about both your problem and your users. The focus here is to understand the motivations and needs of each potential user you talk to and to use that feedback to improve the product.

Ideally, you’ll want to have both an interviewer and observer present during the interview. While the interviewer communicates with the user, the observer would take notes.

Some good practices for a fruitful interview include encouraging participants to share their past experiences as well as their current needs and challenges. Ask them how they’ve tried to solve this particular problem in the past and what was the outcome. Talking about this from a personal point of view allows participants to reveal their feelings, which should give you better insight into their motivations and help you to empathize with their needs.

Also, avoid asking people what they want. It’s often difficult for people to share exactly what they want. It’s easier for them to tell you what they’re trying to achieve and for you to ask about their motivations behind this. Uncovering this information enables you to gauge whether your product idea addresses that particular need or whether you need to tweak it slightly to solve a more pressing problem.

Another damper on user interviews is leading or suggestive questions. These are questions peppered with the interviewer’s assumptions, which could lead to false results. Keep the questions unbiased and open-ended — so, “What’s your impression of using feature X?” instead of “How easy was it to use feature X to navigate?”. We’ve compiled more helpful pointers on best practices for user interviews.

Technique #3: Ethnography research

Ethnography is often described as the process of discovering the unknown. In ethnography research, you take on the role of the intrepid explorer and travel to the natural working or living environment of your users. This form of research is great for observing and inquiring about behavior (What do you do?), motivation (Why do you do it?) and cognition (How do you think about what you need and what you do?).

It gives a lot of insight into context, which can be hard to get from other, more formal testing techniques. Learning more about this context helps us to understand how it affects the user experience, especially outside of lab conditions, controlled interviews and tests.

The key here is to spot and capture the “A-ha!” moments while discovering user motivations.

Imagine that you’re building a product to improve the ergonomic posture of office workers. Ethnographic research would be a valuable tool, perhaps even more so than user interviews. You would set yourself a goal of visiting offices to observe users “in the wild” and to see whether the problem exists. You might also visit a range of different offices, too: startup offices, coworking spaces, as well as the typical big corporate offices.

Conducting ethnography research helps you to see whether the problem is real and perhaps even to uncover new problems so that you can pivot the idea. Ethnographic research is a complex field that goes beyond what we’ve touched on so far. Take a deep dive into the practice by reading more about it.

Technique #4: Surveys

Surveys are one of the easiest research tools to use, but also potentially the most misleading. So, proceed with caution!

The conversation here is one-sided. You don't have an ongoing dialogue with your users--instead, you're sending out a set of pre-written questions and hoping they respond in the right way. It's also much harder to gauge tone and sentiment and read into their way of thinking.

Unlike the other techniques we've mentioned in this chapter, surveys are a more quantitative tool. They're focused more on the quantity of responses rather than the quality of user thinking. This means they're a great tool to validate the size of the market (as we'll see later) but can easily lead you astray at this early stage of the process!

If you're at the very beginning of your product validation journey, we would strongly recommend that you avoid validating the problem using surveys alone. As intimidating as it might sound, you'll need to get up close and personal with real users at some point in the process.

There are many tools that you can use to create surveys but one of the easiest and cheapest (free!) is Google Forms. You can very quickly put together a few questions and generate a link that you can send out to your audience.

If you have an audience already (perhaps a newsletter list for your existing business), that's a great start. But if you don't, you'll just need to get creative. You could share your form with friends and family or you could seek out the type of users you're looking for. For example, if your product is a new tool to help teachers, try searching online for teaching communities, forums, Facebook groups or events.

Another interesting paid tool is Google Consumer Surveys. This allows you to set up and distribute surveys using Google's audience and charges you for responses (about 10¢ to $3.50 per completion). This is an interesting tool, but again, if you're at the early stage of your product journey you'd be well advised to get a little more hands-on with your research.

Be careful if you do choose to run surveys. There's more information about them in our UX Playbook.

Why are these methods important?

By focusing on user research, you’re able to avoid common pitfalls, such as assuming the problem you’re dealing with is a pain point for others, too. Too often, we come across scenarios in which a designer says, “I’m pretty much like the end user, so it’d be safe to design something based on my own needs. Whatever I come up with will probably fit the mould for other users.” Keep in mind that you are not your user. Because you’re too close to the problem, what seems like the perfect solution to you might be a terrible solution for the average user. Tackling the problem you’ve identified could also mean that you’ve spent significant time researching the topic and probably understand it more deeply than the average person. Your view of the problem at hand is now biased, all the more reason why you need input from other users, to ensure you’re solving a real problem and not just one in your head.

results matching ""

    No results matching ""