Talking to customers is not a waste of a developer’s time

Image source: https://www.talkbass.com/attachments/animusic-jpg.465226/

I’ve often made the case here for a broad, inclusive practice of talking to your customers. The concept rarely gets any pushback. In practice though, there’s more resistance to this idea than successful implementation of it. The main argument? Doing customer research is a waste of a developer’s time. (Feel free to replace “developer” with executive, QA, etc). The argument continues that we hired our developers to write code and anything that takes them away from that task is a distraction to be minimized. 

Good code is much more than bugs or performance

This mindset betrays an organizational belief that delivering code is the same thing as delivering value to customers. There are only two things delivering code are guaranteed to get you: (1) more code and (2) technical debt. Every line of code a developer writes will live forever in the continuous systems we build. It will require maintenance. It will build up debt over time. If we can’t guarantee that each line will deliver something of value to our users and the business, we shouldn’t write it. At the very least we shouldn’t push it to production.

Of course we need code to be bug free, high performance, secure and scalable. Good code should have all of those qualities. But all of those qualities are worthless if the feature we shipped doesn’t improve the user’s experience. Too often we push features for the exact organizational belief that developers have to be shipping something at any given time. But with a small investment of time we can dramatically improve the chances that the high quality code we’re shipping actually makes a meaningful impact to our customers. 

Developers who talk to customers write better code

Engineers who have regular contact with customers understand the problems they’re solving for their audience. They get a clear sense of what’s keeping the users from being successful right now. They may even learn what our customers are doing right now to achieve this particular goal. All of these insights provide meaning and purpose to the code these developers write. It pushes them to create software that goes well past “works as designed.” The insight gained from listening to customers inspires developers to refine an experience to a higher level than code that didn’t benefit from user insight. 

Understanding what a user is trying to accomplish means the features we ship stand a greater chance of success. This directly translates into less refactoring, less redesigning and higher usage and success for these ideas. The developers involved with these features actually reduce wasteful coding by not building features nobody wants or that don’t solve the actual problem our users have. 

More customer insight equals better code, less waste

Lean principles teach us to remove waste from the process. Anything we’re doing that doesn’t lead to customer value should be removed from the process. Writing code for features nobody wants is waste. Maintaining features no one is using is waste. Adding bloat to a product is waste. Spending time negotiating priorities without evidence-based context is waste. All of these can be minimized if getting our developer to talk to customers was the path of least resistance. This isn’t a hard concept to implement but it does take a fundamental mindset shift into what a developer should do at work and what the organization defines as “value.”