Collaborating with enterprise customers — tips 5-9

We’re going to talk about a few more ideas on how to manage these big customers, get a good product that they actually like, without going off track. Number 5, Over-Invest in Training, this is such an easy way to create guard rails around how the product should be used and to make sure that you see issues early. It can serve two purposes, one is for any given task, there’s lots of different ways to do it. The better you do in your training, the more you’re going to kind of guide your customer to approach things the way you approach them. Notoriously, Cisco has a training franchise that’s made their product franchise much more durable and more profitable, for example.

And it’ll also help with needfinding. And a great thing is to try and get a few of your people, like your consultants, your support people, maybe even some of your developers out to do training. It is a great way to watch how customers use the product, how it relates to their work. And everybody’s watching the customer, and helping the customer understand the product better while they’re doing this. And they’re probably getting paid in the process.

Beyond training, over-invest in onboarding. If the customers are having a problem, especially early on, jump all over it. And find out where those spots are and figure out what to do with them. Because the corollary here is do retrospectives on everything, all of those rough patches. Support is expensive, it’s even more expensive to neglect it though. So, find out what those things are, smooth out the bumps by hand if you need to, but get those bumps out of there. And do that with retrospectives and a strong interface with your support or your consulting team, whoever is doing this.

Design for variation, a big customer is probably going to need to use your product differently than the last customer, at least to some degree. You have your core application and you don’t want too much extensive variation. Because even if you’re really good at building new stuff and you have a flexible technology infrastructure, too much variation is inevitably going to bubble up into configuration problems, or usability and deployment problems of some sort. APIs and services are a great way to externalize variation, some special thing that this other big customer needs to do.

So even if you end up writing this sort of custom code against your own API, that’s a great way to keep something that you feel is very customer specific from gumming up the core application. And likewise, you don’t want to have to change your code around to, if somebody needs the screen green rather than yellow, or wants to put their logo up. So figuring out where in the view layer you can customize, is a great way to accommodate that variation. Finally, if something is going to be a no, just say no clearly, and obviously offer them alternatives and explain why.

But the worst thing you can do is string a customer along and then say no, because now they’ve foreclosed on other options. Try to work through the alternatives with them, but if it’s going to be a no, just let them know, with a k, tell them. Those are some more ideas on how to work with these big customers to keep your product focused and healthy, so that these big customers are getting what you want. And you’re driving to that intersection of desirability, feasibility, and viability.