Your marketing folks have gotten you an audience and you're meeting with a potential client tomorrow. That's the good news. The bad news is that you just heard your marketing folks have gotten you an audience and you're meeting with a potential client tomorrow. You have 24 hours to do some preliminary planning, get your team together and prepare to impress. Can it be done?
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
First, it's important to understand how this meeting came to be. Was this meeting called by the network manager or the IT manager? Is it in response to a specific need or project, or is it based on production problems that need to be solved? Did the CIO arrange this meeting because he has buddies at Cisco? If you don't have all the facts, you are likely to be delivered to the firing squad of a highly technical team that may be licking its chops waiting to strike in earnest. Perhaps they already have strong relationships with other VARs and see you as a threat. Maybe they don't use service providers and see you as taking over their jobs. I cannot reiterate enough that you need to strategically understand everything about this meeting if you want to come back. If you don't have a real sense of purpose behind this meeting, be prepared to do a lot of listening.
Make sure you bring the right people with you. If you're meeting with the client's technical team, leave your marketing folks behind. Technical pros distrust marketers. But do bring the appropriate technical folks. For example, don't bring a design pro to troubleshoot a network problem, and don't bring production folks to design a network. Needless to say, don't bring 3Com engineers to a Cisco meeting. There is a real distinction between an engineer and architect and an administrator. You need to understand the difference and bring the right food to the table.
If you were involved in pre-meetings with technical staff and have an understanding of the meeting's objectives, you're looking at a different scenario. Be prepared to give the client a "sample" of your services in return for their time. For example, IBM has products that help with architecting pSeries LPARs (logical partitions). One such product is their Systems Planning Tool (SPT). If appropriate to the customer's needs, whip out your laptop and show them some of the technical architectural work you've done using SPT. Plug in some of the technical numbers with their Unix administrator and actually help the client determine their needs on the spot! There is no better way to impress the customer and help them determine their needs by actually doing something for them while you are selling them on your services.
However, even if you were involved in pre-meetings, you still might not be in a position to determine the networking needs of the customer. For example, you were told that the existing environment does not scale well and there are single points of failure. In this situation, try to get as much information about what they have as you can, so that the meeting can be even more productive.
The key word in determining the client's needs is "listen." I cannot stress this enough. Try to talk with some of the network administrators or engineers (beforehand) to fill in some of the blanks that the network managers might not get. Understand exactly what you are being asked to do and in what timeframe. Take good notes. If you come on too strong, like you know it all and are going to fix everything, the IT department will eat you alive -- perhaps not publicly, but when you leave, they'll rip you to shreds and you'll never be invited back. While IT managers make the final call on the service provider to use, they always want buy-in from their staff, and that won't happen if you demean staff, act arrogantly or worse, are shown to be ignorant. At the same time, if your team has not done the required homework (understanding the real objectives for the meeting), it could end up just as bad.
Finally, schedule the second meeting while you're there and have everyone's attention. As you know, it's extremely hard to get IT people to pick up their phones.
About the author:
Ken Milberg is the founder of Unix-Linux Solutions. He is also a board member of Unigroup of NY, the oldest Unix users group in NYC. Ken regularly answers user questions on Unix and Linux interoperability issues as a site expert on SearchOpenSource.com.