Monthly Archives: January 2026

(That Vendor Rep) He Ain’t Pretty …

A verbal commentary on the current state of SaaS …

I wore two hats, I was pounding the sand
And on the weekend in a rock & roll band
One Monday aft in the office board room
In walked a rep who looked like Max Headroom

He stared at me and it was scaring me off
He said he worked for the vendor on top
I heard a voice inside me say
He ain’t pretty he just looks that way

We made a date for demo round two
I wore my jeans and he wore a suit
There was this misconception all over town
That he sold software savings by the pound

He said “Buy my app, there won’t be no fuss”
I said “Why? you haven’t shown me cost-plus”
Watching him leave I heard his grunt-in-tow say
“He ain’t pretty he just looks that way”

So, I called his office, the admin was there
Said “He’s busy, he can’t come to the phone”
I held my breath, decided to wait
A guy like me needs to set some things straight

I got stuck with the sales rep from hell
Didn’t take much time for my hormones to tell
Letting him in has been a grave mistake
He ain’t pretty he just looks that way

His ego wrote cheques incredibly fast
But the software he sold wouldn’t save us the cash
I laughed out loud to my total dismay
He ain’t pretty he just looks that way
He ain’t pretty he just looks that way

He ain’t pretty
He ain’t pretty
He ain’t pretty
He ain’t pretty he just looks that way

You Really Don’t Need to Read Another State of Procurement Report for Five Years!

Just read this 34 part series and you can ignore the 10+ surveys / studies / reports that will be collectively released by every major ProcureTech consultancy and analyst firm this year (which will likely include, but not be limited to: Capgemini, Deloitte, Everest Group, EY, Hackett, McKinsey, PwC, and many, many more)! We say this with certainty because we reviewed all of the reports they put out for the last 5 years and the vast majority of the content was the same year-after-year and firm-after-firm. You can practically count on any survey/study that tackles barriers, risks, and concerns to overlap with the following at least 80%, and that these will be the most significant barriers, risks, and concerns. In fact, in five years, only one concern will have changed, and that’s the tech-du-jour, because that’s all that was really different between 2025, 2020, 2015, etc.

You’re welcome!

You Don’t Need To Read Another State of Procurement Study for the Next 5 Years!

Top Barriers to Success

Breaking Down The Major Procurement Risks with High or Moderate Impact

Primary Concerns for Procurement Leaders

BONUS

Don’t Focus on Spend …

In a recent LinkedIn post by Celia SGAR, she made a very important point on a key requirement for good Procurement advice.

Focus on Impact, Not Spend!

Now, her advice, governance, assessment, and relationship breakdown was focussed on Supplier and Vendor Management, because otherwise you’re wasting your time reviewing the same suppliers over and over again, but the reality is that it’s good advice that should be applied across the Source-to-Pay and Category Management lifecycle and the only way you’re going to get good results in today’s turbulent trade tussles.

Right now, the typical focus when analytics is first implemented is to find the top suppliers and top categories. Then, you’re supposed to measure those suppliers and source any of these categories not currently under contract or coming up for contract in six months. Then you’re supposed to track those over the next year, match all of the invoices, and report on the savings. Which will end up being less than you expect because the reality is that most organizations know 8 to 9 of their top categories and 8 to 9 of their top suppliers without any analysis, those are the suppliers they are managing, and those are the categories that are being “sourced”, “spot bought”, or a combination of both based on what the organization feels is best.

But this typically isn’t where the biggest opportunities are! The biggest opportunities are in the suppliers providing critical components who aren’t being managed, the categories from the next tier that are not managed because the organization doesn’t realize they’ve went from tail to mid-tier, and the categories where extensive market research has not been done to not only understand market price but should cost.

Contract Management needs to focus on reviewing contracts that don’t have standard terms and conditions, don’t have risk management clauses for emerging and newly identified risks, and don’t have regular measuring, monitoring, and reporting clauses from both sides.

In other words, teams start off on the wrong focus, and continue on the wrong focus all the way through sourcing, contracting, and supplier management because they focus on spend, not impact.

And when it gets to supplier management, by not identifying which suppliers present the most risk due to supplier instability, part criticality, regional uncertainty, trade wars, sanctions, etc, the organization is overlooking, the organization is exposing themselves to risks with severe impact potential by not managing those suppliers first and foremost.

So, if you want to get Source to Pay right, focus on impact, not spend. Not only will you save more, but you’ll be more efficient, and more resilient, overall.

Safe Vendor Selection is Hard!

Every week another vendor is going bankrupt or calling it quits. Every week another vendor is getting acquired. Most of the startups, even the over-funded ones, are not going to make it. Even assuming you know what functionality you need, it’s very hard to select a vendor that is not only good for you but likely to be around for the length of the initial engagement, which is probably 3 to 5 years (mid-sized to large) because, any shorter, and you’re spending more time on vendor evaluation, selection, implementation, and integration than actually using the vendor’s product! (And even if you can get a year-to-year contract, you know you still want the solution to last for at least three years to get a return on the time you spent investigating, selecting, and implementing the solution … which might only hit majority adoption at the end of the first year!)

So how do you select a vendor that is not just “good” but “safe”?

Well, let’s go back to our process for vendor assessment and selection.

Stage 0: Find a reasonable candidate pool based on your needs based on quick high level assessments.

Stage 1: RFI Creation

This is where you focus on weeding out vendors that

  1. don’t have technology that might actually solve your problems (without getting into deep details and demos)
  2. don’t have the necessary (cyber) security and privacy protections (especially if you are processing payments or private data and have to comply with industry and governmental regulations)
  3. are just too risky from a viability perspective for you to deal with
  4. don’t give you a back-up plan if something goes wrong

If it’s a point-based best-of-breed solution designed to solve one problem that could be replaced with another solution through the API, you can probably take a bit of a risk. But if it’s a foundational sourcing execution or procure-to-pay platform that is going to power your sourcing events and category management or your procure-to-pay process, this is not a vendor you can afford to have shutdown or get acquired by a buyer who doesn’t want to support it (because they’re buying for the customer base or dev team).

So how do you figure this out? It’s not perfect, but as we pointed out before, you calculate the relative corporate debt. If it’s too high, the vendor is not financially viable, even if it is “well funded” because most investors, even PE, won’t wait more than 5 years for their return — which is hard to get in tight economies when they invested at a multiple that’s (way) too high — and typically any multiple above 5X to 7X IS if you want a return in 5 years. (That’s why you always need to ask who’s funding your ProcureTech Vendor. If it’s customers, you’re safe. If it’s PE, you have to investigate deeply. A few firms are willing to wait [more than 5 years] for their return if the long-term is very profitable. But a lot of firms are of the “strip-and-flip” mentality, and that’s not good for anyone. And those in between start losing patience around the 3-year mark if they don’t see the sales growth they want, even if their growth expectations are ridiculous!) Collect the key financials and run the equation.

As for security (and privacy), you ask for their SOC 1/2 and certifications and any other certifications that are mandatory or designated as essential by your risk management department. If they don’t have the minimum, you drop them (unless they are in process).

As for functionality, you ask them to describe (at a high level) how they support your key core requirements. The in-depth descriptions and demos come during the RFP process later. The key to selecting a “safe” vendor and not being pressured to select a possibly “unsafe” one because you didn’t do all the right checks until after you fully verified the tech (and you can’t start the process again) is to do the majority of key non-tech validations up front, not at the end.

Moreover, by doing this analysis up front, you ensure that you aren’t wasting time analyzing vendors you can’t risk from a business perspective! Capability assessments take time. If you wait until the end to look at viability, you’re wasting a lot of time whereas the RCD calculation, certification verification, and verifying key requirements of other stakeholders often takes a fraction of the time as the in-depth tech assessment.

As for the back-up plan, here’s all you need to ask up-front:
Can I export 100% of my data, in a standard format, anytime I want it?

Not 90%. Not 95%. Not 99%. 100%!

Not submit a request and ask them to export a database or wait for a weekly backup process to backup and shoot you a copy. Request on the fly, it zips up (possibly into a multi-part archive) on the fly, and you can download on the fly.

If you can always get all your data, then, even if you mess up on the risk or viability assessment or something unforeseen by both parties happens, you have the most critical thing — your data — and you can always go with the next best solution! (And then make sure the clause is in the contract because it’s the most important clause in the contract.)

Now, this isn’t a complete list of requirements, as it will depend upon the industry and geography you are in and what type of solution you are selecting, but it’s a good start!

How Does a Vendor Build a GOOD Solution?

Two posts ago on the top final procurement concern of today (and the last five and the next three years) we told you that Gen-AI, which is (still) the tech-du-jour, is not really any different than every other tech-du-jour that we’ve had over the last two decades and, like all these preceding technologies (that were all over-hyped), it is not the panacea that will solve all your problems (despite claims to the contrary) and is, in fact, simply the latest incarnation of silicon snake oil.

Then, in our last post, we asked, and answered, why most (new) vendors are building on it. There are a host of reasons — which include greed, low TQ, hype, and cluelessness — and none of them are good. That’s why, as we stated, most (AI-first) start-ups today SUCK, and, to be honest, why most start-ups in our space suck in general (and do for at least the first few years of their existence, even if they aren’t AI first).

But we also told you that we’d tell you how a vendor can build a good solution, starting with V1. Just like selecting a solution that actually works is possible 80%+ of the time (if you follow the right method that we outlined in our series on Successful Vendor Selection Series, because, otherwise, your chances of success are about 12%), there are best practices that will maximize your chances of success. But like solution selection, don’t expect any of the big analyst or consult firms (that depend on never ending hourly support contracts) to give you any real advice! (They are all instances of The Vendor in Black … Comes Back!)

1A. Get Relevant Procurement Experience and Insight
By this I mean that if you’ve only worked for one or two companies and only done things one or two ways, you don’t really understand what Procurement needs generally — you only understand what your companies needed and what very similar companies in your niche industries need. With limited experience at one or two companies, you’re not building the perfect solution for the industry, you’re building the perfect solution for YOU, and YOU may not represent the majority of the market!

You don’t have this in your late 20s, or even your 30s. You have this in your 40s. (And then to run a successful startup, you need management experience — that’s why they’re saying 50 is the new 30 for startups … by then you truly understand what is needed and likely have the management experience to pull it off.) Any earlier/younger than this, and you better engage some real independent Procurement experts to help you define what you really need to do to address entire verticals or wide swaths of the market.

1B. Get Relevant SaaS Development Experience
You also need real SaaS Development Experience. The ability to vibe code, the ability to use low-code / no-code solutions, and even the ability to write web script DOES NOT COUNT! Script kiddies don’t build enterprise apps — the dot com boom and bust (which some of us remember — and the rest of you need to study because the Gen-AI bust could be as bad) made this clear. You need real, educated, experienced developers and architects who have worked in real tech companies building, deploying, and actually delivering enterprise apps! These are the only resources who build enterprise apps.

Now, it’s very, very unlikely you have both. That’s okay. That’s why you get the perfect partner that compliments you so that you collectively possess CPO (Chief Product Officer) vision and CTO capability from day one. Then, if the Procurement Expert founder is not a CEO, the two founders seek a third founder who is a real CEO with relevant C-Suite domain experience, and if the Procurement Expert founder is a CEO, the two founders seek a real domain expert who has product management experience who can be the CPO.

2. Define the problem you want to solve in detail!
What is the real pain point? What does the solution look like? How do you measure it? How do you get there?

Once you’ve answered the key questions and fully defined the problem, define the process that solves it. Then define the variations to the process. I.E. What are the core, required, steps. What are additional optional steps. Where might approvals or sub-processes be required in specific situations.

Then define what can be automated, what needs to be done by a human, and where there are multiple options.

Only once you fully understand the process and variation across companies of different sizes, categories of different complexity, and departments of different maturity in the verticals you are going for can you attempt to build a platform that will support it.

3. Identify the minimally appropriate and best-match algorithms for each process step and the best tech for stringing the algorithms together.

Some steps will just be collecting information on a form, validating the response type with regular expressions, and validating the data with third party integrations … and possibly require a(nother) user to accept it. Other steps will just be running pre-defined analytics and suggesting or taking an action based on the result, possibly using a rules-based multi-select with adjustable parameters. Others will be RPA auto-execute based on previous steps. Others still will be machine learning based on collected inputs from previous steps. And so on. (Very rarely will you need advanced AI and rarer still will you need [anything close to] Gen-AI. This is another reason AI-first is so wrong!)

When you go through this process, you will find that not only do most steps not require any (Gen-)AI at all, but most are better served without AI. You’ll find it only fits in the few situations it is good at (natural language processing, large document search and summarization, potential pattern identification, etc. for Gen-AI), and that if you apply it, you should do so narrowly, with custom trained models with guardrails and, if possible, have users accept recommendations to modify rules to reduce dependence over time.

4. Remember that good enterprise solutions have MDM (Master Data Management), Workflow, and Orchestration at the core.

These are not after thoughts. In addition, if you plan to support global users or sell your solution globally, multi-language support and internationalization MUST be at the core as well.

5. Select a programming language and an enterprise stack that supports ALL of the requirements identified above.

Not the stack that is cool, the stack that makes it super simple to get MVPs out the door, the stack used by your favourite AI platform, the stack recommended by your favourite cloud provider, but the stack that will work for the enterprise application you want to build. Then select the cloud provider — most of them are pretty competitive, and most of them support the majority of enterprise stacks, especially if they are not Microsoft (which wants a .Net/C# Azure Friendly Stack).

6. Plan out three years of major features.
These major features will support additional process extensions and related processes as there’s no significant shelf life for a niche app that only does one thing unless that one thing is so complex that almost no other application does it and the cost of building such an app from scratch by a new startup is prohibitive (especially relative to the untapped market potential).

Too many startups define the MVP, race to build the MVP, and then try to figure out what comes next. This is equivalent to shooting yourself in both feet with your brand new shotgun.

1) While you’re trying to figure out what to do next, your competitors are already building it.

2) By failing to define where you are going, you’re taking shortcuts and building the foundations for a dinky niche SaaS app versus a full-fledged enterprise application. The way I like to explain this to non-technical folk is that if you’re designing to MVP, you’re building the foundation for a two-story house and that means all you can ever build on that foundation is a two-story house. When you’re thinking three years ahead, you’re building the foundation for a multi-story apartment complex, building the first floor, and just pausing before you build the second floor. (And so on.)

In the first case, once you figure out what comes next, you realize you don’t have the right architecture or infrastructure, and then have to stop and rebuild the core, slowing down your advancement and future releases even more unless you can miraculously define the minimal API to the core you will be rebuilding up front, simultaneously build the new features perfectly to that API while trying to re-architect the core, and somehow fully achieve that API and don’t have to change it significantly during implementation when you find out it just won’t support the required workflow or orchestration … which it inevitably won’t, and then you need to update the API, and then this necessitates a rewrite of the business logic layer (and even UX) on the fly, which not only results in wasted time but wasted development because you tried building multiple levels of a house of cards all at once. A few extra months of research and planning up front will save you years!

7. Get a couple of beta customers by the time you hit beta on the MVP.
You need to verify all the assumptions YOU made in the design and implementation with a real customer (that wasn’t one of the companies you came from), test the usability, and see how real Procurement departments work (that weren’t the one or two you had experience with). You might find you have a lot more work to do before release than you thought, but it’s better, and easier, to do this before you sell it to enterprise customers as a ready-to-use enterprise product than after!

In other words, it’s not just designing an MVP on a napkin, vibe coding your way to implementation, giving a flashy demo, and delivering on a major cloud platform. (Which is what a lot of startups are doing, and that’s why so many SUCK.) It’s deep thought from day one over months and months, if not a year or two (if you are trying to do something significantly complex). But then it’s a real solution that will be relevant for years (and years) if done right (and continuously improved, appropriately maintained, and always priced appropriately).

And yes, you can argue that more steps, or at least a deeper refinement of the above steps, are needed, but these are the absolutely critical steps and many of the ones that often skipped — which results in poor solutions and sometimes complete startup failure!