Should We Avoid Clueless Customers?

Question

I'm our companies only PC software programmer so I often end up in meetings with customers discussing what they want. We have developed custom hardware and software, but some of our customers are very very non-technical.

You show them a 'cool' animated realtime display of data coming from multiple sensors over a network and they get so excited. However, they find it very difficult to understand that the UI is less that 10% of our whole development time/cost.

Another customer wanted to generate historical reports and statistics from 1-2Gb of data per year, but they insisted that they didnt want or need a database.

We end up with two outcomes:

• You finally work out what you think they want, write a spec and they sign it off and still dont understand what they want
• They insist on specifics that really dont matter ('cool' things generally) and dont care about important things like how the data is stored

Either way I feel it will end in tears. Should we be bothered if they are willing to put up big money for it? Can contracts like this be managed and end with a good outcome?

Answer 1

People have asked me this before and the best answer I could give them is that if software development was easy, anyone could do it. The real art of the "business" of software is making the decision on whether or not you can deliver what your customers want for a price that makes it viable for you.

Customers are stupid by the way (I'll caveat that with IT and in the general case, there are certainly pleasant exceptions to this). Your job is to show them how your software will make or save them money. If you can't save them money (ROI) then they won't deal with you.

Answer 2

I'm by no means a veteran of the industry, but I feel that if you can work out a contract that your company feels comfortable with - one that clearly states what will be done as well as how much additions/modifications might cost if needed, etc. - then why not go for it? Especially if they're paying well.

The trick is to not go in blindly. Have a contract that you know will protect you in the worst of circumstances, and then you don't have anything to worry about (except perhaps some communication-related headaches if things start going badly).

Answer 3

If you avoid clueless customers you will probably starve.

Instead you need to manage them properly. Generally customers do not understand the technical side of the business and they shouldn't have to. I would not depend on a customer knowing if they need a database or not. Rather focus on the fact that they need to store data. Word the contract so that it leaves you room to do what is necessary to get the job done and you implement the code your way as long as it satisfies the needs of the customer.

Answer 4

Customers should set goals, with restrictions, but they must not set mediums as long as they objectives are satisfied.

Answer 5

There are sometimes you need to walk away from a job. The question you need to ask is: "are you able to help the client?" If you feel that you won't be able to help them understand or convince them there is an easier path than the one they take, then you should try and refer them to someone else. Chasing the dollar, so to speak, generally ends up in you being frustrated and the client being angry. It's never good to have someone speak ill of your company even if you can get fees from them.

Answer 6

Requirements analysis is a skill, not a science or even an art. And it is a very difficult skill at that, however, someone who can do it well is extremely valuable to any development company.

Answer 7

Now you know why people say that your job is to tell your customer what he wants. If you have long time customers, like my company has, it is actually your job to educate them. Some time in the future, they will understand what you tell them. That's a good thing.

This reminds on The iceberg secret, revealed from Joel Spolsky. It's about exactly your problem in detail and likely a must-read for you ;)

Answer 8

Should we be bothered if they are willing to put up big money for it?

Yes.

Can contracts like this be managed and end with a good outcome?

Yes.

It's actually pretty common for non-technical people to judge systems by the interface, and not to understand technical requirements. Managing their expectations is a part of dealing with the client, and a basic part of project management. This tends to be adversarial if you're looking down your nose at them, and the temptation is strong, but it doesn't have to be adversarial. Technical thinking does not come naturally to many people. They're paying you, after all, to handle this for them.

Answer 9

It can be easy to assume customers are less capable humans, but this is a self-defeating path. Their skills are in different areas than yours, and they are good at some things you are not. Remember that they have money to pay your salary, and it's actually easy to make these people happy.

I would suggest a few approaches:

1) Iterative Prototyping.

Take baby steps to get to the full system they want, and allow them to have input at many levels. Implement pieces of the application without spending too much time on things they may not be happy with.

2) Snapshots of proposed implementations.

It's tempting to quickly mock up a menu in code, and show them a running shell of an application. They will get the impression that it works, and will have no idea of why it would take another 6 months before they can use it. If you do mock up an application, then take screen shots and present them with jpegs and a verbal description emphasising the fact that different pieces would take months to implement.

3) Suggest alternate routes that will be less effort.

Sometimes they want a specific feature that is very difficult and will take a great deal of implementation. Suggest alternatives that are baby-steps, or possibly another solution that will fit the need behind their request. It can be difficult to see their intentions behind their requests, but ultimately you will end up with a happier customer.

Answer 10

One thing I've found from customer reviews is that the GUI gets %95 of the comments (and contraversy). I think your typical non-software person doesn't really understand or feel qualified to talk about databases or data structures. However, everybody uses GUIs, so everyone thinks they are an expert in those.

The main thing I try to do is take customer input for requirements (what the GUI needs to provide), but take input on design (how it provides it) as suggestions. You shouldn't just out and out blow them off. But you shouldn't take all your design direction from them either. If you do that, you will invaribly end up with the one gigantic uber-screen, as they always want all new functionality to be crammed onto their favorite screen or dialog.

Answer 11

There are two different varieties of clueless customers; one is to be avoided if possible, the other is a great opportunity for partnership.

A clueless customer who does not understand how their own business works is very likely to be a painful customer with whom to deal. Avoid like the plague they are! The odds favor their relevance in your long range plans being limited, if present at all - because they are the likely victims of statistical predicted failure.

A customer who knows how to execute well in their business, but wants a technology solution you can provide is an opportunity to form a business relationship which can give you the most perfect marketing in the future. Cultivating a relationship where you can give the customer that clue they were missing is invaluable to your ongoing business, especially since it increases the odds that the customer will be around for a new project, or referrals, in the future.

Answer 12

• Your role as software developer is to find out what your customer really needs. What user needs is most of the time different from what they want.
• Because you understand the technology you have to find the solution.
• You will be successful if you find a way to communicate with your customer and bridge the differences.
• Ideally the solution should do everything what the customer expected but include stuff that they really need but have no idea about.
• Probably prepare multiple solutions and explain the differences (in simple terms, leave the technical stuff) and point out the effect on performance, scalability, usability, maintainability and so on.

Remember, customer is always right ...

Answer 13

If you have enough customers to survive on "smart customers" only, do avoid them. It makes for a happier work life.

You can refer the "clueless customers" to me. The only customers we avoid are the ones that we suspect wont pay.

Answer 14

If the customers were as technically savvy as you in your field, they probably wouldn't need you. Clueless customers are often your biggest source of income. So yes, you should bother if you want to pay the rent.

There does come a time when you meet customers that are clueless but still think they're smarter than you in your own field, and those take some extra patience and understanding, and sometimes you still may need to decline their business, or just price yourself out of the bidding. If they're willing to pay significantly more than what the job is otherwise worth then it may still be worth coddling them.

Answer 15

Never bite the hand that feeds you! They do pay your salary, clue or not.

Answer 16

Not at all. In my humble opinion, we are problem solvers and dealing with clients is part of the business. They offer guidelines and goals, and it's our task to come up with something that respects the guidelines and meets the goals. If some guideline blocks the way to meet a goal, give priority to the goal and explain the client that your implementation is the good way to go.

Bottom line is they come to us with a problem that needs to be solved. Making them happy is priority one, but It's also our responsibility to offer a viable solution we know is the best approach and meets the real goals (e.g. store data) and satisfies the personal requirements (e.g. 'cool' interface).