On Reconnecting with Customer Context

One takeaway from the Jobs to be Done Framework is that we should place more attention upon the problems customers are attempting to solve when they "hire" our product, rather than focusing on our product and its features.

Such a basic idea, it makes you wonder why we need to talk about it in the first place. But we do, because something is standing in our way of seeing and doing the obvious.

There is a simple explanation for what's going on here. When we work on technically complex products, our attention naturally get pulled into its inner workings. This draws us away from the outside world where relationships are deepened and opportunities are discovered.

But let's be reminded of something else, too. It's the basic structural issue at play. Software product development is a specialized pursuit. Customers don't have the capabilities to build their own software in-house, they have to hire those of that do. The natural consequence of this arrangement is that software is built in a silo.

And so if you have been on either side - builder or user of enterprise software - there is often a persistent, nagging sense that something is basically wrong.

There is a wide gulf between producer and customer that prevents the creator from knowing exactly what to build and why. This is where enterprise sales teams have always played a part. They often discover the experience customers are trying to navigate during the sales cycle, as a sort of 'final mile' consideration.

Then there is the product team. Delivering a roadmap is one of the ultimate hand-wavy exercises in modern business. PMs are often preoccupied with the future of the product, not the future of customers using the product to achieve their own specific ends.

But the problem is not so much about individual actors. It's bigger than that, a structural issue that begins and ends with how we organize around problems. The need for technical intervention is carved out from its original context and a software product is built from a distance. The distance is bridged by a sales team that prioritizes efforts around a product built in the past, while the product team imparts an ideal image of a better future.

We have a choice on how to look at these interactions. One is to say to ourselves that this is inevitable, its just how tech works. Another is to ask ourselves whether they are connective or not. And if they do connect maker and user, what kind of connection is entailed?

Today more software companies place a strong emphasis on direct customer feedback and user research from the very beginning of the development cycle. But we need to go further. We need to organize around problems in more effective ways, removing the issues that come out of the software silo.