I love customers! It would be churlish not to: they pay my mortgage, they pay for my groceries. More important, they give my life meaning and save me from the despair over wasted effort, the woe for lost, irreplaceable hours of life that comes when a product I’ve worked long and hard to develop is abandoned or becomes shelf-ware.
So I love customers!
But I don’t trust them.
- You will say, “it requires Java 7”. They will try to use Java 1.4.
- You will say, “it requires Microsoft Server 2012”. They will try to install it on XP.
- You will say, “it runs on CentOS.” They will install it on Debian.
In every case, your support team will hear anguished tales of your product ruining lives, and your sales reps will glare at you in the kitchen. The lesson: minimize the customer’s role in deploying your system.
One approach, if it fits in your pricing model, is to require purchase of professional services to perform an install. You send your people on site, and they establish a working system. (A major down-side to this is that it introduces a barrier to trying your product, a barrier to sales. Another problem is difficulties in scaling to high volume sales.)
In any event, your product must be as self-contained as possible. For example, if you are deploying a Java product, you must include your own Java Runtime.
If possible, sell your product as a hardware appliance. Ship blades or boxes that you have provisioned at your own facilities, with staff well-versed in how to do this.
The ultimate step in customer-proofing your deployment would be to offer hosted services. But this requires a huge amount of dev-ops expertise, even if you delegating system and facilities management to cloud services such as AWS or Rackspace. You will know whether or not you have the necessary expertise. If you aren’t sure, then you don’t.
And if none of this is possible, your product’s install procedure should be as simple as possible. If it requires your customer to edit a file or follow a page of instructions, it needs work.
The philosophy of limiting customer involvement has a role in how your implement your customer support. If your customers will allow remote monitoring of their systems, then by all means implement mechanisms to report system status and configuration directly to you. Having system crashes and dumps automatically sent to your support team is also an advantage. (Of course, many customers would not permit any such access to their internal systems,)
In most cases your customer wants your product to pay for itself many times over with no effort on his part (See my blog post, I don’t want to learn your product.) The more you can accommodate this wish, the happier you both will be.