Low-performing teams choose problems based on what theyd 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 arefacing.A couple of years back, a customer came to me with a request: Our CEO tried to use our product. His transaction didnt go through and he couldnt see its status. So customers being able to track their transaction is a priority problem that we need tosolve.Im sure youve already spotted the snag: the problem in their statement was users dont have thistool.In other words, it was a solution statement in disguise.But we couldnt convince the customers 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 customers team realized what we had told them in the first week: that they were trying to solve a product problem rather than a customerproblem.The road to the Build Trap is paved with productproblemsThe 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 BuildTrapThis was hardly the only time that a customers 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 defineit.This makes sense because of how these teams are typically organizednot 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 stakeholderslike that customers CEOthey skip right to the formfactor.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 teams efforts. Other mandates youve likely seen pop up in the news include users want a chatbot, users want a dashboard or users want a subscription to theirmouse.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 teams 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 youre on the wrong track; when you ask what features do you want the dashboard to have then unless youre reading between the lines all youll never hear users dont 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 theaterand rightly sobut 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 youwant?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 theirgoals.Customer problems make teams; product problems breakteamsWhen 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 QualityCultureProduct teams dont realize theyre making this mistake because its baked into the stories-and-features way that PMs are trained to approach problems. Even Marty Cagan doesnt consider does it solve the users problem to be one of the four big risks (will people buy it is the closest, but not the same thing atall).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 problemshow 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 designersdazzling 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 itsolves.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 likethem.Forget the product, focus on thecustomerWorking backward from customer needs is a huge amount of work. But it will save you even more work later.JeffBezosThis 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 20years.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 playat.Slide from hypothesis-driven product developmentInstead 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 pathsforward.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 lookslike?The result might not be the worlds sexiest app. The solution my team convinced the stubborn customer to build in the end had no web presence at allbecause their users didnt 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 andmost importantlyit kept customers informed much better than a tracker on a website most of them would neversee.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.