Introducing SolutionMap market personas — ranking solutions to fit company sizes and use cases
With the release of the Fall 2021 SolutionMap today, long-time readers and subscribers will notice a change in our presentation methodology.
In previous releases, our ranking graphics used buying personas — groupings of characteristics to summarize the needs of buyers (e.g., Nimble, Turn-Key, CIO-Friendly). In an effort to continuously improve the accessibility and clarity of our maps, however, we decided in this next iteration to move to more standardized market personas — groupings of characteristics to summarize the needs of many buyers in a specific market segment (e.g., SME, middle-market, large enterprise).
This article provides an overview of our rationale for this change and an explanation of how we constructed our new market personas.
What is SolutionMap?
To understand how we designed our market personas, we first need to establish the context in which they operate. That context is the rationale behind SolutionMap itself.
SolutionMap is a technology benchmarking system designed to align functional capability with specific tech-selection scenarios. The system creates outputs that provide guidance regarding which solution providers might be best aligned to a given set of buying requirements. Customer scores are also included via a separate axis to provide external balance and validation to our analysts’ ranking of technical capabilities.
We view this persona-driven system as an antidote to a “one-size-fits-all” approach for technology selection. Because the relationship between functionality scores, customer scores and buying requirements drive placement on the maps, we can configure weightings for these factors to represent unique buying scenarios, which result in more personalized, valuable recommendations to buying organizations via automated outputs.
The critical point here is that SolutionMap ranking graphics do not aim to produce a map of which vendors play in which markets, who is winning a greater share of business, or who has compelling future features or “vision.” If a vendor is up and to the right in our maps, that means the vendor is empirically aligned with the modeled scenario containing functional requirements (and deeper underlying technical platform requirements), and that its customer references also align with our assessment output. Users of SolutionMap can use the graphical rankings purely based on customer satisfaction (i.e., x-axis), or they can use it based on product evaluation from our analysts (i.e., y-axis), or a combination of both (i.e., “upper right” approach).
Why build SolutionMap?
So why build a “solution” map rather than a market map? At Spend Matters, we are, in essence, your external category managers to the market that sells solutions and services into procurement. Categories have both market-facing commercial attributes and customer-facing solution attributes. Our deeply held belief is that you need the solution perspective (based on product scoring and customer scoring) to begin a selection process.
The fact that a vendor has repeatedly won business within a certain group of customers shouldn’t be the only rationale for whether or not customers should specifically shortlist them. This tells you more about how strong their sales and marketing teams are, not whether they can deliver long-term satisfaction or, more specifically, deliver the technology that will meet your specific organizational needs and power your organizational process.
In our view, your shortlist decisions should be driven by:
- Sufficient or better functionality (i.e., your company’s specifications) for the module/suite in question …
- … that can fit your enterprise architecture (including other IT environments)
- … for the appropriate price range and geography in which you operate (e.g., it needs to support the languages and currencies you use, or handle any audit, clearance, tax or other compliance issues mandated by governments in target countries)
With SolutionMap, we help drive selections in this more logical and complete manner to de-bias selections and construct more relevant shortlists.
Critically, we designed SolutionMap to be used at the start of a tech-selection process, not the end. Rather than give you some bubbles on a map and say:
The players in this quadrant are the ones you should shortlist.
We instead designed our maps to say:
For the functionality and customer satisfaction requirements that we see these market personas prioritizing, these vendors would be the “best fit” candidates.
A better approach to tech selection
In designing SolutionMap, our goal was to give you a list of vendors that should meet all of your technical requirements. Not only because we know it’s a better way to approach tech selection, but because we’ve also seen time and time (and time) again over the years many companies inviting vendors to a shortlist with:
- Completely different solutions (because they used similar, confusing terminology in their marketing and communications that is impossible for an average buyer to differentiate)
- Inappropriate maturity — either not mature and sophisticated enough for the complex process requirements or organizational demands, or too mature and sophisticated for a small and immature procurement department
In the best case, the company would end up with only one good candidate (and have a very narrow view of the real options), and in the worst case, end up with a platform that couldn’t scale to meet their needs or that they couldn’t take advantage of for years, resulting in significant lost opportunities on top of higher software costs.
By designing an approach that provides you with a list of vendors in which you can be technically confident (often the hardest factor for most procurement organizations to judge), you can spend more time evaluating all of the “softer” factors that other firms focus on in market studies and narrow down the list based upon which vendor will work best “with” you. You can spend more time focusing on service and support philosophy, short-term roadmap and long-term vision, corporate culture and even market share during the evaluation process, using that insight to find a technologically appropriate vendor that “fits the best” versus a marketing vendor that “speaks the best.”
Elements of our market personas
Since your requirements as a buying organization are unique, they will never exactly match the templated market persona. And in all honesty, that is by design — the market persona is just a starting point for a selection process, rather than a shortcut for it. The personas signal to you that our base outputs are configurable to unique presentation and requirements, meaning you can create a unique map weighted to your specific buying requirements as part of a tech selection process with us, either at a high level using our TechMatchSM product or at a granular level through a custom persona TechMatch Concierge engagement.
What can you refine to your unique weighting needs? The SolutionMap market personas are configured using four overarching factors:
- Element relevance weighting. For each market persona, we set default weights that assess the relevance of all 500+ requirements to the given scenario. For example, in the category for Contract Lifecycle Management (CLM), our standard requirements for supplier portals are weighted lower than other maps, and in each market persona, even further weighting adjustments are given to provide slight relevance for large enterprises vs. near-zero relevance for the SME persona.
- Element maximum score. In addition to element relevance, we apply a maximum score in certain personas (e.g., for the SME persona, the maximum score used in calculation for some requirements is a 2 or 3, as there is no need for capabilities more advanced than market average). We use this as a proxy for the extent of functionality that a buying organization may care about relative to its maturity. If you are a mid-market organization on the beginning of a procurement transformation journey, you may not care about the ability to complete m-way matching beyond just invoices, purchase orders (POs) and goods receipts (GRs) to include contracts, advanced shipping notifications (ASNs) or advanced scenarios; you may just care about a 3-way match. So we limit the max score for m-way matching in that persona to the score on our scoring scale that accounts for a 3-way match and leave the higher scores for scenarios where they are valued.
- Customer response question weighting. We do not modify customer scores or construct them ourselves, instead using a survey-driven approach from which the analysts are fully excluded. We do, however, apply weightings to the 20+ questions in the references survey, so that we can emphasize the relevance of certain questions for certain market personas. (The intent is to reflect the similar process for element weighting described above.) For example, the SME persona generally has a higher weighting emphasis on pricing/affordability and TCO, whereas the large enterprise persona uses comparatively lower weighting on these questions that reflects a willingness to spend more for advanced capabilities. Note that we do not segment or weight specific customer types or overall scores differently; every customer is treated the same. We instead apply weightings to the individual questions, so that the differences portrayed in each market persona rely on the relevant factors, rather than give specific customers greater or lesser weight because of their characteristics.
- Modifier scores. There are three additional modifiers we use to construct the maps: price scores, geography scores and value beyond technology scores (VBT). Each is calculated using data provided by vendors, stemming directly from specific SolutionMap RFI elements or the customer survey.
- Price scores are determined by vendor-submitted pricing data and our own knowledge of pricing based as gathered from conversations in the market. We then tier vendors into pricing groups and apply a small score to each group. (In TechMatch, users apply pricing tiers via a filter.)
- Geo scores are determined by vendor-submitted customer data about regions where customers are based (i.e., we do not count subsidiaries, only companies headquartered in that region) and the presence of dedicated support in specific regions, as well as data gathered externally from resources such as LinkedIn, company/investment databases (e.g., Crunchbase), and company websites and press releases.
- VBT (value beyond technology) scores are determined using customer scoring data from specific customer survey questions that correlate to services questions and the value delivered from those services.
How our market personas drive vendor visibility on maps
It is essential to note that the market persona methodology places a vendor in all three personas by default. From there, we use the price score modifier as the sole driver for exclusion from the SME persona. Then, on all maps, the next exclusion criteria is whether the vendor places in the bottom left quadrant — that is, producing functionality and customer scores that are below the benchmark average for both score types.
In short, in our SolutionMaps, data drives the process to exclude a vendor. No analyst makes a determination whether or not to make a vendor visible on a map.
Our market personas, like any persona, are built based on assumptions to characterize them. The rationale is that a one-size-fits-all graphic is not enough, nor relevant. Each persona is a way to show sensitivity to certain elements in certain markets — such as certain types or levels of functionality, price or geographic footprint.
Not all large enterprises are looking for (nor are able to decide on/implement) global solutions for all of their users. Not all large enterprises want expensive solutions. Not all large enterprises want deep functional solutions. We (and they) know that “point” solutions and/or local decisions/initiatives are also sometimes needed. Therefore, the SME persona, as we characterize it, would also be the persona to use for a large enterprise looking for a solution in that context, not the enterprise one, the Large persona.
This is perhaps a confusing point, but we are increasingly seeing large organizations looking for “nimble” solution characteristics rather than bloated “feature 500” functionality packed in at the expense of product usability for stakeholders. In this case, the SME persona could apply to large enterprises, as a point solution (see below) — it’s about the context of the selection, which, as emphasized above, is the driving concept behind SolutionMap.
This, along with the collection of granular data on technological capability on standard, well-defined scoring scales, allows buying organizations to do apples-to-apples comparisons across vendors using their own high-level personas through our do-it-yourself TechMatch tool (i.e., a selection project conducted by a buying organization and/or a consulting organization that can license our deeper solution evaluation scores to create unmatched personalization in solution selection).
Introducing the new market personas
With all the reasoning and methodology behind SolutionMap market personas explored in detail above, let us outline them.
You may detect a correlation between the old and new personas (i.e., Nimble loosely corresponds to the new SME Persona), but the new market personas have been further refined. As mentioned above, in addition to considering core functionality data, market personas have been enriched to consider geographic reach, client base, price, implementation duration and available (support) services.
The following market personas are available for each SolutionMap technology category:
We hope these insights give you a better understanding of how the new SolutionMap market personas work and how they deliver value to end users making tech selections with SolutionMap. For additional questions about SolutionMap, please view our methodology, code of ethics and data sources pages.
Procurement’s Digital Transformation Goals Not in Sync with Development Priorities, Hackett Study Finds04/23/2019
Procurement’s Digital Transformation Goals Not in Sync with Development Priorities, Hackett Study Finds04/23/2019