Want to become a partner or sponsor, click here to schedule time to talk with the team.

FinOps & Beyond is what engineering, finance, and IT leaders read to understand FinOps, and what it means for operating models, accountability, and spend decisions.

Ok … for my reader’s out there. How many of you are aware of Boardy Boardman? What is it the kids say these day … IYKYK!

(But if you don’t know, check it out this website) -

Well, Boardy started reaching out recently because he/she/it (not sure how to refer to Boardy) wanted to connect me with people who work for companies and these companies may have some synergies with the FinOps Directory that I’m maintaining.

While Boardy didn’t get it right, from companies that had nothing to do with FinOps, to other companies already in the directory, I found the interaction fascinating, which is leading me to this week’s newsletter focus

The changing landscape of vendor management.

What Has Changed

Finding a vendor used to require effort and “cost” you something. You asked a peer, you went to a conference, you read an analyst report, you sat through a cold outreach sequence. I found that friction to be annoying, but it helped filtered out the noise. Only vendors with real reach or a real reason to be on your radar got in front of you.

Now, there is an agent that is attempting to remove it. Say what you want to a random AI phone call at 9am and an intro lands by afternoon. For the buyer, vendor access may have gotten really cheap. For the vendor, getting a potential meeting just got cheap as well.

Great, so there is a solution that helps make the connection, but if you don’t know what you need, this is all for naught.

The Vendor Writes Your Requirements If You Don't

Currently in one of my consulting and advising opportunities, we are beginning the search process for a FinOps solution. The first thing we discussed was the research done by a different team, about 1 year ago, that ultimately led nowhere. Now while I was not involved, I have my suspicions as to why this failed.

No requirements.

And why do I believe there were none? Because I asked for them and they could not be produced.

Which is fine.

But remember, when a buyer walks into a vendor call without a written list, the vendor demos what they're best at. Every vendor does. And by the end of the third demo, the buyer has a feature checklist, and every line on it was put there by what the vendor is selling, not what the buyer needs.

Now, with AI brokering, this will get worse for the buyer, and the reason is simple. Demos are not requirements

What "Documented Requirements" Mean

I don't mean a 40-page RFP that nobody will read, and vendors have templates for answering. I mean one page you could hand to a stranger and has five parts.

The problem, in a sentence a finance person and an engineer would both sign. "We can't tell which team's AI/cloud/SaaS spend is which" is a problem. "We need better visibility" is not good enough.

The spend you actually have. Which door it comes through (issue 30), roughly how much, and who owns it today.

What you already own. Cloud-native tools, the BI layer, whatever the FinOps team built in a spreadsheet. Most requirements are filled halfway by something you've paid for.

The must-haves and the walk-aways. Three must-haves and two things that kill the deal. If your must-have list has twelve items, it's a wish list. I still say keep the full list, but get critical of the must-halves and walk-aways.

Who owns it within your company after the contract is signed. This is the one that usually gets skipped, and it's the one that decides whether the tool gets used. If nobody owns the tool … well, you know the drill.

Write it all down before any call with any vendor. Use it as a guide and find the 5-7 companies using tools like the FinOps Directory (finops.cloudxray.ai) to narrow the vendor list. Schedule the meetings and use the requirements as a guide to the conversation. If they ask for a copy, share it with them and watch how they respond. A vendor who rewrites your list in their own vocabulary is telling you something. So is one who says "that's not us."

The Job

Three moves. (Always three moves … must be something about this.)

Move One.

Take your last vendor evaluation and try to find the requirements doc. If it doesn't exist, find the email thread where the requirements got decided. They were probably decided by whoever demoed last.

Move Two.

Write the one page requirements I mentioned above for the next thing you're buying. No more than 1 hour. And don't use a vendor's template.

Move Three.

Before any intro call, whether it came from a peer, an agent, or an inbound email, make sure to use the requirements you wrote up in Move Two.

I said in issue 30 to ask any vendor which door they actually solve. You can only ask that if you already know which door you have.

PS, Previous Issues

I have covered some aspect of vendor review, selection, gates, etc. in Issues 4, 20, 21, 25, & most recently 30. I will need to consolidate my views one day, but the key thing to take away … Document your requirements so that you do not exclude all potential solutions. Otherwise, we are back at Issue 4, the biased shortlist. Feels full circle.

Written with the help of AI. All the ideas expressed are mine and mine alone.

Subscribe

FinOps Directory

Give Me Your Opinion