Sympathetic Developers - Good thing for everyone

Most developers live shielded lives away from customers and users. They're typically heads down in their own piece of the puzzle and rarely do they actually have a chance to use the product as their intended users would. Their interaction is limited to other developers and product management. Every so often, when things get really critical with a support case, they may get pulled in to resolve an issue but they're still very protected and are not exposed to customers directly.

While you can argue that it's not their job to interact with customers directly and they should indeed focus on their piece of the puzzle, this would only serve to limit developers' appreciation for customer needs (and pain) and how the product is actually used (or not used). A little direct exposure to the front line can only serve to help them grow to a more well rounded contributor. You may also find that some direct customer contact can help your developers be more empathetic with your support and services staff too.

So how do you get your engineering team enough direct exposure without totally disrupting your product development?

I would recommend 2 different approaches.

1. Create a program where by each developer will spend 2 weeks (1 week every 6 months) a year in either a support or services role. During this time, they are fully immersed in the role they're taking and responsible for any and all customer interaction that the job entails from logging new incidents to working with engineering to resolve issues to communicating with the customer. It may be hard at first for some and they may resist it but they'll eventually see the light.
2. Make 5-10% of the compensation dependent on overall customer satisfaction. Satisfaction starts with a quality product so why not have a portion of an engineer's compensation based on it. To make this happen, you need to put in a process where by you solicit feedback and rate customer satisfaction as objectively as possible (i.e. forget all the marketing on your external web page).  You can use a combination of data collected from logged incidents to periodic surveys to determine level of satisfaction at any given time period and with specific product releases. I would actually recommend creating an active dashboard using (preferably) a cloud-based analytics solution (Try GoodData) and display it some where your engineering team (and the rest of the company) sees it every day. 

Familiar Excuse: It works as designed.

You get a long awaited product release and dive right in to find the feature you were most interested in only to find utter disappointment. The feature is there but it doesn't quite work as it should. It's either entirely useless or requires a workaround right from the get go which is absurd.

You walk down the aisle to talk to the developer to see what's going on but you find a defensive developer that gives you the familiar (and illogical) "it works as designed" excuse. Well, the design had a BUG that no one caught! The developer probably realizes (you hope) that there is a genuine issue but instead of owning up to it, he/she directs you to the product manager responsible for the feature. Well, the PM gives you a more tactful answer by telling you that what you're asking for should be filed as an enhancement that YOU should file and they will work on including it in some future release (not patch) depending on the level of effort and timing. So, a new feature sits there useless till some future release for it to actually be useful and work. Who signed off on that?!

There are such things as design bugs and should be addressed with the same sense of urgency as coding errors, asap. The ownership falls with product management and engineering both to make sure function/features make sense and actually work. If in doubt, ask your customers. I'd rather a feature be delayed and work right then be released and require an immediate workaround.