Customers Own the Problem, You Own the Solution

Great advice I received this week: if you’re a product team working with customers, help your customers separate the problem from the solution. Once you’ve distinguished problem and solution, you’re able to establish clear ownership: the customers own the problem; the product team owns the solution.

The trap product teams fall into is taking the customer’s unquestionable expertise in the problem domain and projecting that expertise into the solution domain. “Well, these people really know what they’re doing and they told us EXACTLY what will fix their problem. So let’s just do it and make our customers happy!”

If you do this as a product team, you’re hurting your customers even as you make them happy by doing what they asked. Why? Because you’re ignoring your own expertise and unintentionally setting ceilings on how much value you can deliver to your customers and how quickly.

The product team is the expert on the hidden details of how the current system is implemented. The product team also knows what other demands are being made on them as an organization: problems other customers are having, tech debt that needs addressed, changes in manpower and resources. That gives the product team the ability to conceive of creative ways to tune the value / speed ratio.

Let’s say your customers come to you with a problem they’re eager to have fixed. They use this workflow every day and they have a manual workaround that they’ve been doing. All your product team needs to do is implement their manual workaround as a feature! You can do that, but it will take an entire quarter. That’s okay, they say, they’ll wait.

A quarter goes by. You’ve met with the customer, updated them on your progress, and finally you have the handoff meeting. They’re very pleased to have the fix! Near the end of the meeting they bring up another issue they’ve been having. It’s similar to the first problem - maybe the fix is easy? Not really, you say. The way you implemented the fix doesn’t really address more basic problems in the data that backs the workflow. It’ll be another quarter…

Compare this to a world where the customer owns the problem but doesn’t prescribe a solution. You think creatively based on your knowledge of the system, other features in the roadmap, and what the alternatives are. You recommend a slice of the value to be delivered in a month, as the first vertical of a bigger effort to port their workflow to a new platform. Future problems they have will be easier to address because you’ll be on a new platform that allows for light-weight data schema changes.

Now the customer gets SOME (but not all) value way sooner, and their future problems will be easier to fix. They didn’t get the solution they thought they wanted. But they might be happy to make the trade if you can frame the tradeoff to them in a way that makes sense.

It’s in the customer’s best interest not to prescribe the solution, and it’s in the engineer’s best interest to 1) listen closely to the problem and 2) get creative. Don’t shut your brain off because the customers are experts in their domain. You’re still the expert in yours.