Sharing the thrills with the customer: the good
Programmers want customers to use their software. Some of them want to be given feedback in order to improve the software. Most programmers, want even, their customers to be thrilled by their software, if they are thrilled by it. They want their client to share this with them. This is a good thing, it makes us developers proud, knowing that the software is being used, that the customer shares our enthusiasm for a solution we thought of, doesn't it? This is good.
Sharing the thrills with the customer: the bad, the ugly
Unfortunately, programmers want more, and like any excess it ends up bad. The programmers want the client to be thrilled by their technical accomplishments, by the 'smooth' things in the solution, techincally speaking, by how ingenious the solution was developed. They want the customer to be excited that the programm works 28 times faster then another solution. This is bad and ugly. It is naive. We programmers like logical things, but this is against logic. At least at the beginning.
The customer will only be thrilled by a software if it will improve his life, if he can achieve his business goals faster. It doesn't matter if the product was ingeniously build but whether the product is an ingeniuos tool for him. He doesn't care whether it is faster 28 times faster then another technology, unless the second was slow by his standards, he doesn't care if you used n-tier , unit testing or automated builds, 'healthy' approaches or not. He only cares if he can be more efficient with his new tool, your software.
So where is the problem in sharing the thrills with the customer?
Programmers and customers are both thrilled by being good at what they do. This is the common thing. The problem is that they act in completely different areas (mostly), so 'at what they do' means completely different things. Let me give a very simple example: management likes reports about what developers do, so sometimes as a programmer you're not very happy at the end of the day to fill in a report about your activity. Well that data makes them happy, but takes time out of your programming time. They even sometimes, show you the reports very enthusiastic believing that you would share that too, but do you?
Software is a tool. Just having it doesn't make your customer happy
It's not that easy to be thrilled just by the fact that you have a tool. You'll be thrilled only by achieving a goal. If achieving this goal, involves using a tool, you will be thrilled by the action of achieving the goal and not by the fact that a tool helped you achieve it. Just having a tool or using it without meaning doean't make you happy.
Let's say that you're a mobile phone manufacturer. You want to sell your customer mobile phones. If you sell them mobile phones, they won't be thrilled by how good you phones are. They will only see their potential when they'll achieve the goal of speaking from everywhere. They will be thrilled by the fact that they can go everywhere, and still be able to be called and call anyone they like. This is the first thing they will notice, this is their goal, to be mobile and not to own a mobile phone. They won't care if it is GSM or CDMA, if it works on triband or not. Fortunately, as the time goes, they'll start realising that in order to achive their goal of mobility better, they depend on the mobile phone. Some will even notice, that it works on three frequency bands. They will see that they can be more efficient at their primarily goal by improving their tools.
Turning priority lists arround
If you have real good marketing people, you might find out that at a time, this goal changed, they care more about having powerfull mobile phones with color display, calendar, mp3 player and camera more than speaking from everywhere. People become addicted. Another example would be skiing. At first you don't care about what helps you ski but about the action of skiing.
Unfortunately, we as programmers often missunderstand the approach we need to use. We think that proirities are already changed, and we show the client how great the software is compared to another, and not how it will help him. We assume that the customer is already addicted.
Show the client not how to use your software but how your software helps him
Think about car manufacturers (and salesman), 2-3 decades ago, when they suddenly realised that there a huge new market: women. So, the salesmen turned their entire arsenal towards women. They started showing women mustangs and corvettes, impressive V8 engines, incredible horse power, the beautiful roar of the engine, how fast and powerful they are, how fast they go from 0 to 60 miles per hour, how cool the cars were.
Cool vs Chic
Well, this meant nothing to women. They didn't want cool they turned out to want 'chic'. Women had no idea what V8, 5s 0-60, 160mph, roars etc meant. The first thing they wanted was a mirror to be able to powder their noses, check the makeup, a place to put their purse?, colors to match the shoes etc. Of course, I am kidding, but I am trying to emphasize that women had completely different expectations about cars. They didn't want 'cool', they wanted 'chic'. They didn't want to show power and masculinity , but independence.
The reason behind this strory is to explain how important is to know your market. Men knew how to sell cars to men. We programmers try to sell software to clients as if they were programmers, when instead the client has completely other objectives, just like women did with cars.
Sell to managers
I noticed that many presentations of a software solutions miss their target, because instead of showing the customer representatives there, which are mostly management people how the program works for managers, how to extract the info, because this is what managers want, they show them how the application can add and save data to a database.
The managers see the purpose of a program as getting THE information needed now. This gives them what they want: power by controlling the information. If you present a software to managers, show them the manager's dashboard that displays the instant data, the main reports and not how your application puts the data in (unless they ask).
I strongly advise you to look at Google. It is so sucessfull not by being a search tool, but by giving you the info you want. Everyone feel the power of getting information instantly at Google. They sell the solution because they know that the clients don't want to search, they want to find.
Conclusion
I hope to have achived to explain you that us programmers ofter put techincal ingeniousity before customer demands, we ofter tend to tell the customer what he wants instead of letting him tell us what he wants. I believe that because of this reason we do not build sellable products, but we tend to build expressions of our egos in our software, to show the other programmers how good we are and not the customers.
