3 ms·

How short sighted. The biggest failure I see in software these days is software developers who are so far away from their customers that they build the wrong t

by mabbo 9y ago

How short sighted. The biggest failure I see in software these days is software developers who are so far away from their customers that they build the wrong thing. They build what they think is a good idea, and not what the customer actually needs. We aren't all Steve Jobs, predicting and making the future. Most of us need to instead understand the customer. Working customer support? That's a fantastic way to get to know what your customers want.

rleigh 9y ago
Absolutely agreed. In a previous job, I was hired as a developer for a small company and also took most of the service/support calls. It gives a huge amount of insight into how people use the software/hardware, where they get stuck most frequently and also where any bugs lie. We made most of the changes to the software as a direct result of customer feedback, targetted to the areas which generated the most calls because they caused the most problems for the user. Simple usability/workflow improvements significantly reduced the call volume and made the customers much happier with the software. It also meant that in cases where bugs were found, we could triage them directly on the call or shortly after and in many cases have a tested software update for them during the same working day. When someone runs their business with your product, they greatly appreciate the effort you make to keep their business running smoothly. I learned a lot about our customers' businesses by talking to them, even visted a few in person, and that all helped to make our software serve them better. I had a few surprised callers when they realised that the tech support and the developers were one and the same; they often expected the tech support to be stupid/less well informed/script-following automatons, and were surprised when we could help them in great detail. Very few of them expected that suggestions for improvement would actually be acted upon, let alone implemented and delivered within a short timeframe. In a small company, with customer numbers in the small hundreds, this led to direct personal working relationships between the end users/customers and the developers, which I found very satisfying. Were we shielded from the customers by first-line support etc., we would have missed out on a lot of very valuable information. Of course, it's difficult to scale this approach, but I do think developers should be well exposed to end users' problems, needs and specific business/domain expertise in whatever type of organisation they are part of, rather than being isolated and disconnected. This is not in any way "insulting" to your team as the original article tries to justify; it's giving your team knowledge and understanding which they would otherwise not have, and getting them directly involved with the use of the software as well as its creation and maintenance.
FLUX-YOU 9y ago
>They build what they think is a good idea, and not what the customer actually needs. That is what good PMs are for (ignoring many customers don't know what they want or change their mind). Have you guys ever thought about how it feels to have a software dev just dropped in your lap with his boss telling you to put him to work?
torrinson 9y ago
But the article suggests that software developers should understand what customers are saying and gives several suggestions on how to do that.

by mabbo 9y ago

rleigh 9y ago

Absolutely agreed. In a previous job, I was hired as a developer for a small company and also took most of the service/support calls. It gives a huge amount of insight into how people use the software/hardware, where they get stuck most frequently and also where any bugs lie. We made most of the changes to the software as a direct result of customer feedback, targetted to the areas which generated the most calls because they caused the most problems for the user. Simple usability/workflow improvements significantly reduced the call volume and made the customers much happier with the software. It also meant that in cases where bugs were found, we could triage them directly on the call or shortly after and in many cases have a tested software update for them during the same working day. When someone runs their business with your product, they greatly appreciate the effort you make to keep their business running smoothly. I learned a lot about our customers' businesses by talking to them, even visted a few in person, and that all helped to make our software serve them better. I had a few surprised callers when they realised that the tech support and the developers were one and the same; they often expected the tech support to be stupid/less well informed/script-following automatons, and were surprised when we could help them in great detail. Very few of them expected that suggestions for improvement would actually be acted upon, let alone implemented and delivered within a short timeframe. In a small company, with customer numbers in the small hundreds, this led to direct personal working relationships between the end users/customers and the developers, which I found very satisfying. Were we shielded from the customers by first-line support etc., we would have missed out on a lot of very valuable information. Of course, it's difficult to scale this approach, but I do think developers should be well exposed to end users' problems, needs and specific business/domain expertise in whatever type of organisation they are part of, rather than being isolated and disconnected. This is not in any way "insulting" to your team as the original article tries to justify; it's giving your team knowledge and understanding which they would otherwise not have, and getting them directly involved with the use of the software as well as its creation and maintenance.

FLUX-YOU 9y ago

>They build what they think is a good idea, and not what the customer actually needs. That is what good PMs are for (ignoring many customers don't know what they want or change their mind). Have you guys ever thought about how it feels to have a software dev just dropped in your lap with his boss telling you to put him to work?

torrinson 9y ago

But the article suggests that software developers should understand what customers are saying and gives several suggestions on how to do that.