A lot has been written on the topic of being customer focused, and although we could find countless resources on the topic what we encountered more often than not were very solution oriented businesses. We usually didn’t have to look further than their Jira backlog to see long list of solutions described in sparse detail or lengthy summaries. Some organizations were very good at churning out features, while others struggled. But these solution oriented businesses had one thing in common, adoption of new features and products was very low, in many cases features would be moth-balled with some regulatiry.

In defense of us all, solution thinking is natural; it is often easier to describe a solution that a problem. And customers are used to interacting with companies via feature request. What product team doesn’t love receiving feature request? The answer happens to be product teams that receive far to many of them or far to few. When you receive too many feature request it can be difficult to manage and prioritize which request to take on first. When you have to few feature request it is equally difficult to know what the customer needs next. Feature request are difficult to track for some teams, and so some ideas never get captured, others get ignored.

A feature request however is simply an idea a customer shares with you to make you understand how they are using your product, and what they expect from your product to offer them a better user experience. This is one of the alluring aspects of feature request, they show us a real-life picture of how our end-users are making use our products. The problem is feature request are not great at helping us understand the problem well enough to design the right solution.

Feature request are great pieces of evidence showing the existence of a problem that your users have. And this is the real power of them. The secret however lies in the customer problem. Not in the feature request. And so to truly be customer focused you should not focus on designing solutions based on things such as feature request – focus instead on defining and prioritizing problems. Focusing on the problem instead of the solution has a lot of benefits:

• You focus your resources on the user’s needs, what you can do to satisfy those needs, and why you need to solve it – not how. I refer to this with my teams as “Staying in problem space”.

• Your collective understanding of the users needs become rich in background information which helps everyone involved make connections and find solutions that might not otherwise be obvious.

• You avoid tunnel vision – instead of focusing on one single solution focusing on the problem and describing it well expands the realm of the possible and promotes innovation.

Enter Problem Description Language

We found the best way to develop solutions that customers actually wanted was for us to reframe their request and our focus directly on their problem. To do this we wanted to put some very light structure in place that could be used consistently across teams and organizations. And so Problem Description Language was born, it is simply a non-domain specific business readable description of a customer problem. Problem Description Language re-frames solutions and feature request as problems to be solved for.

Say for example you receive a request from a customer (or sales, or anyone else for that matter) to add a feature that automatically fills in fields. If we designed and built a feature that simply allowed a customer to save input field data and later fill the that information in, we may end up with a system that collects more information than needed and requires additional database management. Decisions about how to store and safeguard the saved data are also called into question. If instead we re-framed this feature request using Problem Description Language then we would say something like the following: “How can I avoid having to retype the same information in different forms?".

Using this framework we now can focus on the problem the customer actually has, and gather evidence of this problem. Again, the feature request may have come with more details such as “I have to fill in the address every single time I am presented with with an address field”. It may not have been accompanied by any additional details but either way this is where we would gather further evidence of the problem. Evidence can come from conversations in chat with customers or other members of your organization. Specifically we provide a tool that captures customer conversations and allows you to keep track of the problem and the evidence associated with the problems. Other forms of evidence you will want to help understand the problem may be user surveys, customer interviews, analyst research - really anywhere you can find verifiable evidence of the problem.

Although new feature request are great, often what we receive are request for improved functionality, again, in order to stay focused on the customer we would want to approach these types of request using Problem Description Language to find the solution that the customer will actually use if we build it. I will use another real world example to illustrate, let’s say you receive a request to “increase the performance time of queries”. There are likely more than a few ways you could go about this, and in this case since we are talking about improving functionality there is a good chance the customer will use what ever solution we provide since they are telling us right now that they see more value from the current solution if we improve on it in the ways they are asking. The balance we often have to make is how changes to our system affect other parts of the system, how long it may take to make those changes, the cost associated with the changes etc., in order for us to deliver the feature. And so by re-framing the request using Problem Description Language then we would say something like the following: “How can I as a systems analyst perform faster queries?". This time we added some additional information in the Problem Description Language - the persona that the problem is associated with. This immediately provides additional context and background information which in our case we knew that systems analyst only worked with data sets over 5gbs. And so of the two possible solutions we were exploring, indexing the database or re-writing the schema definitions, both of which we knew would improve performance and both of which we knew we wanted to do, it became far easier to prioritize between the solutions and deliver the feature request that met the users needs and expectations.

The true test of wether you are being customer focused is in how you handles difficult or especially stressful product decisions. When a deal is stuck or a customer is ready to walk because of some problem with your product, how does your organization respond?

Is it stop everything and change the roadmap based on the loudest or most senior voices in the room? Or is there a sense of urgency (not panic), to understand the customers problems and come up with an effective solution?

One of the behaviors I have observed and admire in companies that are truly customer focused, is that the leadership is as problem focused as the product teams are. This sends a very clear message to everyone as to the importance, without resorting to micro-management and creates a culture that promotes learning.

Problem Description Language solves many of the problems that exist with solution oriented product management and allows you to innovate on behalf of your customers - without turning your development teams into feature factories.