Talking to Customers

For a developer, one of the disadvantages of working for a large software company is that you rarely interact directly with customers. In fact, I've worked on products where I never once talked to a customer. There are many insulating layers between me and customers. This lack of contact has its biggest impact with feature requirements. Typically, I work from a Product Requirements Document (PRD) that was written by a Product Management team. That group does have some contact with customers and also does competitive analysis and looks at internal product integration issues as well. Also, sales, marketing, and various people in management are also involved in creating the PRD. The resulting requirements can be quite divorced from what any particular customers wanted originally.

Recently I had the opportunity to work directly with a small group of customers on requirements for security features for the Coherence product. This group represents a few of our largest customers, and, most importantly, they had an urgent need for new security features. They were coming under increasing internal pressure from security auditors to make changes to their use of Coherence. However, it was nearly impossible for them to satisfy their internal needs because of a few missing features in Coherence. We had a conference call (due to my being 3,000 miles away) in which they laid out the product changes they wanted. After the meeting, I wrote up their suggestions along with a proposal. We had a few rounds of email with proposals and counter proposals and a follow up conference call to reach a final consensus. It turned out to be a straightforward and pleasant process. Largely that was because these particular customers are friendly, knowledgeable, and very reasonable. It was a pleasure working with them. Another developer, Jason Howes, also had substantial input into the suggested features. The final result was a short (3 pages), concise description of the requirements and the resulting features. This document was reviewed by Product Management but not changed by them. It was not impacted by sales or marketing or management in any way.

The next step was to come up with a design and proposed implementation, which was reviewed by Jason Howes and Gene Gleyzer. Jason and Gene were critical in helping to decide on the final design and implementation approach. They also reviewed my code very thoroughly and helpfully. Jason also wrote a key part of the implementation. The teamwork of the Coherence development group is an extremely important factor in the success of these features and the product in general. Everybody talks about the importance of teamwork, but there's usually a big gap between talk and action.

The final result in Coherence 3.6 is presented by me in this screencast.

So, what't the point of this story? Large software companies need to find ways to get developers in contact with customers. There's a balance, of course, because developers need to be focused on writing new code (and fixing bugs). However, most large software companies completely isolate their developers. Partly this is do to a belief at many companies that what developers due is mere coding. This philosophy says, let the knowledgeable people write the requirements. Developers are just smart typists who turn words into code. Obviously, I completely disagree. The best products are written by developers deeply involved in understanding the problems the product is trying to solve. The Coherence development team talks with and meets customers regularly and the product reflects that closeness and will continue to improve because of it.