Kathy Sierra's Blog

Have your developers seen a real customer in the wild?

A couple of years ago, I addressed an all-hands meeting for a small division of a Very Big Computer Company I Won't Name. This little division had just over 100 employees. I began with a single question, "How many of you have seen a customer in the last 30 days?" (about two hands went up.) "The last 90 days?" (one additional hand). "The last YEAR?" (couple more hands). So, these folks managed to maintain at least two degrees of separation from those who ultimately received their work.

Nice, that. When they don't have to see or talk to customers, they can tell themselves happy little stories like, "This is what our customers want." or "It's not our fault." Meanwhile, those of us who *did* face the customer, almost daily, took the heat. Sure, these other employees heard about quality problems--reports were generated each month, and groups with especially poor quality were "spoken to". But I was astonished by just how poor the quality had to be before it was considered unacceptable. And sure, there were plenty of regular reports with titles like, "Voice of the Customer", where we were given info about what the customers (faceless and nameless) supposedly said and wanted. But there was no *real* voice (the kind you could actually hear) behind the report. No real human with stress of his own. No person whose life we were actually affecting, good or bad.

It seems that as long as customers remain some abstract concept and not real living, breathing, humans, people can justify an awful lot of crappy quality. Meanwhile, the folks who *do* interact with the customer are often among the lowest-paid (receptionists, customer service, entry-level tech support, etc., phone order processors). Hardly anyone ever paid attention to what these folks had to say, and instead listened only to others of their own kind... the kind who did lots of Really Important Work in a nice, hermetically-sealed customer-free environment. No messy clients to get in the way of the real work.

The most depressing part of this story is that the facility where these folks worked had customers in-house virtually every day. Lots of them. If only the employees would walk the 400 yards or so down the main campus hallway. But I decided that if I couldn't bring the employees to the customers, I'd bring the customers to the employees. At least in video. So I grabbed someone with a video camera, and I randomly asked some customers if they'd spend five minutes and let us interview them. Nobody refused.

At first I thought, "Oh, this'll be perfect--these customers will complain and that'll *really* show these employees the negative impact of their work, and that should motivate them to improve. They can't just throw their work over the fence and forget about the impact." And then I began the interviews. Did the customers complain? Oh absolutely. Clearly. Explicitly. "Yes!" I thought, "This is good stuff. This will work."

But then something else happened during the interviews.

Something completely unexpected.

Without prompting, many of the customers insisted on explaining the ways in which the products and services had affected their lives in a *positive* way. In a heartfelt way. In a few cases, a life-changing way! These were living, breathing humans... with more than just a checklist of complaints. They had fears. They had stress. They had dreams. I caught them on camera talking about how this particular service had given them a new direction in their career. One guy said that he never imagined he'd be able to accomplish the things he could do now that he had one of our products, and you could almost see his self-esteem ratcheting up. One woman claimed that a week working with the training and support staff had taken her from hyper-anxiety to relief and hope that things in her work life would improve in ways that truly, deeply mattered to her.

My first reaction was to edit the hell out of it. "Gotta take out that positive stuff", I thought, "that will only *encourage* the employees to continue what they're doing, and make them think there's no need to improve."

But then I wondered... while attaching a name, face, and voice to a customer *complaint* might help improve quality, letting folks know just how important their work really is in HELPING someone's life might do even more. Knowing that someone really *cares* about your work is perhaps more important that simply knowing that someone *complains* about it.

So I left it all in (although I rearranged a few things so that the whole video presentation ended with the customers saying their most encouraging words). In a twist, my partner Bert was one of those interviewed customers. And shortly after that, he began telling me a story (I'm hoping he'll blog more about it, but here's my short version) about a software development job he had for about ten years. The company made extremely sophisticated AI-based broadcast scheduling software, that was initially sold to small radio stations and eventually made its way into large television stations and even cable channels like AMC and BET.

The story was that everyone--EVERYONE--in the company had to do regular rotations through tech support and customer training. Made no difference who you were. Managers. Algorithm gurus. Sales. Everybody had to spend time (and not just once at the beginning of their job) answering the damn support calls and teaching the customers how to use the software. Can you imagine? Can you picture what would happen if EVERYONE who worked on a software program had to spend time teaching customers to use it? If they had to experience the frustration not just during development, but AFTER it's deployed in the field?

Now, XP and other development models like "The Handcuff Technique" do make heavy use of customer input, often demanding that a customer be part of the development team. But what happens *after* the product is out in the world? How often are the developers involved and accountable to the customers *after* the product is deployed? And what would it be like if *everyone* in the company spoke with and--shocking--LOOKED at real customers on a regular basis?

But it can be done simply, quickly, and for virtually no budget. Borrow a video camera. There are no excuses these days--if you (or SOMEBODY there) has a machine with Mac OSX, you can get a cheap digital video camera and edit the video using the (free) iMovie software that comes with OSX. If you can't manage that, take still photos and a simple voice recorder and get them talking. It's crucial that developers (and everybody else on the team) hear the REAL voice of the customer (not just the printed, compiled, sanitized PAPER "voice of the customer" reports that many companies generate).

Then circulate the videos/pictures/voice recordings. Let your team know there are REAL humans back there. Let them know that thier work matters. Really matters. And no, it doesn't have to matter as in, "You're building the software that's going to save thousands of unwanted puppies..." It can be as simple as, "You just made this woman's life a tiny bit easier. And guess what, she's going to use that 10 extra minutes to check on her kids at the in-house company day care." Or maybe even, "You just made things a little more fun for this guy. He can now do something cooler and more interesting than he could before." Think about it. Think about the ways in which some of the simplest, most mundane-seeming products or services have had a butterfly effect on your world. And don't just do it once. Do it quarterly. Or monthly. Keep the customer's face in the employee's face.

Help your team find out how their work is changing lives, and it'll change the lives of your team. Even if it's just a tiny bit, the butterfly effect could be dramatic. It's so easy to think that our work just doesn't really matter in the real world. But it always does. Whether you're building a game, an eCommerce product, a training service, a book, a scheduling program, and even if you believe it's the most boring product or service in the world. If even a single human has to use it, you're having an effect. It really could change lives.

Or maybe I'm just caught up in the whole "It's a Wonderful Life" spirit of the season ; )

Comments

• Sounds like developers have forgotten their place.
  A developer's job is to write code. Period. They have a very focused and specialized trade and that is writing code which works and performs well.

  If your developer needs to be convinced that a feature or change is needed, then your developers are managing you and you are not managing your developers.

  It is the job of the product manager, business development manager, and marketing manager to make it their business to know what the market wants and to get customer feedback.

  If your product does not meet the needs of your market or is not satisfying your customer, you need to point the finger at the Marketing department first. If their research and PRD clearly articulated the market and customer needs, then they are off the hook. Then you have to find out why the development team didn't follow the PRD.

  If you find that your development department was too independant minded to listen to Marketing, then you need to replace your development management team with managers that can assemble and manage a team of developers that can follow directions.

  Quite frankly, if you interviewed the marketing department of the same company you would probably find that less marketing people have interacted with customers than the developers have. That would be a problem that would not surprise me. If you Marketing team is spending more than 30% of their time in your own offices, then they don't know your customers. They are the ones that need to be wearing out shoe leather in the field with customers and with the Sales teams.

  All too frequently, developers pretend that they know better about what the user/customer wants. It's at those times that you need to remind them that it is not their job to know or to even figure out. Their job is to write good code. You can always threaten to move this type of developer out of development and into Marketing if that is what they think they are good at. That ought to scare them straight!

  This is just another case of people trying to do other people's jobs at the expense of their own.

  If your developers are this involved with your customers, than your organization is broken and someone else is not doing their job.

  Posted by: jbob on December 23, 2003 at 07:42 AM

• Sounds like developers have forgotten their place.
  I like the scared straight idea ; )

  I'm not a manager, wasn't a manager, could never BE a manager. This company (and others I've worked for) probably had broken pieces all over the place, at least from a business process perspective (and despite the daily worship of the Six Sigma Way).

  But this isn't about whether the specifications are accurate and appropriate, or whether the developers are really writing to the spec.

  This also isn't about having developers go out and DO someone else's job (i.e. find out what the customers really want).

  This is about something more subtle, and it's about the *feeling* or underlying motivation that developers (and others) have about the nature of their work. It's about having a culture that makes the end-user customers real *people*.

  I've had managers claim that if everyone is doing their job properly, then each isolated group will be able to do their job perfectly, in a nice tidy little box, and the end result will be exactly what it should be, without anyone having to touch any other area. But that's what we said about the waterfall model, too. Not that this is a direct comparison, mind you, but the idea of nice tidy compartmentalism means that each part is assumed to be working correctly. And I simply didn't have the time -- or power -- to make that happen. In fact, I didn't have the business knowledge to even KNOW what might be wrong and where things needed to be fixed.

  I just wanted something that would have an impact on quality, RIGHT NOW, without having to wait for other parts of the company to all get their various acts together so that everything worked as it should. Whatever that meant (again, I'm just another individual contributor... NOT management material).

  But I do believe that humanizing the customer--instantiating the Customer--is a point of great leverage. My video interviews were not about giving the developers more *specific details* about the requirements, for example. These interviews were about fluffier concepts like, "Why these products or services MATTER to these people" and "How issues related to quality really have an impact, good or bad" and even "Where your work really ends up."

  I've worked in both kinds of environments over the years, both in and out of high-tech. Places where virtually everyone had a strong sense of the customers and places where it was all about the specifications and job tasks. I'm not talking just about a customer-is-king or customer-centric mentality. You can certainly have a strong customer-focused company, and yet still keep developers and other employees from ever seeing or hearing from real people. No, I'm talking about customer-is-a-real-human.

  And again, all it takes is a few minutes with a recording device. Not a reorg, not a change in job responsibilities, no Six Sigma black belt stepping in to help.

  Personally, and with no basis in business reality, I think that the less job compartmentalization there is, the better. That virtually *everyone* should have at least a little cross-exposure or, better yet, cross-training. Not a day went by there where I didn't hear an engineer or a sales person or a manager say something that made it painfully clear how little of the Big Picture they had, or how little they knew of what the other person's job was really about. How just a day in another employee's shoes might give them a new perspective. (Including a day in the customer's shoes.)

  Well, perhaps actually *spending* that day doing the other person's job (or trying to) is not practical (although there are other companies that do this... sheesh, I know it's common in the hospitality business to have, say, a five-star hotel manager do a stint in housekeeping and working the restaurant), but a no-budget ten-minute documentary can do a *lot*.

  Two years after that presentation, if I'm at that facility (where I sometimes contract on projects), people still stop me in the halls, occasionally, to tell me how that video inspired them. They still might not ever meet a customer in person, but they'll never again be able to completely put those real faces and voices out of their heads and--OK here's my foofy Californianess coming out--possibly their hearts. They'll never again have the luxury (or liability) of thinking of the customer as an abstract concept.

  So, I'm sure that you're right... and that if these things are necessary then something is *seriously* wrong with the company. But isn't it at least remotely possible that regardless of how things are working, it still might be a Good Thing to do? If it really costs almost no money and takes very little time, would it hurt to have the see and hear a few customers talk a little about *their* world?
  

  Posted by: kathysierra on December 23, 2003 at 11:47 AM

• Agree completely
  As a software developer I absolutely crave feedback (both good and bad) from people using my code. As an individual the ideas I can come up with are limited. I have been truly astounded by the number of good ideas sent my way by the collective consciousness of a good customer base.

  Two of the worst environments I have worked in were when I was completely shielded from customer feedback. IMHO _management_ "too easily justifies an awful lot of crappy quality" - Kathy. I care _passionately_ about the people using my code and their feedback; it drives me to be better (and gives me a way to take a productive break instead of posting to java.net :_).

  I encourage people to provide more feedback. It adjusts my priorities and provides some great ideas that definately get implemented. You can make a difference. It astounds me that I can help roll out a wireless email service for a national carrier and receive only a few feedback emails. I have witnessed the exact same thing time and again. I feel customers don't provide feedback because they don't believe anyone reading their feedback cares.

  Forgive me if it seems like I'm changing the topic but I don't believe I am. I'd love to hear how other companies are successfully handling the customer-developer feedback loop.
  

  Posted by: markswanson on December 23, 2003 at 06:12 PM

• What a sad place Jbob works at.
  "A developer's job is to write code. Period"

  So, developers are nothing more than mindless drones at your company?

  I bet that environment builds a lot of morale.

  Do you retain any skilled and innovative engineers with that attitude?

  Posted by: dukefetish on December 23, 2003 at 10:38 PM

• Classical stupidity or genius?

  Add to Your Bottom Line: Teach Techies to Sell by Kendra Lee seems fitting given how this thread has been going so far. :-)

  Posted by: johnm on December 24, 2003 at 07:23 AM

• This is an old, old debate
  Kathy has hit a hot spot. It�s interesting, and not surprising, that the first two responses deeply agreed and deeply disagreed with her point.

  Many years ago it was discovered that 85% of developers (and an even higher percentage of their managers) are small-granularity people who �don�t want to be bothered� with the big picture. They find it a distraction. Their attitude is: Just tell me exactly what you want done and leave me to get on with it.

  These people can produce excellent quality technical work and be highly productive. I don�t see the justification in forcing them into customer interactions in a way which they clearly dislike.

  On the other hand, there is the distinct minority of developers who find �coding in a box� frustrating and limiting. It�s like walking down a set of stairs in the dark. The narrow-minded arrogance of people like Jbob brings us to frothing fury. He may not be able to see how we can use our higher-level understanding of the customer and technical situation to produce better quality, more effective goods in less time, but we surely do. Moreover, he attempts to remove from us the part of the job that is most rewarding.

  What�s the solution?

  The IT industry has a chronic problem with this dichotomy. Even more than manufacturing, corporate employees tend to gather in layers. Above entry-level personnel are the creative technical people, above them the routine-loving supervisors and managers, and above them we�re back to more creative executives. (*Obviously*, I generalize.) It�s that thick felt layer in the middle that sucks all the oxygen out of the organization. Somehow we need to enable them to perform their necessary administrative tasks, without allowing them to �supervise� creative people into impotence.
  

  Posted by: twallah on December 24, 2003 at 08:07 AM

• Domain knowledge
  Studies have shown that the most effective developers are those with the greatest domain knowledge. When you understand your business inside and out, you can make all of the small "spur of the moment" decisions that will improve the product for your customer.

  Yes, the PRD/SRS/MRD/whatever should spell out the needs. But it never has everything, you simply can't know everything up front. Call it the Heisenberg uncertainty principle for software development: you can't simultaneously know exactly what the market wants and get a product out in time to meet that market.

  That means during development you'll need to get answers, often on little things like should this be in a drop down menu or a link on a page? Do customers usually want to see THIS or THAT on their summary screen. etc, etc. What are the functions they use 80% of the tim? And do they use those functions because it's truly useful or because we don't have functionality FOOBAR and they're making do with the ZIPPY feature?

  All of those micro-questions impact usuability, robustness, design, but often customers aren't really sure what they'd like. They can tell you what they do now, but understanding why they do that often takes hands on experience. Even an excellent requirements elicitor might not be able to convey how annoying it is to go through 3 screens to get to the function you use most.

  So, should you have developers talk to customers? It's a darn good idea, especially your "core" developers you expect to be with the company for a long time. Domain knowledge simply makes you better at what you do.

  It also makes you better at making those intuitive "leaps" of "Hey! What if we integrated with XYZ? Or allowed them to do FooBar?" If you only experience your customers through an MRD/PRD then you haven't really seen their frustration/joy.

  Don't get me wrong, I really LIKE a good MRD and a great marketing group. There's nothing worse than 10 developers arguing about what feature A should do. But that's independent of the value domain understanding gives.

  A good MRD doesn't replace the need for domain knowledge, it complements it.

  Posted by: ckessel on December 24, 2003 at 08:28 AM

• s/w is an art ... box me in at your own peril
  the best art i know of involves vision, creativity and interpretation. i know of few who "know all" and in fact actively run from those that are self professed "know it alls" leaning more towards organic, XP like environments where communication and collaboration is the theme. i also feel the prototypical "how to manage a s/w project: 1 2 3" are doing a huge disservice as what may look good on a white board often doesn't have legs in the wild.

  sure, i can write code and yeah i like to write code, very much so, but if one simply fixates on making the compiler happy then the true joy of systems engineering is largly missed.

  it is all about collaboration regardlesss as to what the label on one's hat, or, better yet, hats happens to state.

  Posted by: gonzo on December 24, 2003 at 11:47 AM

• What a sad place Jbob works at.
  What a developer does and what their "job" is are two different things.

  If you were choosing between two developers and one had much stronger coding skills and the other had much stronger people skills (for interacting with customers). Which would you pick?

  A solid developer who has strong people skills, a desire to spend the substancial amount of time with customers required to get to know the customers, and can take criticism (aka feedback) is a very rare and valuable breed.

  My company is fortunate to have a lot of these types, so that should answer your questions about attracting and retaining talent. However, this combinations of skills is a bonus and not something to make as part of the job description.

  Posted by: jbob on December 30, 2003 at 08:08 AM

• This is an old, old debate
  Sorry Twallah, you didn't pass the test.

  So, in a nutshell (that would be the gap between my narrow mind and my big head!), I provided "feedback" that you did not agree with and your response was:

  
  Frothing Fury
  Calling my feedback "arrogant"
  Calling my feedback "narrow minded"

  
  Much of the feedback we all receive from customers is going to be criticism. That is just the nature of mankind. You don't call your cable company everyday to tell them what a good job they are doing when your cable works? You do call them when it does not work the way you expect or would like? This is because people do not have the interest or time to build a relationship with their cable company. You pay them and it should just work. Many customers feel the same way about their vendors and it is a very valid mentality.

  Additionally, A lot of the criticism you may not agree with. That is why it is important to have an unbiased audience for this criticism.

  Based on your response to my feedback, I would question the wisdom in having someone like you interacting directly with a valuable customer who may be less than complimentary in their feedback. Clearly there is a high risk that you would take it personally.

  Posted by: jbob on December 30, 2003 at 08:30 AM

• Agree completely
  Setting up roundtable meetings between developers and customers can be a great way to reward your more loyal/valuable customers by giving them access to your developers.

  You have to pick the right customers so that you wind up with feedback from parties that are truely interested in getting more from your software and not just looking to nitpick.

  The most eye opening part of this is seeing how well the "how it is used" lines up with the "how it is supposed to be used". Many times customers don't think or work like we do and don't reap the full benefit of how our software is supposed to work. Additionally, you will learn about some innovative ways that your customer may be using part of your application that you never intended.

  With things like web conferencing, it's even easier to bring disparate groups together without a lot of expense or planning.

  Posted by: jbob on December 30, 2003 at 08:54 AM

• Sounds like developers have forgotten their place.
  "All too frequently, developers pretend that they know better about what the user/customer wants. It's at those times that you need to remind them that it is not their job to know or to even figure out. Their job is to write good code."

  And all too frequently, developers *are forced* to guess on what the user/customer wants, because the requirements are incomplete and/or ambigious and communication channels are just too slow to get more information in reasonable amount of time.

  The developers somehow *need to know* what the customer wants, and giving them direct access to the customer can help a lot.

  And as a side effect the contact with a person who directly cares about what the output of the development looks like can improve motivation, too.

  Posted by: ipreuss on January 06, 2004 at 08:42 AM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowleveling3 on December 13, 2007 at 07:18 PM

• 网络营销软件
  网络营销软件
  网络营销软件
  群发软件
  群发软件
  ---
  群发软件
  网络营销软件
  论坛群发软件
  网站排名软件
  群发软件
  推广小助手破解版
  论坛群发软件
  网站排名软件
  群发软件
  推荐给你很好的群发软件和信息群发软件和供求群发软件
  推荐给你很好的群发软件和信息群发软件和供求群发软件博客群发软件网络营销软件网络营销软件
  网站排名软件网站排名软件网站优化软件信息群发软件信息群发软件信息群发软件论坛群发软件网站推广软件网站推广软件博客群发软件博客群发软件

  群发软件群发软件博客群发软件论坛群发软件网络营销软件论坛群发软件
  信息群发软件推广软件网站推广软件网络营销软件网站推广软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件
  网站排名软件
  博客群发软件
  网站排名软件
  网站推广软件
  群发软件信息群发软件
  免费论坛群发软件
  论坛群发软件
  网站排名软件
  免费博客群发软件
  网站推广软件

  群发软件
  博客群发软件
  网站排名软件
  网站推广软件
  群发软件信息群发软件
  免费论坛群发软件
  论坛群发软件
  网站排名软件
  免费博客群发软件
  博客群发软件
  信息群发软件
  论坛群发软件
  信息群发软件
  博客群发软件
  qq群发软件
  邮件群发软件
  博客群建软件
  企业名录搜索软件
  信息群发软件
  邮件群发软件
  论坛群发软件
  博客群发软件
  网站推广软件
  网络营销软件
  全能营销破解版
  网络营销软件
  论坛群发软件
  论坛群发软件
  论坛群发软件
  网络营销软件
  信息群发软件
  信息群发软件
  信息群发软件
  群发软件
  论坛群发软件
  群发软件
  网络营销软件
  网站推广软件

  Posted by: u89io98 on December 25, 2007 at 11:53 PM

This work is licensed under a Creative Commons License.