Validating Problems Through Customer Research

The purpose of a product is to solve a problem for a large group of users. It’s easy to look at any industry, company, or process and find countless problems and pain points. As an innovator, solving any problem isn’t enough – you have to solve the critical problem. Otherwise, no amount of capital, team experience, or technology can propel a product to success when it lacks purpose.

“We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem.” – Russell L. Ackoff

The critical problem isn’t always as apparent as it seems. One major problem can spark a series of cascading issues and various impacts to the customer experience. Even people who experience the process first-hand can’t always identify the source of the underlying problem.

Problem validation and customer research are powerful learning mechanisms that build empathy for users and exposes the various challenges they experience. This process clarifies the full spectrum of problems that users experience and the current solutions they employ. Most customers are overwhelmed with a series of cascading problems, inefficiencies, or inadequate existing solutions – and most of the time, they haven’t even identified the biggest pain point. Problem validation is about digging into the customer’s workflow and exposing the critical problem that’s worth solving.

“Solving problems means listening.” – Richard Branson

Learning from your customers

The best way to conduct problem validation research is by learning from your customers. There are various styles and techniques for conducting user research, but real, human-to-human conversations are always best. There are two primary means for learning from customers: customer interviews and ethnographic research.

Learning from your customers should help you answer:

What is your customer’s goal?
What is the process they undertake to achieve their goal?
What are the varying pain-points in their process?
Which pain points are most critical?
How do they currently solve each pain-point (if at all)?
How flexible is their process?
How badly do they want their problems solved?
Do they have an appetite for innovation or experimentation?
Are they a good early adopter or customer?

When you identify who to interview, make sure that you include various users that can provide varying perspectives. Instead of interviewing five individuals in the same role, try mixing it up with a manager, a technical person, or somebody else who has surface experience exposure to the problem.

Customer Interviews

The idea of customer interviews is to sit down with a customer and develop a deep understanding of their situation, including process, pain-points, and current solutions.

While you should have a script of sorts, this process should be more of a conversation than an interview. Through this in-person approach, the user can walk us through their process, their decisions, and the outcomes they expect.

While many experience similar problems, each customer is unique in their priorities, threshold for pain points, and how they solve problems. Interviews are not about measurable answers but extracting information and discovering problems. One-on-one conversations with customers help build empathy and understanding that is unmatched through any other research medium.

Ethnographic Research

Some problems are better understood through ethnographic research, which is conducted by watching people perform their daily tasks in their typical environment. This might mean getting in a truck with a driver to understand their routine, shadowing an insurance claims representative throughout their day, or observing a customer support representative do their work.

Ethnographic research allows us to observe and document how users go about their day. You take notes, ask questions, and identify the bottlenecks, pain points, and problems the user experiences. Unlike an interview, ethnographic research allows us to directly experience the user’s pain points rather than just hear about them.

Through ethnographic research, we gain a better understanding of the context of the problem and the opportunities for solutions.

Make sure you’re talking to the right people

Talking to the wrong people can be just as bad as solving the wrong problem. You’re not just looking for confirmation; you need to uncover the root problem – and that can only come from talking to experienced people with a deep understanding of the industry.

They should have skin in the game

The customers that you choose to research must have skin in the game. That means they must have something to gain from using better tools and solutions or something to lose if they don’t. You want to talk to customers that want to excel in their industry through innovation and efficiencies. These are the people that are severely affected by problems and eager to adopt new solutions to give them a competitive advantage. They want you to succeed, because it means that they will also succeed.

They should be industry experts

The best customers are going to have in-depth industry knowledge and experience. These individuals understand the bigger picture of their industry, how they got to their current situation, and where things are moving. Industry experts are those with ten or more years of experience that can talk to you for hours about their pain points and the domino-effects of these problems. While new, younger customers are more eager to find new ways of doing things, they usually don’t have the foresight or experience to see the larger forces at play.

Avoid people that only share their ideas

Some customers have many ideas on how they’d solve the problems they face. These individuals lack clarity into what would be a big-picture solution, as opposed to just solving their individual pain points. Their years of following the same routine blind them from envisioning a better solution.

Individuals without skin in the game will rarely take the time and effort required to learn a new process or truly innovate. Instead, they’re waiting for something better to come along.

“You can increase your problem-solving skills by honing your question-asking ability.” – Michael J. Gelb

Question Everything

When learning from users, you should question everything. Whether you are familiar with the process or the responses make sense, you should continue to ask why. The further you can drill down, the more context you’ll build, and the root causes will begin to percolate to the top.

There are a few frameworks for helping expose underlying issues. A few that we like are the “Five Whys” and the “Five Ws.”

The Five Whys

Using the Five Whys is a simple technique to explore the cause-and-effect of underlying problems. The idea is to keep asking why to each response. For example (from Wikipedia):

Why? – The battery is dead. (First why)
Why? – The alternator is not functioning. (Second why)
Why? – The alternator belt has broken. (Third why)
Why? – The alternator belt was well beyond its useful service life and not replaced. (Fourth why)
Why? – The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)

Utilizing the Five Whys will lead you to realize that many users don’t spend enough time questioning why something doesn’t work or why it’s done that way.

The Five Ws

The Five Ws is another technique for understanding the problem and context. The Five Ws are as follows:

Who
What
When
Where
Why

The goal is to build a general understanding of the situation where the problem occurs. Who does it happen to? What happens? When does it occur? Where does it occur? Why does it occur? Asking these questions helps establish the context of the situation. You can start with the Five Ws and then follow up with the Five Whys to dig into details.

In most situations, users get comfortable with the way things are, and they can complete their tasks on autopilot. They will patch together whatever works to accomplish the bigger goal they set out to achieve. Our outside perspective can help reveal the cause-and-effects that lead to a critical problem.

Don’t ask for opinions

What’s that saying about opinions? Asking for opinions can be tempting, even validating, but it’s typically a false positive that will blur your vision.

Rather than ask questions like “Would you…” or “Do you think…”, you should ask for facts. For example, you could ask, “Did you ever try doing it this way?” “Tell me about a time when you…” “When was the last time you did..”, etc. You want to ask questions that can be answered with a factual basis rather than an opinion. How they currently do something or how they’ve done something in the past is a much better indicator than their opinion on a problem or a potential solution.

Don’t focus on solutions

It is tempting to discuss potential solutions with customers, but try to avoid this at all costs. The goal is not to explore solutions but to identify the most critical problems that the customer experiences. The minute you start discussing solutions, the entire conversation shifts, and you fall prey to solving the wrong problem.

If the customer suggests solutions, try digging into the problem more and how they currently solve them. The more that you can focus on the problem, the better your understanding of their pain-points becomes. Fall back to the Five Whys or the Five Ws to build more context around the current problem.

Users will most likely have some “solution” they are currently employing. It’s essential to understand why they use this solution. How does the current solution work? Why does it work? When doesn’t it work? You can continue to pick apart the existing solutions to better frame the problem and dig into the root cause.

“It isn’t that they cannot find the solution. It is that they cannot see the problem.” – G.K Chesterton

Why should you conduct problem validation?

Identifying the right problem to solve is challenging. Problem discovery and validation is a project in and of itself. Many might be tempted to skip it because they have a “good sense” of the problem, but it’s best to spend a little extra time confirming that you are solving the right problem than it is to spend months (or years) building a solution to the wrong problem.

The effort involved in problem validation will vary for each project. More straightforward projects may only need a few days or a week of work, while more complex problems can require weeks or months of work to understand the context and critical problem thoroughly.

While problem validation is challenging, it can be the difference between success and failure. Building custom software products is a considerable risk that can cost a lot of time and money. Problem validation can help mitigate risk and has minimal downside compared to the enormous upside that it provides.

If you need any help with customer research or problem validation, don’t hesitate to contact us.