Four Biggest Fears of Customers

by: stacey - January 27th, 2012   Filed under: Customer Relations Add Comment

I find myself focusing more and more on customers lately.  A project’s success is so much more than successful execution of a project plan.  It is about the customer’s satisfaction with the end results of your project.  If you execute your project plan successfully, on time and on budget, but the client hates the end result, no one uses the software you implemented, and ultimately the customer considers the money they spent on the project a failure, did you really succeed?

In most cases, you did not.  This is especially true if the customer is a customer of your company, and your implementation was of your company’s product.  One of the ways to help ensure success of your project is to address your customer’s fears.

What are the customer’s biggest fears?  Here’s a brief list of the top four I’ve dealt with:

1.  Can you deliver what we really want, on time and within budget?

You have to be able to explain, confidently and in simple terms, how you will achieve the goals of the project, on time and within budget.  You have to show that you are open to changes as well (within the scoped process for change requests, of course) to change.  You are to deliver what they really want, not what they asked for.  The client does not always in the beginning understand what he is looking for.  You may have to change paddles mid-stream.

2.  Will the deliverable actually work and fulfill my needs?

At some point early on you need to be able to explain the change to their business process that your product will bring to them and how that change will make things better for them.  Show them the value.

3.  Will I see value from this project?

Projects are long and often difficult.  You have to be able to articulate over and over how the deliverable is going to bring value.  More than that, you need to be able to explain exactly what that value is.  The customer and the team has to be able to remember why they’re doing what they’re doing.

4.  How hard will this be to maintain?

After you finish your project, the deliverables involved have to be maintained.  As the client gains confidence in you and your ability to deliver, their own confidence to do the same may wane.  The more that you appear to be an expert, the less they may feel like an expert.  You need to provide them with a quality, easy to understand maintenance plan that makes them feel confident in their ability to maintain the product in the event that you are no longer available to them.  If you are to maintain the product later, be transparent on exactly how much time, effort, number of maintenance activities, and cost of maintenance involved.  Let them know that the maintenance of the deliverables will not be too expensive for the project to be worthwhile.

Tags:

Knowing When to Respect Your Customer

by: stacey - January 13th, 2012   Filed under: Customer Relations, Product Management Add Comment

Facebook is a classic example of two things:  how word of mouth marketing can drive huge amounts of adoption to your product, and how failure to respect the basic values of your customers can ruin your product.

There is no question that word of mouth has done great things for Facebook’s adoption and in turn its value.  People have loved the application for allowing them to do a very simple thing:  talk about themselves, keep in touch with friends, and make new friends.  I daresay that items 1) and 3) there are the key driver of any social app; people want to talk about themselves, and people want to think that what they say about themselves is so interesting that people can’t wait to be friends with them.  It feeds all of our inner egos and/or self-esteem.  Their original target market is teenagers, who are, as we all know (particularly parents out there), all about trying to identify who they are and wanting acceptance from peers.

That same word of mouth recently bit Facebook.  Their Beacon program’s online tracking showed a gross misunderstanding of their customers by violating several important tenets:

1) Users in today’s internet are nervous about privacy

2) As any parent knows, teenagers (one of Facebook’s major markets) are really paranoid about their privacy

3) The way that Beacon worked, sooner or later it was going to show up as spyware in any number of security apps- and people were going to block the service anyway, and then they were going to fear Facebook as a result (my security software told me it was bad!)

Facebook broke an even bigger rule with this program, however:  at some point, they stopped thinking about their customers as people, and started thinking of them as sources of information.  Many companies have done this.  You know of a way to get information from your data sources, and you decide on a new feature or revenue source that you can generate from that information.  Too often in this situation, companies think of revenue rather than the customers.  Facebook did this when they decided to make people’s purchases public for the world to see without the ability for the customer to approve or edit the feed.

I am all about revenues and making money from customers.  That’s what free enterprise is all about.  Still, you must always remember what your customer’s core values are.  Evaluate them.  Write them down.  Put them on your wall.  Violate their core values, and not only will they abandon you, they will rebel.  Word of Mouth is the number one advertising method out there.  Don’t turn it against you.

Tags: ,

If You Want Happy Customers, Give Them Less Information

by: stacey - December 16th, 2011   Filed under: Communication, Customer Relations, Project Management Add Comment

Guy Kawasaki wrote a great post a while back about customer happiness.  I’ve seen this at work before.  My parents, for example, have been thinking about buying a big screen television for years.  The problem is, nowadays, there’s HDTV, LCDs, DLP, plasma, projection, etc.  The choices are too many, the television makers are not clear on what it all means, the salesmen keep sharing more and more technical details, and so in frustration and confusion they simply do not buy.  If someone simply made the decision about what the television looked like, what size they want, and ‘hey, look how nice this picture is’, they would’ve made the decision by now- but the sales folk don’t do things that way, and so they lose out on the sale.

So it goes in IT and project management as well.  Too many times, we want the business to understand that we’re thinking ahead for them, that we’re using the right technologies, making good decisions, and sometimes the business simply does not care.  It’s not that they don’t want us to make good decisions, its that that’s our job, and they don’t need to hear about it.  They need to know when we’ll make their jobs easier.  The key is understanding when you should simplify things for the client, and when you should not.  Here’s a few example cases.

When the Sponsor/client cares about the end result:

Sometimes, people just want their problem solved.  They don’t care that you’re using web services to solve their problem.  They don’t care about the database.  They don’t care about anything except solving the specific business problem that they’ve identified.  What you should report to them is when you’ll be done, when the documentation and training will be available, and when you think they’ll be able to put the solution to use.  If this is what your client wants, then anything else other than updates to these three pieces of information likely just irritates them.  The result is everything to them.  If you talk about all the details you are wasting their time, and to them you are focusing on the process rather than getting them their result.  Stick to the basics.

When you are late on a project:

See the item before.  No matter how much the client may care about the process and the details when you’re on track, once you’re late, then they can get impatient.  Stick to the details of what you’re doing to get things back on track.  Don’t worry about the rest until you’ve solved that problem.

When your problems are not the client’s problems

The client’s problems consist of the fact that they don’t have their solution yet, what to do until it arrives, all the communication and change management around the solution implementation, training their staff, listening to their staff complain about things changing, learning how to use the new solution, providing training, and dozens of other things not related to your project/product.  The difficulties related to RPMs not compiling correctly on the linux installation are of no interest to them- that’s your problem, and that’s why you’re in charge of the project, not them.  In fact, there’s some chance that they don’t even care if you’re using linux, windows, unix, or bands of mongoose that quickly rewrite their screen every time they click on something new.  They just want their solution, and if you can tell them how you’ll make their other problems easier, that’s an added bonus.

Other times, you should share as much information as possible with the client.  Some examples are:

The solution will be delivered in phases

The client isn’t getting everything they want up front.  This complicates their lives.  Share as much as possible about what they can expect and when.

The client will be maintaining the solution after implementation

If the client has to maintain whatever it is you’re delivering, then you can’t give them enough information.  They will want and should have as much say as possible in as many decisions as possible.

All in all, understanding the right amount of information to share with the customer goes a long way towards their happiness.  Share too much, and you’re wasting their time and your own.  Keep your project reports tuned to the audience’s needs.

Tags: , ,