tyler

The Customer's Dilemma

Tue Jan 15th 14:44:18 2008

For many years I've been placing the blame for bad use cases /stories and feature explanations square on my own shoulders. I haven't educated my customer well enough. I haven't provided enough feedback to educate the user on what is possible. I haven't given the customer quick enough feedback in the form of tangible interfaces for review to pull additional ideas from them.

A conversation I had with Loren today triggered some thoughts that I wanted to jot down before I lost them to the ether.

The fact of the matter is, some customers don't know what they want. They have a fluid set of ideas, but cannot dictate them to you in conversations any number of days apart. They'll in fact tell you completely different things and call them the same ideas they had previously.

Any effort to educate the user ends up being a waste of time. They are not interested in your information technology hocus pocus. Asking them if they are looking for a desktop application or a web-based app is futile. They don't know. They'll never know.

The opposite end of the spectrum can be just as annoying. Take the customer that comes to you and says, "I need a FileMaker based application." Or perhaps, "We've spent money on 3 different web guys and we've decided we want an application to talk to our MS SQL Server database."

Toss caution to the wind trying to explain what client access license implications mean to these folks. You have to talk in universal terms. You have to come up to their level of thinking and forget implementation for a minute.

What is this customer really after? They've come up with an idea (or multiple ideas) that they are fairly sure will positive affect their bottom line. It's about the money. A customer service bonus program... is about the money. An invoice suite and inventory control manager... is about the money.

So translate that to the customer every chance you get. By adding this feature you save X. By providing your customers a way to accomplish foo you make Y. Show them how you can affect their bottom line.

Now step sideways with me if you will into my cube at Move Networks for a moment.

I don't work directly with customers, and unfortunately I don't get to set expectations nor try to educate them about the benefits of our solutions. I do however get to look at the features I'm in charge of rolling out and be as pragmatic about those tasks as I can be. I tend to offer myself questions to kick start development. How is what I'm doing contributing to the success of the company. Is this the most important task I can be doing right now. Am I doing what the project manager expects me to be doing. Are they fully aware of the risks I am aware of. Are any of my co-workers dependent on tasks that I have taken charge of. A quick self-assessment of my projects helps to straighten out my priority list. I plan on publishing this list internally and making sure the project managers know where to find it.

The key in staying agile and sticking to agile methodologies is staying flexible. Requirements and priorities change. Since I accepted this fact I'm much more at peace with the fact that I can only accomplish the most important things (especially at a startup), but can sleep at night knowing it was the best use of my time.

Recognizing break downs in communication and building bridges to overcome them will reap many benefits. If you can't find a happy medium then head straight in for the kill and show them how you affect the bottom line. Return on investment speaks volumes.