Monthly Archives: August 2023

Ten Best Practices for (Software) Vendors, Part 3

In Part 1 we noted that, just like buyers, you need help. Then, in Part 2, we made it clear that in order for you to understand you need help, you need to understand where you might need that help, and that’s why we are doing this series for your benefit and going deep.

So, just like we wrote on the Five Best Practices for Buyers, which built off of our articles on five easy mistakes source to pay tech buyers can avoid and even a critical sixth mistake most tech buyers make in source to pay (who need to realize that No Tech Should Be Forever), we are giving you the ten best practices that address the ten most common challenges we see that you should be aware of, and some advice on how to address them.

In our first two articles we gave you the first seven:

  1. Identify the Market Sector You Are Competing In
    … and the Niche Your Solution is Targeting
  2. Do Your Market Research
  3. Define Your Target Industries
  4. Identify the Core Pain Points Your Solution Will Address in the First Release
  5. Understand the Data Needs and Design the Full Data Model
  6. Understand the Current Customer Processes and Typical Restrictions
  7. Don’t Overlook the UX (User Experience)

which revolved around market research and technology. Today we give you the next three, which revolve around the marketing (and sales) of the product.

#8 Get the Messaging Right

Not cool messaging, not current hotness messaging, not buzzword messaging, but meaningful messaging that gets the right points across. What it does, how it addresses the customer problems, how it improves the customer situation, and how it will deliver a return on investment in the short and long term.

This is easier said than done, because the messaging still has to be attractive, easy to consume, comprehensible by your target audience, and to the point. It’s a tough balance, made harder by the fact that if you don’t understand the industry, the terminology, the current technology, the competition, or what the audience is looking for, you’ll never get it right.

#9 Price It Right

This is very hard. Price on ROI? That’s different by company. Price by competition? If it’s truly different, it’s not comparable one-to-one. Price by current market size average SaaS spending? That could price you out of the market or price you out of business. It’s the optimal balance between value, customer budget, and all-in costs to the company (development, implementation, support, etc.), and that’s not easy, but it has to be understood to ensure the majority of the intended market can afford it and do so by the next budget cycle, that the pricing doesn’t sell the solution short, and most importantly, that the sale price doesn’t put the company in financial jeopardy.

#10 Get Advice AND Listen to It

Analysts and Industry Experts are your friends, at least if you listen to them and ask good questions and listen when they are able to give you advice (and listen even closer when they say they are not the expert in that area and redirect you to the those who can, as the best analysts and experts not only know their areas of strength, but their areas of weakness and will send you to the right analyst or expert when you have a challenge outside of their core areas).

There are a number of things you need to understand, especially if you are a new founder or CEO:

i) They are much more informed than you on the market, assuming you are talking to a senior analyst or long-time industry expert. Maybe you’ve seen a few solutions and heard customer opinions on a few more, and hearsay customer opinions on a few more than that, but most analysts have seen dozens of solutions in any particular area and have deep understanding of what those solutions do, what the target markets are looking for, and the average technical proficiency of those markets. You don’t have that. (And if you think you have a great solution because Ariba and Coupa doesn’t do something, you are drastically underprepared to tackle the market on your own.)

ii) They have seen the majority of the messaging and sales approaches and have seen what works and what doesn’t. Your CMO might have been the Marketing Guru in their last job, but if that last job was in a different area of tech, or even a different area of Source-to-Pay/Supply Chain, their knowledge and experience doesn’t necessarily translate. Going back to our point about market maturity, and risk-aversion, an experienced industry analyst has a lot more insight into what’s worked and what hasn’t and is the person your CMO needs to learn this new industry/market and how to use their skills to be the next Guru in your market.

iii) They are aware of the market research and expertise that exists that you can take advantage of. You don’t need to guess, and you definitely don’t need to double down on your start-up assumptions and proclaim them as inescapable truths, which, as experts know, likely only holds true in a vacuum (and could be completely false for the majority of your target market).

Plus, as we indicated above, the best analysts know their areas of strengths and their areas of (relative) weaknesses and when they can advise you well and when to pass you off to a colleague, even if at another firm. (If the doctor doesn’t know, or isn’t in the best position to advise you, he’ll happily pass you off to one of the dozens of active analysts and industry experts he trusts to advise you appropriately, which includes the analysts he publicly listed in his analyst recommendation post.)

Is this everything you need to do? Or even know? No, but it’s a great start and when you get these practices down, you will be in far better shape than your competition and not make the same mistakes us long time analysts and consultants see over, and over, and over again. We see far too many companies take two steps back for every step forward during their formative years, and it just doesn’t need to be that way. Especially if they are bringing a better solution to (a subset of) the market.

Ten Best Practices for (Software) Vendors, Part 2

In Part 1 we noted that, just like buyers, you need help. And what we left unsaid is that most analysts, bloggers, and self proclaimed experts aren’t giving you the help you need. Which, to be fair, they shouldn’t, because it’s worth money and they need to make a living too. However, they should at least be giving you the insight you need to understand where you need help and how they could help you, because they shouldn’t expect you to hire them on their word alone that they are good. You should have something to judge that as well as whether or not their expertise is in the area you need it.

So, just like we outlined Five Best Practices for Buyers, which built off of our articles on five easy mistakes source to pay tech buyers can avoid and even a critical sixth mistake most tech buyers make in source to pay (who need to realize that No Tech Should Be Forever), we are giving you the best practices you, as a Source-to-Pay/Supply Chain Front End vendor, need to understand to be successful.

Yesterday we gave you the first three:

  1. Identify the Market Sector You Are Competing In
    … and the Niche Your Solution is Targeting
  2. Do Your Market Research
  3. Define Your Target Industries

which revolved around market research. Today we give you the next four, which revolve around the technology solution.

#4 Identify the Core Pain Points Your Solution Will Address in the First Release

Once you understand the market sector and niche you are competing in, and the problems potential customers are having, you need to identify the subset of pain points you are going to address. (And stick to them until you have a solution that minimally addresses them. Flip-flopping will not only waste time and money, but distract you away from a core you will still need to build.) This may mean tweaking your definition of the “problem” slightly to moderately and changing the product design and roadmap you drafted when you started, but it costs a lot less to do it before you start development than when you are halfway through a development cycle and realize the focus was wrong. Moreover, targeting the core pain points you identified ensures you have a solution that not only solves a real problem but also gives you access to a market that is not already over-crowded with existing solutions that would directly compete against yours.

Make sure to validate that the pain points are common to multiple customers, and not just the companies the founders came from or your alpha partners and beta customers. Remember that your alpha partners and beta customers are either the leaders and innovators in the top 10% of the market (and way ahead of their peers in operations, supply chain, processes, and/or technology utilization and readiness) or the up-and-comers willing to take risks on innovative new tech to catch up to the market leaders. They are ahead of their peers in functional capability and/or willingness to take a risk, and it could be years before the rest of the market catches up. You want to be building something that a majority of the market is ready for once you prove the solution and your resiliency as a company, not something that will limit you to a very small group of industry leaders and/or risk takers.

#5 Understand the Data Needs and Design the Full Data Model

Before you code a single line, go back to your market research and look at all of the data your competitors are collecting, the data the customers are looking to keep track of, and the data that is available in the systems you will (likely) integrate with. What you have to remember is that, when it comes to software, just like the architecture you start with determines what you can build feature and function wise, once you start with a data model and your developers start coding to that model, extending it can be exceedingly difficult later. So start with the right data model. (Then do the architectural core, which should support not only all of the initial functions but those functions identified as potential future improvements based upon secondary pain points or common competitive functionality. Just like a foundation for a two story house will only ever support a two story house, you need to build the foundation for a high-rise if that’s what you want to build, even if you are only building one floor at a time.)

#6 Understand the Current Customer Processes and Typical Restrictions

If you don’t understand what you are trying to automate, what processes your target customers are comfortable with, what restrictions they have to work within, and don’t design your technology to work within the processes and restrictions, it won’t matter how great your tech is because it won’t be adopted. Unadopted technology is even worse than unsold technology — unsold technology can be spun as “just coming out of development“, unadopted technology means you don’t have happy customers using it, which gets interpreted as “it doesn’t do what it was intended to do“, and that will really hold you back.

#7 Don’t Overlook the UX (User Experience)

You could have the best tech ever, but if it’s

  1. not an attractive technology that looks easy to use,
  2. not a technology that is actually easy to use, and
  3. not one that fits within their process mindset, then it won’t get adopted and used by the intended customers. And we’ve already indicated that non-adoption is worse than a lack of sales.

Come back tomorrow for Part 3 where we will conclude our deep dive into ten best practices.

Ten Best Practices for (Software) Vendors, Part 1

In a recent article, we gave you Five Best Practices for Buyers, which built off of our articles on five easy mistakes source to pay tech buyers can avoid and even a critical sixth mistake most tech buyers make in source to pay (who need to realize that No Tech Should Be Forever).

But it’s not only the buyers who need help. You vendors do too, even if you won’t (publicly) admit it.

(We’ll just say this. If you didn’t need any help, a lot of you would be doing better than you are. the doctor has seen, and sees almost weekly, vendors with great tech who never get beyond the 1M to 5M mark because they didn’t understand either what the market needed or how to sell the great product they have, vendors with great service get lost in the marketing noise made by bigger peers, and vendors with inferior tech but better focus get ahead quickly with the right messaging and a partial solution but then stall out when new competitors with better solutions hit the market, and so on. Each of these vendors have, or at least had, the potential to be bigger and better if they just understood where they were weak, focussed on the right issues, extended the platform appropriately, and, if necessary, obtained the appropriate help.)

Just like you need a great mix of talent, transition, and technology to build a great company, you need a great mix of problem targeting, customer focus, solution capability, process fit, and affordability to build up your market share. But we’re getting ahead of ourselves here. Let’s step back and go through the best practices you need to get the right orientation.

#1 Identify the Market Sector You Are Competing In
… and the Niche Your Solution is Targeting

As an analyst and due diligence professional the doctor doesn’t want to tell you how many times he heard the company was started because “product XYZ didn’t solve problem BIGGIE we were having“, and neither did it’s main competitors that we identified in a Google search, when it was often the case the product they were expecting to solve problem BIGGIE was never designed or intended to solve that problem. For example, during COVID, online collaboration and payment portals became the craze, and many I2P/AP/Payment solutions came into the limelight. Looking into these closely, it didn’t take long for some us to find out that many of these were started because bill.com or Quickbooks or another e-billing (management) platform didn’t solve the invoicing or accounts payable problems they were having. They searched for bill management, invoice management, etc. and found cheap online small business solutions, and didn’t research a single, true, accounts payable (AP) or invoice to pay (I2P) solution among the dozens out there and then wondered why they didn’t stand out in the AP/I2P/e-Payment market when they tried to sell their platform, raise money, or get acquired by Private Equity or a bigger company (at a high multiple).

What’s important to understand here is that you need to understand the broader space you are playing in, the terminology that is typically used, the standard solution categories that are out there, and the baseline capabilities that are expected/present in the majority of solutions in each solution category/niche. Talk with peers, use your local professional organizations, use free analyst firm and independent authority resources, and get the terminology down. For example, purchasing, procurement, and sourcing have well accepted meanings in the analyst world, with detailed outlines of what those categories should contain and associated vendor lists, but if you don’t understand that, you might not realize that your definition of these terms is completely different than the majority of the space, leading you to research the wrong vendors and believe certain capabilities aren’t out there when actually solutions with those capabilities are actually quite common. For example, let’s say your old company used “purchasing” for tactical catalog buying and “procurement” for strategic buying, and you researched procurement vendors when starting your company to create a new solution for strategic buying. Since you didn’t research strategic sourcing vendors, you might come to the conclusion that most of the existing RFP options were shallow and your idea to inject more analytics and basic optimization inline is industry changing and enough for an MVP, only to find out 18 months later you have a dozen competitors who are two years ahead of you and you can’t break into the larger mid-market because all your potential customers can find 3 to 5 more mature vendors for their short-list (and many buyers, who are risk averse, think start-ups are risky and will avoid them if there are other options, especially when that’s the mandate from IT or the C-Suite).

#2 Do Your Market Research

Once you understand the market you are playing in, the top players in that market as well as the up-and-comers, and those that play in the niche where your solution best fits, do competitive research and understand what the subset of vendors you will be competing against offer. What core capabilities do they provide? What do they do well? What do they do poorly? And, most importantly, what pain points are they not hitting, or not hitting in a way that works for the markets you are going after?

Then acquire the right customer-oriented market research in the market sector and niche that you are targeting. Specifically, market-research that focusses on the problems the customers want the solutions to solve and the capabilities they are looking for. Augment this with the competitor and customer research you’ve already done to identify whether or not your hypothesis that the “problem” you identified when you started the company is

  1. a real problem experienced across a large number of customers in one-or-more industries and
  2. not solved, or not solved in a good way, by the majority of solutions out there.

If the answer is “no”, even if you have a good solution, you don’t have a very marketable solution, no matter how great your technology is. A marketable solution is one needed by the market that is sufficiently differentiated in a way that allows you to easily sell it to grow your business, and, if necessary, attract then investment needed to help you expand the product functionality, the target market, and the business overall. Do NOT skip this step, or you will waste a lot of time and money (which will typically be in the man years and millions of dollars) to learn something you could have learned for well under 100K.

#3 Define Your Target Industries

While many problems / solution needs are common across industries in general, when you get down into the specifics, the processes and solution capabilities can often be quite different across industries. Think sourcing. If you are sourcing finished goods, any indirect sourcing solution does the trick. If you are sourcing raw materials and parts for manufacturing, then you need a direct sourcing solution that supports bills of materials and deep product and material specifications.

For just about any solution category you can define in Source to Pay, you will find that the needs across different subsets of industries will be different enough that you will not be able to build a one-size fits all solution. So focus in early, so you can build something suitable and attractive to that industry subset. Remember that many industries are so big that you can build a decently sized company just focussing on one core industry at first (and if you get it right, much more than the 1M to 5M range where most startups get stuck).

Come back tomorrow for Part 2 where we will continue our deep dive into ten best practices.

X

… Logged into Twitter just the other day
Just saw a Big X, seems the bird had flown away
It had two lines and one was double wide
I knew the letter, but I just could not surmise
… Musk didn’t leave a number, not an picture or a clue
But something in that pictogram reminded me of coup

Baby, Musk put the X on top
Voided years of trust and it makes me wanna stop
Baby, Musk put the X on top
Twitter’s going bye-bye, baby, ’cause the branding’s gonna flop

… I saw a sign in the middle of the night
Big flashing X, I was blinded by the light
She said “Oh yeah, you don’t want to be here
I asked who was calling, but she just hung up in fear
… Sometimes you gotta suffer for the network that you seek
You’re beggin’ for connection but you only want to shriek

Baby, Musk put the X on top
Voided years of trust and it makes me wanna stop
Baby, Musk put the X on top
He thinks he is a master, but he just can’t compare to Aesop
… Oh yeah

I heard an app a-beepin’ so I clicked into the pane
It showed icons, pics, emojis, it’s like it was built to feign
It said that it was “happening“, but it didn’t give a clue
Then I saw that white on black X and I knew that we were screwed!

Baby, Musk put the X on top
Words have been displaced and our IQ’s* gonna drop
Baby, Musk put the X on top
A digital nightmare, it’s the new-age online horror shop!

… with sincere apologies to KISS.

* It’s Official! Twitter Has Made Us Dumber Than Goldfish!
Who’s Smarter? A Twitterer or a Pothead?
Has Twitter Already Turned Too Many Into Twits
Twitter Will Make a Twit Out Of You!

That’s Right, You Do NOT need AI for Automation!

In our last article, we stated that our space was full of Overpriced “AI” you don’t need in source-to-pay, and one of our three examples was “Sourcing Automation” in Sourcing. To be clear, we’re not saying you don’t need automation — the whole point of software has always been efficiency through automation — we’re saying you don’t need “AI” automation.

The reason we’re doubling down into this topic is that we know there are a number of vendors pushing AI Automation and while automation is very good, AI is just not needed. But we know you’re going to get pushback if you echo the doctor‘s viewpoint here, so we’re going to double down into the details and explain why no AI is needed for great automation.

In our last post, we noted that, at its simplest, it’s the ability to auto-source a (set of) product(s) or service(s) once the need has been identified or the request approved. It’s useful, but you don’t need AI to accomplish this, just good-old rule-based (workflow) automation. After all, it’s just

  1. instantiating a new RFP (which can be done if you have a template tied to the product/service types)
  2. distributing it to known, approved suppliers (which is easily done if you have supplier management that tracks approval status and associated products/services)
  3. collecting the bids (automated submission management through a portal or provided spreadsheet for upload)
  4. selecting the lowest bids and marking it as an approved award (simple analytics)
  5. assembling the contracts (with templates, it’s just sucking in the supplier details, product details, and bids using tag-based search and replace)
  6. push it into the e-Signature portal (via the API)
  7. alert the buyer when the contract is ready for signature (via alerting)

1 You just need templates, and good providers have had those for a long time. And “AI” is not going to invent one you can trust.*1 It’s not too hard to tag your (provider’s) existing templates to all of the products and services you buy, and you only have to do it once.

2 When you onboard a supplier, you should tag it as approved, associate it with the products and services it is approved for, look up its risk and environmental scores, and track its performance over time. If it’s performance drops, it can automatically be suspended from consideration for new projects using old-fashioned business rules that will prevent it from being included in events it shouldn’t be. Thus, approved supplier management isn’t that hard to do and simple saved searches find all the suppliers that should be automatically invited to an event.

3 RFP and e-Auction software has been around for 25 years, so don’t let anyone ever tell you that you need AI.

4 If you’re trying to administer an award subject to constraints or goals, that’s good old fashioned strategic sourcing decision optimization. That’s not AI. MILP using classic tableau and interior point algorithms works just fine in predefined scenarios that suck in the organizational constraints … that leading SSDO (Strategic Sourcing Decision Optimization) providers were building over two decades ago.

5 Contract templates should be prescribed by Legal Counsel, not by software flipping random bits using layered statistical algorithms in combinations no one truly understands. The vendor will provide you with templates, but you should be the one reviewing them to make sure they are too your liking. This includes the standard clauses and variation by geography, industry, or risk you want to address.

6 Software integration happened for decades before AI.

7 Alerts have been standard software capability for decades, no AI needed.

If the right data is captured, and the right rules are written, standard workflow-driven software systems can be fully automated without any AI. The only thing preventing them from going from one step to the next is the human verification checkbox being completed. You can turn that off and they will work just fine. So, again, don’t be fooled that you need AI for Sourcing Automation, because you don’t. And with rules-based systems, you’re guaranteed you won’t get the odd, unpredictable result, every 10th sourcing project (because AI is only statistically effective, which means, eventually, it will always fail).

*1 Sure “Generative AI” can generate one. But there’s no guarantee it won’t be hot garbage.