• Anonymous
• Jun 25,2008
• In: Anonymous, Management

The Customer Is Always Right

…but your sales team isn’t.

Successful businesses produce and deliver products that customers need at a price they are willing to pay for. Most of the time if a customer doesn’t like the product presented to them then they will not purchase it and the company has to redesign the product in order to make the sale. But, it seems some software companies think this kind of business process doesn’t apply to them.

I’ll use an example to illustrate a problem that occurs much too often. Let’s compare the process of building and buying a house with the process of building and buying software. When you want to build a house you find a contractor to take your requirements and build you a home. You spend a lot of time with them to make sure this contractor understands your needs and is capable of building the home you need at the price you feel is right. Some negotiations take place depending on due dates and the complexity of the project. The contractor says he will deliver what is required of him if the customer pays a certain price. The contractor knows that he could lose the deal if he doesn’t deliver what the customer wants. Once in a while the customer will visit the construction site to see that things are going as planned. If there are mistakes in the home then the customer will point them out and the contract can make adjustments. Then, one day the house is complete and the client is given the keys to their home and the customer pays for it.

The software development process is very similar but there are some serious problems. So now we have a customer who is looking for a software solution. This time the contractor is a software development shop that is offering to build the software by a certain date at a certain price. The sales team of the software company sits down with the client in many meetings negotiating features, prices and due dates. Finally a contract is made to deliver a product that the customer wants. But here’s the problem. The people making the contract, offering the features, setting the prices and setting the due dates actually know nothing about software development. They don’t know how long certain features are going to take to actually develop or if they are even possible. Does the sales team really care about that? No. They are going to tell the customer what they want to hear to get the contract and then figure out the details later.

What ends up happening is development teams who actually have to make the product are bombarded with vague and difficult requirements one after another. That is because the requirements are never prepared and thought out ahead of time so that they can be given to the developers all at once. This happens until finally the development team has to step up and and start questioning the requirements in order to meet deadlines. Of course, in order to reject features and requirements it is the responsbility of the developer to fully understand now the cutomer’s needs and the full scope of the product because the sales and management teams want to be approached with solutions to problems and not just a we can’t do that in time response. Of course when this happens a lot of time is wasted trying to setup meetings and waiting for responses from the customer as the sales team tries to renegotiate the contract.

As the deadline approaches the customer usually gets to see a sample of what is going to be delivered just like with the house example. So what happens when the customer says it doesn’t do what they said it needed it to do? Well, you try to renegotiate the contract again to make sure the sale still goes through. What happens when the customer demands a certain feature be in the release that the sales and management teams neglected to mention to the developers until the day the customer realized it wasn’t it the product? Well, now it becomes the responsibility of the developers to produce miracles.

Let’s look at what went wrong here. At one point the company and client did have a clear understanding of what was supposed to be delivered. The problem was introduced after the contract was created. It seems that after the inital negotiation the sales and management teams look over what was promised to the customer and now decide what they can actually deliver with the idea already in their minds that they will renegotiate later. Then, like I mentioned before it becomes the responsibility of the developers to produce miracles when these negotiations fail.

Imagine if that whole process was applied to the home building example. Would you still buy the home if the contractor told you that they couldn’t build the second story for one reason or another but if you wanted you can have it added on later next year?

There isn’t an easy solution to this problem. Most of it is poor communication mixed with unrealistic expectations. When your sales team cannot make a sale without making undeliverable promises then something is seriously broken. You can’t blame the customer for wanting a great product that works. You also can’t blame the developers for not creating the impossible or working fast enough. Its the reponsibility of management and sales teams to bring customers and developers together.

No business is perfect but I believe that to be successful you need to deliver what the customer wants eventually. Some customers might be ok at first with getting a different product now with a promise to get what they want later. But you sooner or later when a customer has to keep going through the same process for every product they want they are going to end up with software that doesn’t meet their needs over and over again and they will eventually look elsewhere.