You’ve probably heard that saying (often attributed to Henry Ford even though he probably didn’t say it): “If I would have asked people what they wanted, they would have said faster horses.” The “quote”—at this point a bit old and tired in product circles—is often used to inspire teams to focus on the customer’s core problem and help them develop a similarly innovative solution.

One of the problems with this quote-not-quote is that most product teams simply aren’t in a position to pasture the horse and build an assembly line. Instead, it’s more like they’ve been handed the 1896 Quadricycle and told to figure out how to improve upon it. (Case in point: with no steering wheel, brakes, or reverse, the 1896 Quadricycle was the original MVP). So, how do these product teams figure out how to balance gradual improvements to the Quadricycle while simultaneously identifying what the next motor vehicle should be?

Fortunately, Mr. Ford had a UX Researcher at his disposal to help navigate this terrain (not really, but since we frequently falsely attribute a quote to him, I figure we can also do the same with team members).

This UX Researcher explained to Mr. Ford that now that he has a product, he has two problems to worry about and balance: product and customer problems. Worse yet, if he doesn’t balance them well, he’ll also have a third type of problem: business problems. 

It’s not in any history books, but I feel sure that if the UX Researcher were to break it down for product teams today, it would go something like this:

Product problems point to the deficiencies in our products. They exist only because our products exist. That list of feature requests your favorite customer just sent you—that’s probably a list of product problems. The improvements your sales and customer success teams have been asking for—also likely a list of product problems. The content of NPS responses and technical support tickets—you guessed it. Probably almost all product problems.

Make no mistake: managing and responding to product problems is essential for product success. Our agile development processes push us to create and deliver products and features that are MVPs—in other words, knowingly inadequate. Post-launch we attend to the feedback provided by a multitude of sources, with the goal of prioritizing what to build next.

When working to improve an existing product, it is easy to become so myopically focused on product problems that we lose sight of the customer’s problem(s). And, because they are often resolving deficiencies in the product, they are often not the type of improvements that are market-worthy. And problems that aren’t market-worthy can be difficult to “sell” to leadership as they rarely result in significant revenue gains to the business. 

Customer problems are the true problems of our customers and prospects. They exist because our customers exist. In modern parlance, they are the “jobs” in Jobs To Be Done nomenclature. That is, they represent needs that exist for our customers (or prospects) regardless of whether there are a plethora of options and solutions in the marketplace or none at all. They get to the core of why a customer is using your product and what they hope the product will accomplish for them.  

The opportunity doesn’t have to be large enough to charge a fee, but if it’s at least “marketable” (i.e., something you can present at a conference or write a press release about), then you know you’ve hit on something worth exploring.

And then there are business problems. Which are, as they sound, the problems of the business. These problems are frequently revenue-oriented and driven by leadership. They manifest through statements like, “We need to increase market share” or “we need to be able to better compete against XYZ.”

Successful organizations have to be cognizant of these demands and their position in the marketplace. However, it’s critical not to confuse business problems with product or customer problems.

Different stakeholder groups are often focused on different problem types due to the demands of their role. While each of these different problem types is important, they often get pitted against each other, with the various stakeholder groups lobbying for what is “most important.”

For example, executives tend to identify business problems and customer-facing teams tend to focus on product problems. It’s the job of the product team to maintain focus on the customer problem without losing sight of the product and business problems.

As UX Researchers, we are uniquely qualified to help our stakeholders navigate this dizzying balance of problems. First and foremost, it’s our responsibility to ensure that, regardless of any other problem type we might be focused on, it always overlaps with the customer problem. Otherwise, it’s not worth doing. 

In fact, the opportunity for innovation lies in the intersection between these three problem types.

Second, our relative objectivity on a team enables us to identify and name which types of problems we are addressing and with what specific improvements. As skilled facilitators, we can host a workshop to help our stakeholders map the various problems to their types and ideate solutions that span all three.

Let’s go back to our 1896 Quadricycle. With no real breaks and no steering wheel, there’s no doubt that motorists experienced the product problem of crashing into things. The problem of crashing into things—or, put another way, the need to stop the vehicle—only exists because the product exists.

When people were just walking around, they probably weren’t randomly crashing into things (unless they were drunk, but for now, we’ll assume they were sober). It seems silly for us to think about now, but early automotive inventors were more concerned with motion than braking. 

If we focus specifically on the product problem, we might offer various “stopping” solutions such as: throwing out an anchor or dragging your feet, Fred Flinstone style. In fact, the actual solutions put forward in terms of early improvements to brakes ultimately failed because they didn’t focus on the customer problem.

The customer’s problem is that people need to get from point A to point B—comfortably and as quickly as possible, without fear of injury or death to themselves or others. As it turns out, the intersection between comfort and speed required an entirely new invention: the pneumatic tire. Pneumatic tires provided a more comfortable riding experience and allowed for faster speeds. But faster speeds and different tires require an entirely new type of brake. 

So the real invention that resulted from the intersection between customer problems (go somewhere quickly and comfortably) and product problems (without crashing into things) was a new tire with brakes inside.

As it turns out, there is an actual Henry Ford quote that better aligns with the moral of our story: “There are no big problems, there are just a lot of little problems.”

In other words: don’t get so caught up in solving product or business problems that you lose sight of your customers’ problems!

Be clear about what specific type of problem each of those “little problems” are, identify the intersection between them, and then look for those magical opportunities for innovation.