Trust in the Heavenly Father

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.

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.

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

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.