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.

Software Sales and Marketing

Joel Spolsky has an interesting (as usual) blog post about the role of sales and marketing in a software company. As someone with an engineering perspective, he used to think that a good software company could have no sales and marketing, only developers. Success was all about the product and its quality based on having good developers.

Now, he argues that “the more sales and marketing people you hire, the more you sell.” Sales and marketing multiply the effect of good quality developers. Product quality is still important: “The best marketing in the world cannot force people to pay for a useless product.”

I agree with his post. I’ve experienced working on good products that were not successful until they had a good sales force. The multiplying effect of good sales and marketing can be astonishing. Joel is absolutely right here.

However, Joel is missing an important effect of the politics of organizations. As sales and marketing grow in numbers and importance in a company, their influence on the features and future directions of products grows. Sales and marketing start having a big impact on product quality. I’m defining quality in the broad sense that quality is how well your product solves a customer’s problems.

Improving a product requires a delicate balance between giving customers what they want and giving them what they need. Customers always know what they want but many don’t know what they truly need. A great product solves the customer’s real underlying need and may solve a problem that the they didn’t even realize they had.

Sales and marketing often start dictating features based on customer prospect’s criticism of your product during a competitive evaluation. Sometimes these features identify important gaps in your product, but often it’s a reaction to claims by competitors. Adding these kinds of feature sets can distort your product into strange, unnatural shapes all in an effort to listen to customers or potential customers. I’ve added features to products that sales people insisted were critical to get more sales only to find that those features made no difference to sales but hurt quality because they didn’t really belong in the product.

The canonical case of sales and marketing’s malign influence on quality is the competitive checklist. You have to have features that match every competitor’s features. You have to have a feature for every item on the checklist. This can lead to implementing features that make no sense. It often leads to quick and dirty implementations to get sales off engineering’s back. The competitive checklist can be a terrible dictator of product direction.

Also, customers often have wants or needs that are peculiar to their own situation but not generally applicable. If you add features for just one (usually large) customer, your product can get distorted and start looking unusable to other customers.

Overall, I agree with Joel. At FogCreek Software, I’m sure that he will never let sales and marketing degrade product quality. However, I’ve seen sales and marketing hurt product quality so many times that I think FogCreek is the exception, not the rule. Every great product needs a visionary to maintain and improve quality, and that visionary usually comes from the people who develop the product, not sales and marketing.