Category Archives: Best Practices

So You Admit You Might Be a Dead-Company Walking. How Do You Avoid the Graveyard? Part 1

Good for you. It takes a lot of guts to admit you’re screwing up badly, burning cash faster than you’re taking it in (or able to raise it), and that you boarded the hype bus heading straight for the edge of the cliff before making sure the brakes and steering wheel worked! (So much so that the doctor wasn’t really expecting you to admit it. That’s why, this time around, his dead company walking series was targetted at buyers to help them avoid companies who won’t do what it takes to survive the coming market crash in our space.)

Fortunately, the fact that you admit it now, before the market situation gets really bad, means that you likely still have time to get treated, recover, and make a comeback before you bleed to death. So what do you do?

In short, you

  1. start by admitting to every mistake you are making and do something about it, even if it means ousting part (or all) of the founding team (assuming they don’t still have a majority control, in which case you jump to the next ship while there are still ships sailing to jump to) then
  2. continue by looking for cost-effective opportunities for improvement and pursue them and finally
  3. never, ever, ever forget the timeless basics.

Today, we’ll start with describing what you do when you identify, and admit to, the first mistake we chronicled in our two part introduction to our “dead company walking” (Part 1 and Part 2) series (where we helped your potential customers identify problems that signify you are a SaaS supplier they should be walking away from).

1) Too Many Assumptions, Too Few Verifications

Double Down on Market Research – Know Your Competition

You’re not selling in a blue ocean. You’re selling in a very crowded ocean, and if you did your market research (or even glanced at the Mega Map, you’d know it! Depending on your core offering, you have at least 50 competitors, and even if you focus in on an industry niche or market size, at least a dozen, if not two. And there’s only so many customers to go around, which means there’s only room for a handful of companies with your specific focus to be smashingly successful.

So learn who they are, what they do, and, most importantly what they don’t do that they should do, and then do that, because, at the end of the day, you need to sell on core and differentiated value.

Double Down on Market Research – Know Your Target Customer’s Pain Points

Your customers don’t want cool. They don’t want custom Aston Martin’s that need to be tuned by a high price mechanic every month to keep running and can’t be driven on anything but the smoothest of roads. They want Ford tough F150s that only need maintenance every six months and can withstand the rugged terrain they work in.

They want a platform that helps them do the job they have to do everyday, the 80%, not the frilly 20% and nothing else. Learn their pain, and, most importantly, after the core pain is solved, focus on their frustrations that your competitors aren’t. That’s the core and differentiated value that will make you super successful, not whatever technology is currently hyped to be in Vogue. After all, like real fashion, tech fashion changes (and in some cases goes out of style) every few years, and doesn’t necessarily solve any problems in the first place (like Gen-AI).

Get Help! You’ll Only Identify So Much On Your Own.

Especially if you’re new to the space and started your company because you were a purchaser forced to use tool X that didn’t do function Y at your last job. You know one tool well, the two competitors who were finalists in the RFX okay, and that’s it … especially since your lack of understanding of Procurement (marketing) terminology led you to believe that the first few results of a Google search and the Gartner/Forrester maps chronicled every vendor you need to know. Which, as one glance at the Mega Map should convey, is not even close.

Plus, you knew your company’s processes, and, if you were involved in an association and actually went to meetings and roundtables, maybe a couple others. But now you have to serve industries and quench the thirst of multiple types of buyers. You need the help of someone who has seen the rise and fall of companies in this space from 1.0 through the current 3.0+ offerings and knows the products, the players, and the pain well if you want to quickly zero in on what the core and the differentiation actually is for your company.

Stay tuned for Part 2!

You Admit You Might Be a Dumb Company. How do you avoid the fork in the road that leads to the Graveyard? Part 2

Good for you! As we noted in part 1, admitting you might be a dumb company is the most important thing to do on the yellow brick road to enlightenment.

So what do you do next? In short you continue to:

  1. admit to every mistake you are making and do something about it,
  2. look for opportunities to improve that are logical next steps, and
  3. never, ever forget the timeless basics.

Today, we’ll continue with describing what you do when you identify, and admit to, one of the last five mistakes we chronicled in our re-introduction to our “dumb company” series and want to do something better.

6) No More Training

Start picking out your corporate coffin and writing your corporate obituary, because the minute you stop learning and stop improving is the first minute on your corporate deathbed. So:

  • time your process throughput across corporate processes (and compare to industry averages)
  • examine your SaaS utilization (on the SaaS apps you keep after you Get SaaSy)
  • train where either can be noticeably improved

7) Tighten The Belt One Notch Per Month

You can trim the fat, but you have to stop trimming when the fat is gone.

If revenue is not increasing, it means that either your marketing or sales is not effective or your product is not appropriate. In both cases, you will have to invest further. In the first, to get some consulting from an expert low-cost guerrilla marketer as well as the educational assets you will need, and then some training on how to improve the effectiveness of your sales cycle. In the latter, expert advice on where to focus the development roadmap to make it more appropriate, and appealing, to your target market.

If there’s not enough cash, then you will have to wrangle more investment (even if the terms aren’t what you hoped) or, if you have revenue, take a loan (and keep your equity).

8) From 60 to 0 in Marketing

As already indicated, just because you wasted the entire $M marketing budget on overpriced events, email marketing, “analyst firms” and their maps, soundbite marketing, and a CMO who only cares about his jet-setting media-centric lifestyle, that doesn’t mean you can cut it to 0. If you do so, crawl in the corporate coffin as it’s almost time to nail the lid.

You need constant visibility as you have to be “the name they know” when your target customer finally gets budget and can invite you to an RFP or a contract negotiation. At any given time, half of your customers are going to be six months away from a potential budget. One fourth, nine months, and only one fourth will be close to a budget season, where they may not get budget, and then it’s fifteen months before they can talk to you.

Constant visibility doesn’t mean a booth at a 100K event every month and the media that comes from it, it means monthly educational content that not only keeps your name visible, but keeps you front and centre as they look for that content to consume, to learn from, and hopefully build their business case to buy your product.

9) Real Innovation is Too Risky

First of all, a lot of customer problems can be solved with evolutionary renovations to existing tech, and “innovation” is thus not as risky as you think.

Secondly, sometimes real innovation is needed to solve a problem, or at least do so affordably. While it’s risky (maybe you won’t solve it / get it right), if solving that problem is key to your corporate growth, and possibly your corporate survival, it’s definitely riskier not to pursue innovation. So do it, but carefully and in a controlled manner — don’t bet the bank on anything without a [very] high probability of success. Innovation should NOT be costly (beyond the innovator’s salary) in software-based tech. It’s just research, trial, and error. More than that, and you’re not doing it right.

X) Raise the DrawBridge!

You don’t know everything. And that’s okay. No one does.

But always remember: what you don’t know can kill you. Bring in an expert ASAP to do an analysis of your critical activities, identify weaknesses, and then, if necessary bring in an expert to address them. SI has been telling you for years consultants are cheap as the value a fair priced expert consultant will bring you is multiples of what that person will charge.

Next up: Avoiding the Graveyard if you are a Dead Company Walking! (Part 1 of 8)

What SHOULD Procurement Officials Learn from CrowdStrike?

A recent article over on on GovTech titled What Can Procurement Officials Learn from CrowdStrike caught my eye because I wondered if it contained the most important lesson.

The article, which sub-headlined on how CrowdStrike is a useful lesson for officials who draw up government IT contracts, pushing them to ask the question of how future contracts can prepare for any unplanned outages, hit on five important point(s) of modern SaaS / Cloud-powered technology.

  • additional safeguards are needed in IT contracts
  • even with safeguards, there is still the possibility of a cyberattack, so there must be an immediately actionable disaster response and recovery plan (which vendors must be able to live up to)
  • there should be alternate backup/failover options, even if non-preferred, and that can include paper in the worst case (as far as the doctor is concerned, it’s absurd when a store shuts down in broad daylight because they lost power or internet connectivity to the bank — that’s why we have cash and credit card imprint machines)
  • one should consider specifying liquidated damages up front, to prevent long drawn out lawsuits and delayed response time from the third party (who will want to avoid those damages)
  • consider cyber insurance, either on the vendor side or your side

Which is all good advice, but misses the most important point:

NEVER ALLOW A CRITICAL SYSTEM TO BE AUTOMATICALLY UPDATED (en masse)

Now, there’s a reason the military will exactly configure a system designed for single use and LOCK IT DOWN. That’s so it can’t accidentally go down from an unplanned / uncontrolled update when it’s needed most.

For example, there’s no way any update, no matter how minor, should be pushed out to a core airline operations terminal without an administrator monitoring the update (which could be on the vendor side IF the vendor maintains a [virtual] configuration that is the exact same as the customer’s configuration) and ensuring everything works perfectly after the update. And then the updates should be propogated to the rest of the terminals in a staged fashion. (Unless you’re dealing with a critical zero-day exploit that could expose financial or personal information, there’s no need for rapid updates; and even then, there should be techs on standby after that test update is complete just in case something goes wrong and a system has to be immediately rolled back or rebooted.)

Modern operating system installations, like Windows 11, can have up to 100,000,000 (that’s one hundreds million) lines of code and since you never know where the bugs are, there is no such thing as a low-risk update. Any update has the chance of taking down the OS or the application you are updating that is integrated with the OS.

But this is not the only critical lesson to takeaway. The next is:

For critical systems, your provider must maintain backup hot-swap redundant systems!

Once a configuration is confirmed to be bug-fee, it must be propagated to the backup, which must have a backup redundant data store with all transactions replicated in real-time (so that you’d never lose more than a minute or two of updates with an unexpected failure) that can be hot-swapped through a simple IP redirection should something catastrophic happen that takes down the entire primary system. This backup redundant system must have enough power to run all critical core operations (but not necessarily optional ones like reporting, or tasks that only need to be run every two weeks, like payroll, etc.) until the primary system can be brought back online. A catastrophic event like a rolling failure from a security or OS update or cyberattack should be recoverable in minutes simply by re-routing to the failover instance and rebooting all the local machines and/or restarting all the browser sessions.

Those are the lessons. If a system is so critical you cannot operate at all without it, you must have redundancy and a failover plan that can bring you back online with an hour, max.

You Admit You Might Be a Dumb Company. How do you avoid the fork in the road that leads to the Graveyard? Part 1

Good for you! Admitting you might be a dumb company is the most important thing to do on the yellow brick road to enlightenment.

So what do you do next? In short you:

  1. start by admitting to every mistake you are making and do something about it,
  2. look for opportunities to improve that are logical next steps, and
  3. never, ever forget the timeless basics.

Today, we’ll start with describing what you do when you identify, and admit to, one of the first five mistakes we chronicled in our re-introduction to our “dumb company” series and want to do something better. Next week, we’ll tackle the remainder of the mistakes before we move on to our eight-part series (each of which is worth much more than a piece of eight) on avoiding the graveyard if you are a dead company walking. After that, we’ll provide even more advice if you just want to be a smart company in two two-part series! In other words, SI has a lot of great helpful content lined up for you if you are a vendor that wants to successfully sail the choppy seas ahead (and not end up as another wreck on the ocean floor).

1) No More Perks

Unless you’re going crazy on perks, just leave them alone.

If a few are a bit crazy, reign them in to reasonable levels.

If they still eat up too much of your budget, find something else to cut. Start with the deadweight (and begin your search in the [micro] management suite). A useless or salary or two will go a long way to maintaining morale (and if you cut deadweight, morale will even lift).

2) No More Tech/SaaS

First, do a process time audit and figure out where your people are spending too much time on tasks that can be semi-automated to a significant extent.

Then, identify the appropriate solution to the problem and a set of potential SaaS tools to fill that solution affordably.

Then, Get SaaSy and do a SaaS audit, find the 33%+ overspend, cut it, and use that savings to get the SaaS your organization needs to be more productive and receive a return of at least $3 for every $1 spend on SaaS.

Finally, if your cloud costs are significant, Be Cloud Aware and do a cloud audit, tracking down what applications, or parts of your application, are chewing up the most CPU time. Then reign that in. Ongoing cloud costs add up faster than you realize!

3) NPD Can Wait (Sell What We Have)

Maybe heaven can wait, but hell waits for no man, and neither do the competition you don’t yet know about. No matter how good, or how bad, times are, your product must ALWAYS be improving. The minute you stop, the sales will stop as the customers will peg you as a dead company walking if you are not actively developing your product.

Segment all features into must, should and nice to have from a target customer perspective and make sure you are constantly working on the “must have” features, getting a decent number of the “should have” features that aren’t too time consuming to add into the plan, and prioritize any “nice to haves” that can swing a deal in your favour. If you have to slow down a bit because you can’t expand the team, that’s fine, just as long as you don’t stop.

Remember to keep dependencies in mind and structure development so that dependencies are always done first, to minimize release cycles.

4) No More Travel

Before you approve travel,

  1. first do an audit of all travel reasons the company has seen. Then,
  2. identify the direct and indirect ROI on past travel. Finally,
    • determine where in a marketing cycle travel actually results in actual, qualified leads
    • determine where in a sales cycle travel actually results in a selection or sale
    • determine which conferences/workshops/training events helped product management or developers

Then deny all travel that does not fall into one of those buckets.

Next, for travel that does, look at the cost vs. the projected return and how it compares to the most successful travel of the past. If a conference only results in 10 real leads, and it will cost 100K, but there’s another conference likely to result in 5 real leads that will only cost 25K, deny the first request and approve the second.

If $$$’s are tight, then restrict all travel to

  • small, focussed, cost-effective events that will generate actual leads or customer insights
  • on-sites likely to close the deal
  • low cost workshops where your product managers / developers will definitely improve their skills

5) Cut 10% Across the Board

Do a full budget review (keeping the dumb mistakes in mind) and cut the unnecessary expenses. They are MUCH higher than you think (because, when times are good, or you raise too much money, you don’t watch the small stuff and your unnecessary tail spend is just as bad as your clients).

Then, do a performance analysis (and blind peer review) of the teams across the department, especially the management teams, and cut the real deadweight.

Chances are, done right, there’s more than 10% that can be safely cut with no impact (whereas 10% across the board will damage morale to the point that the best talent might leave at a time they are the most critical).

Be sure to keep reading SI as Part 2 posts next week!

Want Procurement Technology Success? This is Your Anthem!

Show Don’t Tell by Rush

From now on, when you are contacted by a vendor, the first thing(s) you do is

  • refuse to listen to (or read) any marketing material, especially if they use any buzzwords (and, in fact, point out the minute they say one that you will hang up on them if they say it, or a prepared list of buzzwords you keep beside your phone, because it’s all Hogwash)
  • refuse to review any “case studies” until you see the solution in action, and even then refuse them unless they contain hard numbers based on standard metrics that you can compute yourself pre- and post-implementation (a client stating they saw “significant” savings is NOT a case study, it’s hearsay)
  • refuse their pre-recorded / scripted 30 minute intro demo until they tell you, in plain English, what problems their platform solves and why they think it will help you (and maybe even ensure the contract they will ask you to sign is also in plain English)

Once the vendor tells you:

  • what procurement problems and pain points their platform solves
  • how it does it (no techno-babble bullcr@p, plain English; no mention of AI, and definitely no mention of Gen-AI [which is bad for Procurement] because if it uses real ML then they can tell you what algorithms they use, and what confidence you can have based on what level of data is available)
  • and why the vendor is the right vendor to deliver the solution to you

Then you agree to a demo that covers the specific pain points you want addressed, provided that, if you like what you see, you can take it for a test drive. Nothing stops a true multi-tenant SaaS solution provider from spinning up a sandbox instance for you to play with, at zero cost, as it should literally be the flick of a switch (or letting you run one real sourcing event at a trial cost). The only significant charge should be if you want to see it in action on your data, in which case you should be prepared to pay a standard daily consulting rate to load your data (but, to be honest, you shouldn’t do this until you are sure the vendor is going to be the finalist, or the runner up, in your selection process as a final step, since a test drive on standard dummy data will illuminate most of the functionality supported).

You need to see a platform in action to understand if you can, and will, use it to solve your problems.

So, if it isn’t already, your new mantra for procurement software solution providers is Show Don’t Tell!