Solution Provider Product and Technology Roadmaps: Are They Important?

The short answer to the question posed in the title is emphatically and definitively “yes” — now more than ever. When screening or evaluating technology solution providers for e-procurement, contract lifecycle management, vendor management systems (VMS) or any other solution, there is frequently an inherent present and backward-looking bias in evaluating and making decisions about these solutions. Considering only what solutions have done or are doing for their clients (and ex-clients) only tells so much about whether or not the solution is a good fit.

There are probably a number of reasons for this bias, including that it may have led to optimal decisions in the past because vendors often over-promised and only partially delivered. But in today’s world, this bias can handicap a procurement organization given the growing number of new solutions and rapid changes in technology. Whether intentional or not on the part of the solution provider, “adverse selection” may come into play here — to the detriment of all. By not knowing where a provider plans or intends to (or actually can) take its solution in the future, the buyer is missing crucial information that could result in a bad decision. Making sure that roadmaps are reviewed and analyzed is an important way to mitigate this risk.

In this Spend Matters PRO research brief, we explore this problem and make suggestions to support ways to move beyond it, including how to look at a provider’s product and technology maps from a 2017 cloud-era frame of reference. For those who are new to this topic, we start with the basics, providing an explanation of what vendor product and technology roadmaps are, what they should contain and what you should expect.

What Are Solution Provider Product and Technology Roadmaps?

Just about all technology providers — unless their solution is in a sunset phase — will continue to develop their solutions in response to currently unmet client and market requirements, as well as to pursue what the provider anticipates its current market will value in future years (which also helps signal the direction of the provider’s longer-term strategic focus).

For a solution provider, the business strategy, and, in turn, the product strategy (including a product vision) should envision the product’s future state and establish the goals and requirements for the product and technology roadmaps. This also should inform the development of the actual product, and technology roadmaps documents and how it is shared with customers and potential customers. If a provider doesn’t develop and share these roadmaps with existing customers (which you should find out about if you’re not yet an existing customer), that’s not a good sign. If those roadmaps don’t turn into planned product releases and those plans aren’t reliable (which you should also monitor), that’s also a warning sign.

We should note that although user functionality and enabling technology may be different solution aspects, they are interrelated and must both be considered tactically for promised new product functionality in the shorter term — but also directionally for the longer term. The chart below highlights the differences and intersection of product and technology roadmap components.

Product roadmap and technology roadmaps will influence one another and should, in the final version, align with one another. Ultimately, they are tactical plans that match short-term and long-term business goals with specific technology solutions to help meet those goals.

The roadmaps have three main functions:

• They link to the organization’s financial planning and budgeting (i.e., resource/investment allocations), and there should be alignment between the two.
• They represent the specific areas of functionality that the product is expected to work on and bring to completion.
• They provide clarity and purpose for the rest of the organization (particularly those in client-facing roles, like customer service and sales) to understand and work toward.

The usefulness and importance of product and technology roadmaps for the solution provider organizations should be clear. But, as we have suggested, they are also of critical importance to buyers who are evaluating new solutions (or even to current users evaluating their existing solutions).

Why a Mindset Shift is Needed

For decades, procurement technology solutions were the province of the large, multiproduct software providers or smaller, highly specialized vendors. Yet in the past few years, this has shifted dramatically, as new entrants enter the market and disruptive technology makes its way into the technology roadmaps of new and incumbent providers. New entrants are finding unique ways of penetrating into existing established market segments (e.g., by layering in content, analytics and knowledge into managed services offerings rather than just selling “empty apps”). Similarly, incumbent providers are developing solutions that are addressing entirely novel segments — and the end result is a greatly expanded (and expanding) landscape of solutions.

Some illustrations of these developments include:

• Uber and Lyft displacing the existing corporate car hire/rental car market and Airbnb beginning to do the same in hospitality while also integrating with T&E apps (e.g., Concur)
• WorkMarket defining a new solution segment for independent workforce (an adjacency to VMS) in the same way that SAP Ariba pioneered the supplier network area. Coupa entering the existing indirect spend e-procurement solution space and building out a broader invoice-to-pay offering (and the makings of a full procurement suite)
• SAP Ariba and Jaggaer expanding to direct procurement applications and connectivity
• Ivalua fleshing out a specific set of capabilities to support project management as an overlay to procurement activities (e.g., the management of a facility build out, plant overhaul or new product introduction)
• Solutions strategically platforming on the stack of a mega tech provider (e.g., Icertis or Ivalua on Microsoft)
• Beeline’s VMS platform expansion for Self-Sourcing
• Tradeshift’s development of its Ada bot or its acquisition of a text-based travel bot
• Brightfield Strategies’ development and introduction of Talent Data Exchange (TDX)

Furthermore, today there are not only more and different solutions/products to evaluate but new technologies also have emerged and proliferated at a faster rate than in the past — and this is a trend that shows no letting up in the foreseeable future.

One implication of this is that many new solutions are enabled by new and state-of-the-art technologies that both differentiate them from many existing solutions and put them on a different trajectory and a longer road ahead. At the same time, even some existing solutions have begun to incorporate new technologies into their established solutions or even have begun to update the technology architecture underlying the solution. Therefore, buying organizations should compare the roadmaps across vendors to help assess where there’s a good “vision match” on future product/technology strategy rather than just optimal matching to immediate functionality needs.

If we accept that times have changed — that is, new technologies are giving rise to new solutions (as discussed above), and the technologies are evolving faster than ever before (resulting in a kind of creative destruction) — then we have to accept that the approach to evaluation must put a much heavier emphasis on the future of the solution and the provider developing that solution.

That brings us back to product and technology roadmaps, which provide the visibility into the planned or expected future of the provider’s product (solution) and technology. Accordingly, thorough review and analysis of the product roadmaps becomes a crucial — even indispensable — part of the technology-enabled solution evaluation and decision-making process.

Recommendations

• If you have a solution your organization is using, ask to review the incumbent provider’s product and technology roadmaps. This will set a baseline for later comparisons with alternative solutions/providers, as well as inform your assessment of whether it is time to start looking for alternatives. Ask for as much detail as possible.
• If you are looking for and evaluating a new solution, be sure to incorporate product and technology roadmap review into the scope of your RFP.
• In reviewing and analyzing the roadmaps, you may want to have a savvy technologist come along for the ride to help to really understand the technology and how viable it is. One latent contingency/risk is tied to the maturity/immaturity of the technology, upon which depends the delivery of certain future product functionality.
• Ask to review requirements definition documents (where available) for nearer-term roadmap items.
• Naturally, your evaluation should involve matching your own requirements to the functionality promised in the product roadmap. For example, in the services procurement area, if it is critical for you to have an expanding set of end-to-end SOW management capabilities, make sure that is there. Conversely, if there is also a major focus (in your organization) on self-sourcing in the roadmap for services procurement, but relatively little on SOW, then that may be a red flag, too.
• Try to assess the balance in the roadmap between enhancing or expanding existing functionality or adding adjacent functionality and developing entirely technology-enabled features of new solution components (e.g., AI/analytics-based guided buying/supplier selection). Are you comfortable with the balance, or do you have concerns about the vendor’s ability to execute?
• This last question points to another crucial part of the analysis: ensuring that the roadmap is adequately and reliably funded and budgeted for. This is a tricky one, because often this is not the case. There may not be correspondence between what is laid out in the roadmap and the amount of funding committed. Sometimes the roadmap is aspirational, aiming at the product vision even while the provider organization is willing to accept falling short. A special case of this is in relatively new (e.g., Series B round) companies (of which there are and will be many in the landscape) where pivoting can still occur or investor funding can dry up. Alternatively, some organizations do not commit to funding budgets beyond a certain time period (say one fiscal year, or perhaps even less). So it is important to discern all of the above and not count your chickens before they hatch.

Naturally, all of the above assume that the solution provider has product and technology roadmaps.

In some cases, they may not, or they may be limited to a single slide or short PowerPoint (obviously a bad sign). Or the roadmaps may be superficial and vague — more window dressing than serious planning (also a red flag). Indeed, there is much to discern and analyze in product and technology roadmaps. For those doing evaluations, it can be a fresh and different way of thinking.

Conclusion

In this brief, we have argued that, in the evaluation of technology-enabled solutions, it is necessary to give a prominent place to the review and analysis of the solution provider’s product and technology roadmaps. We’ve spoken to reasons for this above and need not be repeat them here. Though making this shift is critical, it will be challenging in at least two respects:

• Established approaches to evaluation, in most cases, may allocate some attention to these roadmaps, but not to the extent or degree of the analysis suggested above. In the worst case, it is a complete blind spot. In both cases, the challenge is overcoming bias as well as bringing a significant review and analysis into the evaluation and selection process.
• Analyzing product and technology maps is, as suggested in the prior section, not a trivial exercise. It requires asking the right questions in a certain context. It requires assessment of the connections with business and product strategy, technology and resource availability and allocation. In short, it requires a new mindset, knowledge and skills.

Regardless, whatever challenges are involved in analyzing a company’s product future and how it aligns with your own current and emerging requirements, they are worth addressing head-on to avoid a single or collection of technology decisions that lead you down the wrong path with the wrong partner.