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 five, over-Invest in training. This is such an easy way to create guardrails around how the products should be used and to make sure that you see issues early. It can serve two purposes. One is, for any given tasks there are 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 treating franchise that's made their product franchise much more durable and more profitable, for example. And also 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 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's 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 in 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. API's 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 you later 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. Know with a K. Tell them. Those are some more ideas on how to work with these big customers to keep your products 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.