What Matters Is What They Want

, 2010-01-05

In September 1986 my family returned to Beaufort, SC, from a three year tour stationed at MCAS Iwakuni, Japan. My father was a Gunnery Sergeant in the US Marine Corps and we were returning to MCAS Beaufort. The first month or so we stayed with my uncle and aunt and during that time, I took to a manual typewriter that no one was using. I began to write stories and the like with it and I spent quite a bit of time hacking away on that typewriter. It was one of those two color typewriters, where the ribbon had both black and red ink, and this little lever which toggled what color would be used. When one of my uncle's rental houses opened up, we moved into it (our house, from when we were previously stationed in Beaufort, was still being rented), but I left the typewriter behind as it wasn't mine.

Fast forward to Christmas 1986. We head over to my uncle's house and there's a rather large present under the Christmas tree for me. When it's my turn, I tear open the wrapping paper and find that manual typewriter that I had happily used back in September. I was delighted with my gift. My father, however, was fuming. He was angry at his brother and sister-in-law for giving me a "used" present. They certainly had the money to buy something new and shiny. But one of the things I love about my aunt is she has always paid attention to what it was that I wanted. And she knew that the best present she could have given me was that particular typewriter. I'm the type of person who attaches memories to objects. And that one typewriter, for me, was better than any shiny new model she could have bought. I know that probably makes me strange, but she gave me exactly what I wanted.

What Do Our Customers Want?

This is an important question, and one I've struggled with. I have found myself falling into the same trap as what my father did that one Christmas. I hear what a development group or a set of end users want and I find myself thinking, "They say they want A, but what they really want is a shiny, fancy B." That's actually an arrogant thought on my part, because I am assuming I know better than my customer. How do I know what they really want? The truth of the matter is I don't.

Now there are two possibilities here. Either they know about that shiny B thing or they don't. If they say they want A and there's time, I should present B as an option. If they don't know about B, they may not realize it fits their needs better. And by taking the time to show B, I give them an opportunity to see that. In that case, everyone is happy, we choose B, and we move on. Now there are also possibilities like they see B, like B, but we don't have time to go with B, so we'll do A, and then plan a future change to implement B. Again, eventually everyone will be happy, and I've helped improve things for my customer.

But there's also this possibility that they've seen B, understand what B gives them, and have decided that B isn't what they need. So if I present B and they say, "Yes, we've looked at it, but it isn't what we want," I need to honor and respect that. Now I should ask a couple of questions to make sure that they're talking about the same thing I am, and if they are, then they've decided what they want and we go from there. Pushing what I want isn't respecting and honoring the customer. It could be seen as a slap in the face where I'm basically saying, "You're not competent to know what you want." Think about it for a second and you'll see how a customer could reach that conclusion. That's not where we want to be with our customers.

When We Push Too Hard..

So what if we're so busy pushing B that we fail to notice they really want A until after some feelings have been hurt? We own up to our mistake. No excuses. We apologize and admit we were wrong. This type of apology doesn't go along the lines of, "Well, you know, B has this feature and that feature and I thought you would really like it because of..." but rather, "I didn't do a proper job of listening to you. I will try and do better in the future." The first tries to insert an excuse. The second admits fault and recognizes that we need to do better. If you have any doubts as to which is better, imagine you were the customer.

I wish I could tell you that's what my dad ended up doing, but I honestly don't remember. See, for the rest of Christmas break, my and that typewriter were nearly inseparable. It won out over computer games and new G.I. Joe toys. I probably owe my typing skills today to that old manual typewriter. And at some point my father asked me, "You really like that typewriter, don't you?" My response was something along the lines of, "Yes, dad, I do. Can't really talk now. Typing up a story." And that's why I can't remember if my dad called up my aunt and apologized or not. I was too busy typing away on my typewriter.

Are There Exceptions?

Sure, there are always exceptions. For instance, what the customer wants may have a regulatory or legal problem. For instance, if what a customer wants violates a SOX compliance control that their organization has in place, what then? Then it's time to explain the issue. If that doesn't work, bring in the folks who are responsible for tracking and ensuring compliance is met. Let them explain why A won't work for them. At that point, you've put the right people together. In situations like these, that's all you can do. You get the folks who have some ownership of the issue together and you get them talking. That is to everyone's benefit.

And then there are the cases where the customer simply refuses to listen. They don't know about B, they don't want to hear about B, and they aren't going to hear about B. So what do you do? You give them A. But before you do, document that you tried to present B. You can't win by giving them anything other than A. The documentation is for later, in case they realize they need B, and they look to you to blame. It may not stop every bad situation, but it hopefully gives you an "out" to most unfavorable situations.







Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.


1,567 reads

Networking - Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I'd like to talk about social networking. We'll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let...


1,530 reads

Speaking at Community Events - More Thoughts

Last week I posted Speaking at Community Events - Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I've got a few more thoughts on the topic this week, and I look forward to your comments.


360 reads