In this interview with Werner Vogels, the CTO of Amazon, he outlines how Amazon's developers stay in touch with their users:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/12/sharing-the-customers-pain.html
It’s not just the developers that need to be in tune with the customer, it’s often a problem that management has their own ideas about how things should work that is not based on customer feedback or customer experience studies. In my experience, questionable decisions or goals by management contribute just as much as developers for process flow, site design, content, or presentation problems that customers may experience.
Hey Now Jeff,
UAT User Acceptance Testing is a great thing.
Coding Horror Fan,
I find that working with customers, or keeping customers in mind, helps develop concrete features with reasonable limits and permutations.
For instance you are developing a File Utility software product that a) Compresses files, b) Defrags Files, and c) Encrypts Files in a given directory.
A super-star Engineer sitting in their Ivory Tower would design this software product such that it can process directories with millions of files, and must be able to compress, defrag, and encrypt files in a single pass. This increases the complexity of the code since for each block of data trying to be processed you have to handle all the features. At the same time, this engineer using he wicked technical ability makes it such that you can still access your files while all the processing occurs in the background.
However the customer doesn’t really have directories with a million files, may a 1000 or 10000 at most. He doesn’t have need to compress and use his files at the same time. And he never defrags, compresses, and encrypts his files at the same time, only does one of the features at a time.
Had this super engineer listened to the customer he could have design a simple and effective tool, instead he created a complex piece of shit that has to be maintained too in the coming years.
Absolutely true! I’m a technical lead for NetResults Tracker, a web-based collaboration tool, and I spend at least 10% of my day browsing customer emails our support responses and see how really customers use our application to fulfil their need. This has helped us a lot in building a better product focusing on the customer.
Every engineer who gets into our team initially goes thru’ at least a year in handling support emails for 10-20% of their day-time. Well, I feel it is worth it, as you say.
I agree that engineers should share the customers pain by doing support. Visiting onsite and seeing it live in action is a must too. I worked for a medical record company once, and nothing was cooler than going to the ER and seeing the dialog boxes I wrote up on the screens of all the doctor’s workstations.
However, nothing sucks the life out of developers and frustrates them more than supporting the crappy legacy VB/FoxPro/Clipper/Clarion versions of software they know nothing about. In those all-too-common situations, the developer just ends up loosing respect for the company, because they see how aggravated the customer is, and there’s nothing the developer can do to help.
In those situations, I think it’d be better to keep the bright, shiny .NET/Java developers away from your company’s steaming pile of COBOL…
I don’t think that the real problem is the ivory tower principle as much as the fact that a lot of times, you never even get to meet your user. The bigger problem is that your user is not always your customer. And then, on top of that, you usually have to get your info or take direction from people who don’t know what they are talking about and don’t understand the development process, and they inject their opinions in the discussion as if they are fact.
An developer who doesn’t want to make the user’s life better is not worth a grain of salt. The problem is that most time, even when we do want to make the user’s life better, we don’t get the chance.
In most companies, they have specific policies in place so that you, an unwashed developer, can NEVER meet the user of your software, and can NEVER interact with them. In fact, they are downright hostile if you do insist on knowing them… or inadvertently talk to a customer in a training class.
Happily, I left that place. Not all companies are like where you work, Jeff. Such is the tragedy.
Software is a conversation. Be polite.
If you were watching your grandmother fumbling and struggling to look for a file, would you just say “File not found. OK?” and stand there silently after she failed? No, you’d offer to help. Offer suggestions, perhaps even go look for the thing yourself and gently lead her to success.
Focus stealing, as discussed yesterday, is simple rudeness, as are cryptic, lazy, unhelpful, arrogant error messages. We’ve all seen them. Error messages that are gosh, totally truthful… and totally useless.
If you think of software as a way of communicating, just like a letter, or IM, it changes the way you build the interactive parts.
If you can it’s fascinating and instructive to watch other people just get on with their day to day work. People do the same things so very differently, and if you’re not careful you will design something that only suits one way of working to the detriment of others.
That’s similar to one of the things I love about my job. Yes, I’m tech support, but we are no less important than our programmers. Where I am, we are the public face of our company (and a strong selling point). And we also have full access to the programmers, if need be, they can even be brought into the discussion. Just today I had to grab one of the programmers who wrote a few custom apps so we could solve one of our customer’s problems. There’s always open communication between the two departments, and the customers know and appreciate it.
I was waiting for someone to link the Microsoft “Share Pain” button video, which makes this theoretical concept very real:
Tsk! you guys and gals disappoint.
I agree, Jeff!!
I had an opportunity(I agreed rather reluctantly) to work in the Customer Support division of our company. And I clearly see the difference in my understanding of “software as a tool” concept in the period before and after my tenure.
It surely is an eyeopener…
“When was the last time you even met a customer, much less tried to talk to them about a problem they’re having with your website or software?”
I work on-site for our customers. I couldn’t avoid the users even if I wanted to. Then again, I work for a consultancy firm, so our culture is a lot different than in a packaged software or typical Web development shop. Our business is based on personal interaction; if we didn’t talk to our customers, and understand where they’re coming from vis-a-vis their comfort level with technology, we wouldn’t continue to get contracts.
By contrast, when I worked at Microsoft, we didn’t have a “natural” interaction with the customer; we were on Campus, and they were scattered around the globe. MS’s Developer Division (the division that produces Visual Studio, and where I worked) addressed this by having developers sit in with Dev Support reps. We also had regular monthly bug meetings with Dev Support tech leads to find out what were the 10 largest developer issues we needed to address in the next version of the product. On top of that, DevDiv groups went out of their way to meet with customers, set up Tech Labs to preview Alpha and Beta builds, and solicit feedback from the dev community through the Community Preview program.
There are any number of ways developers can stay in contact with customers, regardless of industry.
Look at yesterdays post. Many at Microsoft are no doubt just as annoyed by focus stealing as the rest of us. They do share the pain. They just chose to ignore it. Talking to customers is great but if you ignore you own problems what are the chances you’ll take theirs seriously.
This is a good case for open source software development making for better developers. If you choose to join in on a project you actually use (good examples for me would be Subtext or RSS Bandit), then you get a chance to share the pain. Some quick benefits I can see gained from living on both sides of the fence are:
- Enhanced visibility to potential problems arising from code/feature changes.
- Great insight into bug priority.
Site visits are also good. Then you can see how the software is used without having to solve the immediate problem.
I agree that in-house programs have an easier time of this (the customer knows where your desk is :).
For the last project, our first step was to sit down the users and ask “how do you want this to work?”. Not in the technical sense, but in the user sense - I need to do steps A, B, C, D…
We then built the UI to work the way the users expected it to work. The revisions were largely (a) the build team suggesting more efficient processes (that would then be codified into the system), and (b) the users showing places where it was inconvienent to use (which were then streamlined).
It worked remarkably well.
That is why I maintain that all software developers should be required to maintain a strong presence in your site’s online support forums, newsgroups, or whatever. They need to be there, end of story.
Excellent point, and every developer would benefit from few weeks of intensive customer contact, either through support, on-site relocation or training services. Where I work, there is no such arrangement, but I will argue that I nevertheless have achieved pretty much the same by working as a software consultant for 5 years, until 4 months ago. Pre-that I was software developer, and am one now too. A better one, I think, thanks to consultancy and close relationships with my end users.