Talk to your customers

I have heard something multiple times this week, something that has me a bit concerned. The gist of the sentiment is something like this: “Oh, we discourage the developers from talking to customers; we don’t want them to be distracted from their work or to build a bunch of stuff that’s not in the plan”.

If you are working in an agile environment, this sentiment is outdated and harmful. We want developers to understand the customers and have empathy for them, and there is no substitute for direct interaction for building that understanding.Let me start by discussing the agile mindset regarding developer-customer interaction, then address the concerns expressed in the statement.

Cross Functional Teams

Agile, and specifically scrum, relies heavily on the idea that cross functional teams build better stuff. While product managers, sales people, and similar roles have responsibility for understanding the customer problem space and communicating it to developers, and agile teams typically have a Product Owner for a similar purpose, agile teams see that expertise as a part of their team, not a separate group. The most effective development teams try to learn as much about the customer problem space as possible. They make multiple small decisions every day about how to solve customer problems. Requiring all knowledge about those problems to be siloed in one person or group, and separating that group from the team creates an unnecessary bottleneck to the system. Once developers understand the Why of what they are developing, they become much more engaged, championing solutions that they think will best help their users.


Great products emerge from experimenting in the overlap between the customer problem space and the technical possibility space. Developers know the second space well, but can only know the first space through experience either as an actual customer or through talking to customers. In my experience, great products are rarely built without the developers having a good idea of how their customers think, and more importantly, empathy for their problems. Chip and Dan Heath give a great example of this in their book Switch. They describe a Microsoft team full of brilliant developers. They were certain they were writing brilliant software, but when the usability group tested it with users, six out of 10 customers couldn’t figure out how to use the new features. When they told the programmers, their response was, “Where did you find six dumb people?” To increase empathy, Microsoft brought the programmers into a usability-testing lab and put them behind a two-way mirror. When the programmers watched a real customer struggle with the software they designed, the programmers immediately started thinking about ways of changing it. They were developing empathy for the users, and instead of contempt for their ineptitude, they developed an intrinsic desire to improve the software to better meet the needs of the customers.

But what about those concerns?

“…we don’t want them to be distracted from their work…”

In his book Radical Management, Steve Denning describes a shift in the way that we describe the high level goals of everyone at a company. He proposes that the primary goal of every employee is to “Delight Customers”, and that companies should set measurable goals for the company, executives, and employees related to this purpose. In this light, the idea that a developer’s work can be summarized as “writing code” feels almost insulting. Great software teams tend to spend the vast majority of their time figuring out what problems their users are facing, potential solutions to those problems, and the best technical approach to solving those problems. A small percentage of their time is spent actually typing code. In this environment, “their work” is not just writing code, but delighting customers.

“…we don’t want them to build a bunch of stuff that’s not in the plan…”

This one’s pretty easy to address in an agile environment. One of the simple rules of scrum is this: “if it’s not in the product backlog, we don’t work on it”. This provides transparency to the system.

Another potential concern:

“…developers will promise customers stuff that we can’t deliver…”

Sales people have been doing this for decades, so this isn’t much different <grin>. At least if developers promise something, they get to experience a direct consequence of their action, so the behavior is likely to improve.

So get out of the building, talk to customers, find out what’s driving them crazy. Scrum says that developers should spend 10% of their time on forward looking backlog refinement. What if they spent an additional 10% of their time talking to customers? Would we have a higher chance of delighting customers? It’s an interesting hypothesis. Anyone care to test it?

2 Responses to Talk to your customers

  1. Devin Rickard says:

    Nice post Peter! There are probably more excuses for not engaging with customers than could be fit into a thousand blog posts. Perhaps the best one is “I just don’t feel comfortable talking to people, let alone customers. And I really don’t feel comfortable with the thought of soliciting those customers to tell me what is wrong with my product.” 😉 Fortunately, there are many ways to get excellent customer feedback that don’t evoke the professional equivalent of asking the coolest girl in the school to the prom. (whew!)

    For me the take away is – we all have customers. And regardless of our role, be it developers, testers, trainers, marketers, etc. what we produce for our customers will be better if we take the time to understand who our customers are and what is most important to them.

    – Devin –

  2. Mark says:

    Interesting post.

    I think it’s useful for developers to be involved with customers early in each cycle, discussing and refining concepts. It’s important the empathy is balanced from both sides. The developers wishes to simplify and generalize should be respected as much as the customers wishes to try something innovative and new.

    The best products come from companies where neither voice is allowed to drown out the others, true collaboration.

    If the customer’s voice it too noisy, your developer will get fat on late night Domino’s pizza. And generally for a string of minor subjective reasons rather than anything useful or functional. The risk is the developer will dig his own grave trying to meet all of the demands of the customer (no matter how unreasonable those may be). You could end up with a project which is neither maintainable nor scalable.