Low-performing teams choose problems based on what they’d like to solve rather than what their customers need.
They say that good designers fall in love with problems, not with solutions. I tend to agree, and the first thing I always ask new customers to do is describe the problem they are facing.
A couple of years back, a customer came to me with a request: “Our CEO tried to use our product. His transaction didn’t go through and he couldn’t see its status. So customers being able to track their transaction is a priority problem that we need to solve.”
I’m sure you’ve already spotted the snag: the problem in their statement was “users don’t have this tool.”
In other words, it was a solution statement in disguise.
But we couldn’t convince the customer’s CEO to change it. He “fell in love” with the problem of not having a tracker. After two years of bashing away at the problem without moving the metrics, the customer’s team realized what we had told them in the first week: that they were trying to solve a product problem rather than a customer problem.
The road to the Build Trap is paved with product problems
The build trap is when organizations focus more on shipping and developing features rather than on the actual value those things produce. — Melissa Perri, Escaping the Build Trap
This was hardly the only time that a customer’s first stab at a problem statement ended up defining a product problem. In fact, the majority of initial problem statements I see are some twist on “we want to add this feature, can you help us define it.”
This makes sense because of how these teams are typically organized — not as true product teams, but as project teams. They are given an output goal and only make decisions within the bounds of that output. Since decisions about the form factor are typically made for them by executive stakeholders — like that customer’s CEO — they skip right to the form factor.
Output-driven teams make plans around features, creating the illusion of certainty in the near term but much greater risk in the long term because those outputs are not meaningfully connected to likely outcomes.
Because the team was told “build a tracker” by their stakeholder, “users want a tracker” became the animating principle behind the team’s efforts. Other mandates you’ve likely seen pop up in the news include “users want a chatbot,” “users want a dashboard” or “users want a subscription to their mouse.”
Fundamentally, the question all these teams are asking is not “what needs do our customers have?” but “What features is this product missing?”
They are solving product problems.
When low-maturity product teams do engage with outcome goals, the situation is rarely much better. Vanity metrics such as number of queries or email send rate predominate, locking product teams into their most highly instrumented form factor rather than allowing them to choose the most appropriate channel for reaching the customer.
Once the team’s work is framed as a product problem, it becomes extremely difficult to correct that framing. No amount of validating your idea will tell you that you’re on the wrong track; when you ask “what features do you want the dashboard to have” then unless you’re reading between the lines all you’ll never hear “users don’t need a dashboard.”
The double square is less well-known than its cousin the double diamond, but much more frequently practiced.
This kind of work is commonly dismissed as UX theater — and rightly so — but it can certainly feel like research to inexperienced practitioners. After all, the PMs talked to customers, and gathered feedback and feature ideas, which they used to create a roadmap and then a prioritized backlog. What more could you want?
But the features delivered from that backlog will all contribute to the user experience rot, because they build on a premise of solving the product problem of “missing features” rather than the customer problem of not being able to reach their goals.
Customer problems make teams; product problems break teams
When a work group establishes shared goals and methods to achieve these goals, it transforms into a team. — A Deeper Understanding of Real Teamwork and Sustainable Quality Culture
Product teams don’t realize they’re making this mistake because it’s baked into the stories-and-features way that PMs are trained to approach problems. Even Marty Cagan doesn’t consider “does it solve the user’s problem” to be one of the four big risks (“will people buy it” is the closest, but not the same thing at all).
Instead, Cagan slotted UX design (the function best suited to catch that risk) into the “usability” bucket, and many PMs followed.
As a result, the majority of time designers spend on product teams is dedicated to solving tool problems rather than goal problems — how to make a feature more usable, or how to add more options and settings. And given that every tool problem is by definition a problem created by the team, the overall impact of solving those problems is extremely low.
Of course, designers are equally guilty of solving design problems over customer problems. Or perhaps even more guilty, as our field is structured around incentives to design for other designers — dazzling our peers with awards and hiring managers with stunning portfolio visuals.
Software developers, of course, have their own version of this phenomenon; trying to learn about customer needs by shipping the MVP can quickly evolve into incrementally working out interesting coding problems at the cost of making measurable improvements to the user experience.
Creating this knife must have required solving a huge number of product, design, and engineering problems. But I cannot conceive of a customer problem that it solves.
As a result, the three “legs” of the product triad end up setting their own goals, and fighting over them. The prioritization process turns into haggling: we will solve this many product problems to this many design problems to this many developer problems.
While everyone is haggling for themselves, there is no time left to exercise all that empathy for the customer.
The result is an entire industry of products solving problems for its employees and the people who live like them.
Forget the product, focus on the customer
“Working backward from customer needs is a huge amount of work. But it will save you even more work later.” — Jeff Bezos
This issue runs deep. It is at the very root of how we talk about products: the framing that products are “desirable” to customers has influenced product thinking for over 20 years.
In reality, no products are desirable to customers. Customers have desirable outcomes, which products can help them reach. And while any successful product strategy must ultimately pick a level of outcome at which it wants to play, choosing to play at the widget level and then flailing for product-market fit before your funding runs out is the least effective level to play at.
Slide from hypothesis-driven product development
Instead of forecasting outputs based on what stakeholders are asking, product teams need to start with what stakeholders hope to achieve and then back-cast from those outcomes to chart possible paths forward.
Then instead of prioritizing features, you can choose a single bet without compromising your flexibility: which next step will help us learn the most about what a viable path forward looks like?
The result might not be the world’s sexiest app. The solution my team convinced the stubborn customer to build in the end had no web presence at all — because their users didn’t want to go to a website. We sent them the information they needed directly by SMS. But it was quick to build, cheap to test and — most importantly — it kept customers informed much better than a tracker on a website most of them would never see.
Stop inventing product problems; start solving customer problems was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
