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:
- Identify the Market Sector You Are Competing In
… and the Niche Your Solution is Targeting - Do Your Market Research
- 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
- not an attractive technology that looks easy to use,
- not a technology that is actually easy to use, and
- 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.