Category Archives: Best Practices

Have We Been In The Dank Basement So Long That We Don’t Care If the Fish Stinks?

the doctor has to ask because when Jon The Revelator asked if you would eat a piece of fish that has been in your freezer for 10 years? 5 years? 1 year? not many of you spoke up and it seems you are quite okay with old, smelly fish, which, in this case was a metaphor for provider case studies, as this was a follow up to The Revelator‘s post that asked Should Solution Provider Case Studies Have a Best Before Date.

A question, which was in turn sparked from a comment by Duncan Jones to his preceding inquiry on what can 2005 tell us on why most AI initiatives fail in 2024, which is a question that was partially sparked off of a post the doctor himself made on how we need to hasten onshoring and nearshoring — the drivers will pound those who don’t into the ground! (Part 2).

While this sounds like a long, meandering, pointless introduction, it’s exactly the opposite. The purpose is to demonstrate that not only are many parts of Procurement and Supply Chain connected, but they are connected in complex ways that require sufficiently broad, as well as sufficiently deep, solutions that address the complexities being experienced by the organizations a vendor is trying to sell to.

Furthermore, this means that for an organization, or a consulting partner, to select the right solution, they need deep information on what the solution does, where it’s been used, and what it has been proven to do. Traditionally, this would mean that they would require product sheets and demos, customer references, and case studies to make a good decision.

However, centering in on this last requirement, not all case studies are created equal, and not all are even “case studies” at all. What once was the domain of third party analysts, consultants, and professors (who would do proper due diligence, data collection, and impartial write-ups for educational and investment purposes) has now become the domain of marketers who get happy customers, often still wearing the rose-coloured glasses that came free with the install, to tell a story that they write-up and promote using very little, and often unverified, data. Those are not useful at all. Furthermore, if you don’t know what version of the software, what stack the customer ran on, and/or, and sometimes most importantly, when the study was done (and the time period it was done over), is it even still relevant at all?

This prompted the critical question from The Revelator about whether or not studies should have a best before date. the doctor leans towards no on best before date, because just like different types of fish have a different shelf life, different case studies will have a different shelf life, but votes a most definite yes on a packaging date.

To elaborate on the comment he made when asked, the following is absolutely critical to be included in the case study:

  • when the case study was written (packaging date)
  • the time period it was over (processing dates)
  • the precise metrics that were tracked and how they were computed (labelling compliance)
  • the extent of organizational data that was used (ingredients)
    [as well as the full extent of data available (may contain)]
  • the products, and versions, that were used (processing)

In other words, a feel-good story with a few random numbers is not case study! (the doctor would say any marketer trying to pass such off as one should be ashamed, but any marketer who did would obviously be without shame, so there’s really no point in saying it.) A case study has rigour in definition, methodology, data collection, and exposition and contains all the information that would be needed if a third party wanted to repeat it. (The same way a scientific study provides enough detail for an independent team to verify it.) Anything less should be considered unacceptable.

And, most importantly, since business processes, products, systems, and stacks continually change, a study (processing) date and a publication (packaging) date MUST be included so that a buyer can make an informed decision as to whether that study is still relevant to them (as they decide just how much stink they are willing to tolerate).

Playbooks? Those Were the Good Old Days!

THE PROPHET Jason Busch recently posted about 50 Years of Pivots in Procurement where he stated that:

  • 1980s: Procurement is Supply (prioritize)
  • 1990s: Procurement is Sourcing (save)
  • 2000s: Procurement is Transactional (systematize)
  • 2010s: Procurement is Spend (manage)
  • 2020s: Procurement is Playbooks (rinse/repeat)
  • 2025 : Procurement is …

the doctor‘s first response to this: Playbooks? He wishes!

In the late 2000s and 2010s, the top Procurement consultancies had playbooks that had good processes, methodologies, and metrics that would help any organization not best in class out-of-the-gate because they were built on tried-and-true processes, analysis, and results that worked. They weren’t centered on just implementing tech for tech’s sake, trying to roll out Procurement for the masses (who didn’t want, or need, a full Procurement solution — just easy acquisition of the products and services [they were responsible for buying to do their jobs on a daily basis] in an organizationally compliant way), or implementing AI for the heck of it (because they over-invested in training their workforce on Gen-AI solutions that have no value).

But that’s not the worst of it. In the doctor‘s view, the worst of it is that

2025 Procurement at many organizations is (on the road to) “Consumer” (intake/orchestrate).

Procurement is now all about ensuring every single person in the organization can “buy” on their own from the catalog or preferred vendor with no real management as long as they have “budget”, “authority”, or it’s a “preferred vendor”.

That’s just transactional Procurement on steroids. (i.e. it’s 2000 all over again, we just survived Y2K, and we don’t know how to manage spend with tech … really?) Now, it’s true that getting Spend Under Management (SUM) is good if you do something with that Spend Under Management data, but this surely isn’t.

Why? First of all, if you talk to a real old timer who did Procurement in the 80s/90s about this “intake” or “orchestrate” phase and they’ll probably say they just don’t get it. As far as they are concerned, Procurement is supposed to be more strategic and focus on all encompassing processes, strategies, negotiations, etc. Not about trying to manage every single nickle-and-dime purchase in the organization. This is one of the leading reasons results (and costs) in most organizations are getting worse, and not better.

Secondly, see our recent post on how Marketplace Madness is Coming on how

  • “Pay For View” Intake makes no logical sense
  • “Solution Sprawl” Orchestration doesn’t make any logical sense either
  • when it comes to I2O, it’s “where’s the beef” and “where’s the market” [hint: not where most of the providers are looking]

Furthermore, the age old analogy applies here — they can’t see the forest for the trees. Nor can you manage it that way. If you spend too long trying to focus on each individual sick tree you come across, the sickness will spread and consume the forest. Sometimes you have to just cut and burn the tree.

In other words, the madness is taken us towards consumerism in Procurement, and it’s the wrong path! We need to get back to process-centric playbooks, and let the tech take back-stage, as the tech supports Procurement, it doesn’t do it, or solve it, on its own.

Mistake X that Procurement Founders Keep Making

As part of the discussion between the doctor and Jon The Revelator on how 2005 can tell us why most AI initiatives fail in 2024, the doctor, who recently finished the first six installments of his Mistakes Procurement Founders Keep making series, noted one mistake that founders keep making that maybe he should have made more explicit.

Specifically, and this applies to founders who are techies / ex-consultants in particular who are tech first, the one big mistake that is still being made two decades later is this:

Building a “solution” without having identified the “problem” they are trying to solve.

Or, as The Revelator put it, you must solve problems before selling solutions.

(And, preferably, not a problem that was already solved, and solved better.)

While this mistake could fall under foundational market research, it also stands on its own because these tech-minded individuals think that just because the tech doesn’t appear to exist, there’s a market for it.

While the “find a new ‘solution’, figure out what it works for later” might work for PhD students (develop a new algorithm, technique, material, etc. and then figure out what it can be used for), it doesn’t work well in the business world.

While techies might think business people want cool, the reality is that business people, especially those writing big cheques, don’t care. Techies think business people want slick UX. The reality is that business people don’t care. Techies think business people want the latest and greatest tech stack. But, again, business people don’t care.

The techies fail to realize that the business people they are selling to are NOT the people in the organization who are actually going to use the solution, which could be on decades old tech, with a horrendous UI and UX, and descriptors from an 80s horror film. All the solution buyers in an organization care about is

  1. will it meet the business need,
  2. will we get it at the lowest price and,
  3. if the solution processes transactions or personal data,
    does it have all the appropriate security certifications and monitoring?

That’s it. The budget controllers only care about whether or not the solution will solve their problem efficiently, effectively, and affordably. And if you can’t demonstrate that, they won’t care whether or not they’re buying it from Someone Who’s Cool.

Dear SaaS Founder. We know you’ll make mistakes, but there’s no excuse to make these!

This month, having seen many of the same mistakes that he’s seen over 18 years as an (independent) analyst and 20+ years as a consultant, still being made in new startups (since leaving Spend Matters almost 20 months ago on 2022 Sep 30) the doctor decided to put his experience to e-paper and chronicle 15 of the most common mistakes he sees all too often — mistakes that don’t need to be made anymore. (In the early noughts, before there were dozens of tech startup books telling you what worked and what didn’t for founders that went before, some of these were excusable. But not anymore.)

Now, these aren’t being pulled out of the air. Over his career, he has researched/engaged in depth with over 500 vendors and their solutions as an analyst, consultant, or diligence professional, and publicly (co-)written up the solutions of over 350 of these on Sourcing Innovation and Spend Matters. He’s also followed the progress, or lack thereof, of many of these companies and seen some grow, some stagnate, some get acquired, and some ultimately have to shut their doors. The number of analysts still active in our space that can make the same claim-to-fame can likely be counted on your fingers!

He’d hope after last year’s series on the 10 + 2 best practices for success, some of these mistakes would become obvious and their frequency would decrease, but he was obviously too indirect in why those best practices were being focussed on and what some key takeaways were.

In any case, because he loves innovation and startups (which should be clear from the fact that he writes about 50 to 75 of them per year FOR FREE) and would like to see founders with good products, platforms, and commitment to their customers succeed, he’s hoping this more direct approach will help those companies who just started and who are still making a few of these stop doing so before it’s too late and help others start on the right track.

So without further ado, here are the links to the articles on the mistakes you’re still making:

Enjoy. Educate. Excel! (No, not the spreadsheet, the intransitive verb!)

Dear Sourcing/Source-to-Pay/Procurement Founder: Please STOP Making These Mistakes! Part 6

In Part 1, we reminded you of the 12 best practices for success that we published last year and noted that, since this obviously wasn’t read enough (or properly) understood, as the doctor is still seeing founders make the same old mistakes year after year, he needed to do more. So, using his 18 years of experience as an (independent) analyst and 20 plus years as a consultant, during which he has researched and/or engaged with over 500 companies, of which 350 were publicly covered on Sourcing Innovation or Spend Matters (between 2016 and 2022), he’s decided to make plain at least 15 of the same mistakes he has seen over and over again, in hopes that maybe he can prevent a few founders from making them again.

Then, we covered the first twelve (12) of the 15+ mistakes the doctor has indicated he has seen over and over again.

  • Assuming that because you were a CPO, you don’t have to do your market research. (Part 1)
  • Assume you can serve any company that shows interest in your product. (Part 2)
  • Assume you can go for disruptive or innovative first. (Part 2)
  • Assume you can take Tech Shortcuts and Fix It Later. (Part 2)
  • Assume that because you could run a Procurement Department that you can run a SaaS company. (Part 3)
  • Assume you know the average process and technology competency in your potential customer base. (Part 3)
  • Assume that you know the messaging because you received the message. (Part 4)
  • Assume if you cut the price to get in the door, you can raise it later. (Part 4)
  • Assume you need a CMO early to get noticed and build demand. (Part 4)
  • Assume that becoming an “influencer” or “thought leader” on LinkedIn will replace proper lead-generation! (Part 5)
  • Assume that you need AI or that jumping on the Gen-AI bandwagon will save you. (Part 5)
  • Assume that you can get a great salesperson or grow your sales team (primarily) on commission (only). (Part 5)

If the mistakes stopped here, we’d be done. But they don’t. So, today we’re going to cover the next three and conclude this initial series.

13. Assume you can hire and do it all in-house!
There’s a reason that best practice #10 was get advice and listen to it and #11 was get the help you need sooner than later, and that’s because, when you are small, you can’t hire the people you need to do it all in house. You need a lot of expertise from a lot of senior people, all of whom will be on the higher end of the salary scale. And while these people are worth every penny they demand, that is only the case for the role(s) in their skill set, and you will need a lot more roles than you can hire for.

You will need to not only listen to the analysts that will talk to you, but get one or more expert analysts / consultants to help you tackle key challenges you don’t need a full time person for and/or can’t justify hiring at the current stage in your journey. The best people are not only great at what they do, but willing to admit where they aren’t great and could use the help.

14. Assuming you can barter for what you need when you finally realize you can’t do it all in-house.

A lot of founders are extremely cash-conscious, and while the doctor respects that, you can’t barter for everything you need to keep costs down. And when the doctor says barter for what they need, he means some will try to barter for anything:

  • for a while they would try to barter for rent reductions with stock options, even after the first IT crash … but most landlords are pretty shrewd when they have fixed assets on which to make their money and followed the “fool me once, shame on you, fool me twice …” philosophy and either politely said no or just laughed
  • when print marketing was big, he’s seen software and services companies try to barter for content, editing, design/layout, and even overhead/margin with free software / consulting / marketing services (though newsletter inclusion, promotion at an event, free consulting, etc.); this didn’t work very often
  • when they couldn’t get good trade in value on IT equipment that needed to be upgraded (with the IT vendor), all of a sudden it was hard-ware for services; that didn’t work well either

He sees (much) less of the above today, but the following is still too common:

  • speak for free at our event for exposure
  • write for us and we’ll send your article to 10,000 subscribers
  • advise us on our roadmap and we’ll give you a recommendation to our partners/customers
  • help us with our marketing and we’ll give you referral fees

Sometimes these deals happen, but, despite what the founders think, they don’t work out that well (for the founder).

Let’s consider each of these example cases:

  • if the speaker you want normally makes 10K+ a day for speaking at an event, they don’t need your exposure; this means that if they do agree, they are likely doing it because a) they aren’t as big a draw as you think they are b) they have a vested interest in your company (through an investment, through referral fees, or through projects they get associated with it) … i.e. unless they have a vested interest, you’re not getting the value you think you are
  • they know the open rates and the actual read rates and then the percentage of people who will ACTUALLY notice their name, so if they have any reputation at all, they are just going to work for a paying client instead (now, you might luck out on a newbie who’s really great, but do you really want to roll the bones on critical messaging?)
  • if they’re good, they can make their own recommendation to your partners/customers
  • IF they are willing to accept referral fees (because the minute they do their potential clients will know they are biased towards your solution), why would they want to strike a deal with your company when they could get 10 times the fee with a big company that will sell platforms at 10X what you will get for your module?

In other words, you get what you pay for, and if you pay nothing, you get nothing. this doesn’t mean you have to spend top dollar, as many analysts and consultants (or at least those NOT at the biggest firms) will sometimes offer lower rates to startups willing to accept a limited, but well-defined, set of services offered on the analysts’/consultants’ schedule (to fill gaps between big client projects). In other words, it’s not necessary to pay top dollar to get top value.

But do NOT push referral or commissions on analysts or consultants who say they don’t accept commissions or referrals. You need to remember that some analysts or consultants can only maintain their reputation and make a living IF they are unbiased. And while unbiased doesn’t mean that such an individual cannot have a preferred solution of a given type (which could even be your solution), it does mean that such an individual CANNOT accept a fee for recommending it, because then the buyer would have no way of knowing if the recommendation was truly because the individual believed it was the right solution or if it was because it was the solution that, in the given situation, would lead to the individual getting cut the biggest check from the provider.

(However, if you want the doctor to stop talking to you, it’s one of the fastest ways to make this happen. If you’re curious, another fast way is to waste his time, but, honestly, if you don’t want a check-up from the doctor, he’d just prefer you tell him you only do commission deals as he’d prefer you not waste his time.)

15. Assume that you can take less than your forecast in a raise and still be successful!

the doctor has seen too many companies fail (to meet potential) by

  1. over aggressively estimating the minimum amount of money they need to reach profitability
  2. then taking only 70% to 80% of that to close a VC round

The #1 rule of a startup is: it will ALWAYS cost more than you think.

  • getting to MVP will take at least 30% more effort than your development team thinks; halfway in they’ll discover that the data model isn’t enough; the out of the box workflow won’t quite cut it; the algorithm isn’t fast enough; there are scalability issues with the current architecture configurations; the stack has a few bug/known issues that have to be worked around (when it’s too late to swap it out); etc.
  • you’ll always discover core functionality that you missed (possibly due to a lack of market research) you need to have to close those first few customers (without deviating from the core you should be focussed on)
  • cloud costs will be more than expected (as providers raise prices, you need replication and backup, and your beta/demo customers drive the system hard)
  • you won’t be able to do as much virtual and sales / support will have to do more travellng than you budgeted for
  • you may be able to get away without that office, but you will still need to bring the team in to a central location a couple of times and rent workspaces, pay hotels, etc.
  • you will not be able to rely on consulting partners as much as you think and will need to hire more implementation managers than was in the budget
  • you will need to bring in more demand gen / pre sales / sales earlier than you would like under pressure to show eventual profit
  • etc. etc. etc.

In other words, if you want to stand a reasonable chance of success, you have to inflate all of your numbers 20% AND not settle for less than that, because, without any flux (to weather these increased costs and unexpected events like epidemics, the loss of a key resource, etc.), you just won’t survive.

Now, are these all the mistakes the doctor has seen? Most certainly not, but these are among the most common and NOT making these would a great first 15 steps to ensuring your startup gets on the path to success. So, read them closely, then re-read the best practices, and start your journey with the knowledge of what you know and, more importantly, what you don’t so you can find the help (via partners, analysts, consultants, and appropriate beta customers) you need to make your startup a smashing success.