The product development function is arguably the most difficult job in any software company. Coming from an extensive technology background and having worked for decades alongside product-focused colleagues, even software development with its own spectrum of challenges feels less arduous in comparison.

This article by Pavel Samsonov puts a spotlight on a critical dysfunction that is quite prevalent in many product organizations. Below are just a few quotes. I suggest carving out a few minutes to read his piece in its entirety.

Low-performing teams choose problems based on what they’d like to solve rather than what their customers need.

Customer problems make teams; product problems break teams.

In reality, no products are desirable to customers. Customers have desirable outcomes, which products can help them reach.

His primary thesis is that the majority of product organizations are oriented around feature production rather than solving customer problems. In other words, the product becomes the focal point, not the needs of customers. To be clear, focusing on customer problems does not imply that software companies should be in the business of doing whatever customers ask. It simply means that the north star should be aligned to solving customer problems. Products follow.

This seems like a tireless debate, so I asked myself why organizations struggle to change despite knowing this approach, in theory, yields better results. That statement is my own assetion. Who knows whether results improve? Perhaps this is just an academic argument?

My curiosity is understanding the psychology of product teams and why they systemically operate as feature factories instead of problem solvers. Only then would it be possible to change behavior if desired.

In my estimation, which is primarily intuition based on years of observation, this is a company problem. There are forces outside the control of product and engineering teams that incentivize feature factory behavior. I really believe this is the crux of the issue. You get what you reward.

Both internal and external stakeholders, including customers, want predictability and certainty, so we measure output rather than outcome. When output is the focus of measurement, we end up organizing and operating around a backlog of features. This is easy to measure—did we get that widget delivered on time? Whether or not that feature solved a customer problem is not necessarily considered, because the measurement is oriented around output.

In contrast, when outcome is measured, features are sort of relegated to second-class citizens. They tend to be a way of organizing work—think epics and stories in agile parlance—but their completion is not a measure of performance. They are a means to an end, and that end is the desired outcome. Did we solve the customer problem? Measuring outcomes is not only demonstrably harder, because product teams have to clearly understand and articulate the customer problem, but there is usually institutional resistance from stakeholders due to expectations of certainty.

Of course, this is the duality of product development, which is inherently a creative function. There is nondeterminism built in. We cannot think of creativity and certainty in absolute terms. They are opposing forces that must find an equilibrium. If product design and software development were like an assembly line cranking out the same widget each time, then measuring output makes sense. Clearly, the notion of solving customer problems does not fit into that category of thinking.

I suppose the existential takeaway is that software companies will ultimately measure what they value. If incentives and rewards are aligned around certainty and the production of things, then measuring output makes sense. This is not meant to be a judgment in any way, but rather to create awareness of the inherent dichotomy of behaviors between solving product problems and solving customer problems.