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.

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.