Women are some of the problems of men lol

Hey guys good evening.

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.

And software developers 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.

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).

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?

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.

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.

When you get to the top, you will become the topic.

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.

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.