Category Archives: Market Intelligence

Outcomes is a Dirty Word! Part II

And you shouldn’t have to hear it!

The word of the day is still outcomes, and, no matter where it’s used, it’s still a dirty word.

Yesterday we gave you many examples of where outcome-based pricing has become the norm which includes, but is not limited to:

  • GPOs
  • Recovery Audit Firms
  • AI-first services-as-software
  • Big Consultancy projects

and where every single situation the entire point of the “outcome”-based sales pitch was just a ploy to convince you to pay more for less because

  • suppliers will happily match GPO prices for reasonable commitments as they have to pay the GPO a 1.5% to 3.0%+ administrative fee to get that business, and, moreover, at the head of the tail you can always get as good, if not better, prices using a tail-spend sourcing solution that automates 3-bids-and-a-buy RFQs and auctions (in a standard format that allows suppliers to automate bids) … and this solution often costs a fraction of what you will pay the GPO based on transaction fees (and then the additional savings from being able to quote every category at the head of the tail and not just what the GPO offers adds up to a greater savings)
  • proper retail-centric e-Procurment augmented with supplier and product management could prevent 90%+ of overpayments to begin with (and Lavante, Inc. proved that over a decade ago — why else would PRGX have acquired it and taken it off the market)
  • for every reliable AI-first services-as-software solution (as we all know that hallucinatory Gen-AI enables and amplifies fraud, security risks, bad decisions, etc.), there is a traditional SaaS alternative for a fraction of the price that does the same thing if you can do without the natural language chatbot interface and a slick UX
  • once a consultancy gets you on outcome-pricing, they are going to focus on projects where they know you are doing particularly poorly, employ junior grunts with five year old playbooks guaranteed to increase efficiency and reduce costs (because you are way above market average cost or way below market average efficiency), and use AI to generate their reports and strategy presentations (and hope the junior grunts both do their job and catch all the hallucinations in the prepared documents)

But, as we said in our last post, that’s not the worst of it.

The worst part of all these “outcome”-based pricing offers is that they are masquerading the grift that keeps on taking! (Which is something any American reading this should be quite familiar with by now!)

It’s not the overcharging that is the most insidious part of “outcome”-based pricing models, it’s what’s behind them.

  • GPOs want you to turn over more and more and more of your procurement to them because, the more you turnover, the more you reduce staff, and the more dependent you become … locking you in for years to come as your fees skyrocket to the point where you’re paying more to them then it would cost you to buy a modern sourcing to settle solution (that supports regular and semi-automated tail procurement and a couple of buyers [who will simply review any tail-spend awards that are new or out of bounds compared to past awards and select the suppliers for regular sourcing events, which the platform will automate until award time])
  • recovery audit firms want you believe only they can keep millions in your pockets and software will never solve the rampant overspend the suppliers siphon out of you, will do anything they can to further the narrative that you’re going to lose millions without them, that you shouldn’t even try to improve your procurement processes, and it’s best to just turn more spend over to them … again locking you in for years and years when you could be taking steps towards reducing your overspend to almost 0 with the right technology, processes, and senior category managers preventing that overspend from ever happening
  • AI-first service-as-software firms want you to go all-in on their service, fire your buyers, and believe that only their tech can get stellar results before compute costs go through the roof, the AI bubble bursts, and/or everyone realizes that the whole thing is being orchestrated by the Wizard of New Oz, it’s a bigger circus than anything P.T. Barnum ever managed to assemble, and when the curtain closes, all you’ll be left with is empty pockets (and, when you’re not looking, just like the auto-classifiers of old, they will throw as many Another Intern at the problem as required to ensure you succeed)
  • the consultancies don’t want you do anything yourself because once you realize that, if you hire qualified people and installed modern systems, you can do it just as good yourself, do it for less, and save a lot of money … so they will try to keep up the savings and strategy show as long as they can

In other words, the whole goal of “outcome”-based pricing is to take away your self-sufficiency, capability, and even knowledge and ensure your entire existence is 100% dependent on them. That way, they stay super profitable at your expense with the grift that keeps on taking!

At the end of the day, the only vendor who won’t price on outcomes is one that knows they can’t actually deliver any, even with fakery, because any vendor who can will find a way to use this trend to inflate prices and grift your hard earned gains!

P.S. You shouldn’t be surprised. It’s the same old story with a new name. It’s been going on since the first modern Procurement solution hit the market.

Outcomes is a Dirty Word! Part I

And you shouldn’t have to hear it!

The word of the day is outcomes, and, no matter where it’s used, it’s a dirty word.

You all know that where DEI is concerned, especially in North America, it’s a dirty word. As @Jason Busch will explain in detail at every opportunity, DEI has replaced “equal opportunity”, but unlike properly applied equal opportunity, which took us two steps forward, DEI, or at least its “outcome”-focussed interpretation, has taken us two step backs.

These days, everything has to be measured, and the belief is that if you don’t meet the goals for whatever racial/religious/women/minority metric your organization has defined to be an appropriate racial/religious/women/minority mix for your organization, then you aren’t diverse, equitable, and inclusive and, therefore, you should go out and immediately hire the racial/religious/women/minority employees you need to meet the metric. Merit be damned. No longer is it the most qualified resource, where someone of a minority is hired when two or more applicants are otherwise equal, it’s the most qualified resource of the identified minority, who might not be at all qualified for the job! It’s the token black employee taken to a whole new level! Not only does it reward incompetence, but it insults minorities who study and work hard to be just as competent, if not more competent, than their white male counterparts.

But I digress — we already know outcomes is the dirty word of DEI. But what you don’t know is outcomes is a dirty word across the business, wherever it is used – and Procurement is no exception! Why? It’s only become the popular battle cry since the Age of (BS) AI, whereas its prior use was been limited to situations where the consultancy, vendor, or analyst firm could hide the darkness and venom that the word contained.

More specifically, until recently, outside of DEI, outcome was primarily the verbiage of GPOs, who were doing their best to convince you to turn over a significant percentage of your procurement to them, or recovery audit firms, who were doing their best to convince you their services were the only way to recover your money that your suppliers were assuredly screwing you out of.

But they reality is that they’ve been both misleading you since the get-go. Sure a GPO can get you better prices than you can get on the long tail with their volumes, but that’s only true for the long tail. Moreover, the reality is that the costs aren’t that much less, if any less, than what you could negotiate on your own if you did a winner-takes-all long-tail RFQ to a MRO, office supplies, electronics supplier who could meet the volume across your long-tail needs, especially since that GPO is charging the supplier an administrative fee of up to 3%, and they’d happily give you the same price to NOT have to pay that fee! Add to that the GPO is charging you for their services, and you’re not saving much. Plus, when you work your way up to the head of the tail, you are definitely in 3-bids-and-a-buy RFQ or auction territory, and the application of a well designed tail spend sourcing solution will save you just as much as a GPO, IF NOT MORE!

Moving to recovery audit firms, their outcome-based pitches sound great, as you only pay their 33% if they recover the money on your behalf and fatten your bank account, but here’s the thing. If you had a properly designed retail-focussed e-procurement solution that integrated supplier and product management, did m-way matches, and prevented payments where you didn’t have good receipts that matched the invoice that matched the PO where the prices matched the contract, rejected duplicate invoices, tracked rejected units and associated credits, applied those credit notes against future orders (with the matching product), etc., you could prevent all of those overpayments in the first place — despite the fact that all the recovery audit firms tell you that overpayments (and their services) are unavoidable.

But there are more, and more modern, examples. The worst is AI-first services-as-software vendors convincing you that you should pay based on “outcomes” instead of on a traditional SaaS pricing model. Their rationale? The majority of SaaS tools that you are paying for aren’t offering you immediate, measurable, savings and, therefore, are too expensive. But if you paid for software based on “outcomes”, you’d have measurable value and you could claim the fee was worth it. And the argument sounds convincing, even if it’s complete and total bullshit. The purpose of most software is to increase efficiency, not save money. That’s the value.

And when the real reason they are pushing outcome-based pricing is that they can’t afford to sell based on a SaaS model because the compute costs of their BS AI-first are too high to cover on traditional SaaS pricing — even though there is a traditional A-RPA SaaS application that does everything their app does for a fraction of the cloud and compute cost, as long as you don’t need a fancy-smancy natural language interface or a slick UX. In other words, if they were honest about the true value of their application, they could never charge enough to cover their costs and would be out of business yesterday.

A second, more modern, example is the big consultancies taking a queue from their GPO, Recovery Audit, and now AI-first services-as-software peers and trying to justify their highly inflated pricing (which has skyrocketed over the last decade as they became the go-to firms for all big tech strategy). Especially since it’s the only way they can overcharge for projects where they are primarily deploying a multitude of AI agents (which we know produce utter garbage, just look at the Deloitte fiascos in Australia and Canada) and juniors that they hope will catch and clean up all of the hallucinations in the deliverables. (Because if they charged based on what the tech and juniors were worth, in a climate where no one wants to pay inflated rates for consultants for projects with potentially guaranteed return, they wouldn’t be able to maintain their high rates.)

There are more examples, but by now you should see the common theme. Which is simply this: “outcomes” is always a way to charge you more for less (and sometimes next to nothing) (just like DEI is an excuse to replace people with actual capability with people with next to no capability).

But the worst part, the blatant financial rip-off that always accompanies a (pure) “outcome-based” sales pitch isn’t the worst of it!

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

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!

Why Do Most Vendor Solutions SUCK (For You) And Why Are Most Overpriced?

In our last post on the final top procurement concern of today (well, to be more exact, much of the last five and possibly the next three to five years), we told you Gen-AI, which is (still) the tech-du-jour, is in many ways no different than every other tech-du-jour we’ve had over the last two decades (Advanced Predictive Analytics, Fluffy Magic Cloud, SaaS, World Wide Web) in that, like all these technologies before, is being presented as a panacea that will solve all your woes while being nothing more than the latest instantiation of silicon snake oil, with the only exception being that its failure rate is higher and its much more dangerous (and even deadly) when wrongly applied.

Unless you’re in the top 10% of technologically proficient Procurement/Supply Chain departments, have, and have mastered, the last generation of tech, you shouldn’t even be looking at it. And even if you are, you should be identifying constrained use cases (where you have nothing else) where you can build, and train, your own custom models and install it with guardrails for the inevitable hallucinations (blackmail, and even murder threats).

So if it’s so bad, why are most (new) vendors building on it? A host of reasons, and none of them good.

GREED: they want to build something quick, sell quicker (on the hype), and exit within 3 to 7 years (through PE acquisition or public offering); they are NOT in it for the long haul and not a company you should be looking at

TQ: more specifically, lack of technical knowledge; they see the hype, they see the ability to rapidly build offerings, they see that the solution works okay in the very small set of hypothetical test cases they train and test it on, and see that if they focus on something specific, they can probably build something without a lot of effort or skill

HYPE: Open-AI, Meta, Microsoft, etc are spending so much hyping the tech, and without a lot of counter-hype (or studies showing the dismal success rates, with the first two significant studies from organizations with clout only appearing late 2025), they want to build on this hype and marketing to sell their solutions (often by integrating with or building on the flawed solutions from the big vendors)

CLUELESSNESS: As I have said before, many founders not only have limited technical competence, but limited market knowledge and even Procurement knowledge. They’ve only worked for two or three companies, which had outdated Source-to-Pay solutions (if any), and are only aware of a handful of solutions. I.E. they looked at the Gartner or Forrester Map (which, as we know, haven’t changed in a decade and only contain decades old suites), did a Google search, looked at the website of the first three results that came back, and decided that there was NOTHING at all that even partially solved the problem they identified at their two or three jobs and only they could build it … even though, as we have shown, there are dozens (to over a hundred) solution for every major function in Procurement and Source to Pay and if none solve the problem fully, quite a few likely come quite close! (Like orchestration.)

That’s why most (AI-first) start-ups today SUCK. There’s a right way to build a solution, and, as you can guess, it’s NONE OF THE ABOVE!