How to make the most out of meetings with vendors
22 March 2019
Building relationships with vendors is an important part of my role as Tech Director and when I joined the Financial Times, the excellent Rob Shilston gave me his five top top tips on how to make the most of those meetings. He has kindly agreed to share them here.
1. Use it as an opportunity to learn about how others are doing things
- “What changes in investments are you seeing other organisations making?”
- “How have others turned this tech into a business advantage?”
- “What’s really impressed you recently?” and “We like to learn from other teams who are doing great things. Who would you recommend we speak with?”
- All the way down to the mundane: “We are struggling to find the right cables to have in meeting rooms. You must go to lots of offices. What seems to work best?”
2. Reiterate that we aren’t special
- We want to use their tools in the most normal way possible.
- They MUST tell us if we’re trying (or intending) to do things in a strange way.
- How should we change so that we can get the most from their products and services, and so that it’s easier for them to support us in the long term?
- On the flip side, we might be helping them develop their future roadmap, and be an early adopter/beta partner on a future service. That’s fine, providing all are knowingly entering this arrangement.
3. Do push for industry wide solutions and collaboration
- With GDPR, all companies would have been going through the same things. Many of the large vendors were really really poor at working with regulators to agree “This is good CRM practice”, and then informing their customers how to do it right. Instead, all customers had to reinvent the wheel.
- Ask who is doing things like X, even outside our sector.
4. Avoid talking absolute price, but instead try pursuing the pricing model itself. Is it a fair model?
- Suppliers incur costs based on their time, the amount of network traffic, storage and computing they’re doing. But they frequently have a pricing model which doesn’t correlate with these underlying drivers.
- What this means is that when we implement their service, we may make really bad design decisions so that we can avoid cost oddities.
- For example, if the product incurs a cost per user, but we need lots of people to have access each for only an hour per week, then we may end up sharing user-accounts. That’s not best security practice, probably reduces the utility of the software, but avoids a 10x licensing fee. Highlight these challenges to vendors and negotiate. Usually they’re open to adapting.
- Be utterly blunt if they’re failing to do basics/charging extra for things they shouldn’t be.
- For example, in early 2019, it’s unacceptable to be charging customers of a SaaS product for SSL. Equally, multi-factor authentication is just part of the way of doing business.
He also had some other tips
These were Rob’s five top tips, but he did have some suggestions for other things the meetings could be useful for:
- Requesting executive level briefing – if you or other or other senior folk are new to a company who is using an existing vendor, do insist on FREE exec level briefing on the product (note that this isn’t how-to, but more a clear walk through of its capabilities and benefits), and be wary if the supplier isn’t prepared to properly explain to a tech lead or exec the value and results that the product can achieve. This is especially important when you’re inheriting an existing contract and meeting a vendor for the first time.
- Going specific on long term things and macro concepts, e.g. “How do you see other publishers manage metadata?”
- Seeking their suggestions on how should we be structured to make the most of the service/software, e.g. “What’s a good approach for rolling out the service? For training? For improving?”
- Using the vendor to help find other vendors, e.g. “Who are your competitors, and why does your product remain different?”. This is also a useful way to rapidly understand what a new vendor is offering if you’re not sure.
And one to avoid:
- Avoid going into details of the service unless there’s been an operational incident OR their support is letting our team down.
- In that case, be specific about where you need support, e.g. “We’ve bought your SaaS offering so that we don’t need to manage it, yet our team seem to be spending a lot of time chasing [some problem]. Are we using it wrongly? Or is it unreliable? How are you going to restore our ability to use this product?”
If you’d like to be notified when I publish a new post, and possibly receive occasional announcements, sign up to my mailing list: