Technology Vendor Risk — Check the Product Strategy and Roadmap
6 min read

Technology Vendor Risk — Check the Product Strategy and Roadmap

Every company today most likely has vendors in their technology landscape. There are ways and parameters that technology teams use to…
Technology Vendor Risk — Check the Product Strategy and Roadmap
Photo by Scott Graham / Unsplash

Every company today most likely has vendors in their technology landscape. There are ways and parameters that technology teams use to assess risk while selecting vendors. In this post, I am going to talk about one such risk to consider while selecting a (software or SaaS) vendor — the product strategy and roadmap.

Why is the product strategy important?

It’s important that the vendors you are evaluating satisfy your requirements. Their current features should meet all your current business requirements. And while you are at it, perhaps also consider that the current features product can also satisfy your short term to mid term requirements. And of course the vendor should provide all that while offering the service at a low or acceptable cost.

But what about the long term? Can they be a long-term partner for your business? You must explore the answer to this question. There can be many parameters relevant to your business that could help you find the answer to this question, one important parameter is the product strategy.

The product strategy can help you understand a few things — what kind of customers is your vendor going after and will prioritize in the future and if you fit in that plan, what kind of needs are they trying to solve, what kind of geographical markets are they trying to be prominent in and if they will ever cover regulatory needs of your region, etc. The most important thing that it will reveal for you is that if you are a type of company that the vendor is looking to make money from. If not, the relevance of features and pricing of the service for your company will reduce with time.

So knowing where your vendor is trying to go as a business and hence as a product is important for you to evaluate if the vendor can continue to be relevant for you.

What is the best way to understand this:

  • Mostly product teams or founders (for relatively new vendors) of this vendor will be able to share with you. Sales teams might not have this information or might not be able to communicate this well. So being able to get some time with product team or the founders directly might be the best way to understand what the long term goal is and which kind of customers or markets are important for the vendor. Some established vendors might not be open to letting you speak with their product team directly. This should be possible depending on size of your commercial agreement or if the vendor is a new kid on the block.
  • How much the vendor shares with you will depend on how important you are going to be for them as a customer. This does not just mean dollar value. It can also be that the vendor wants to get you onboard as a strategically important customer that they might want to advertise to get in a segment of market. May be try to establish that with the vendor as to how the vendor can benefit from having your company as a customer.

Why is the product roadmap important?

It is also important that the vendor keeps shipping relevant features continuously so that the vendor can support your company’s short term and evolving needs.

If there is a time or business critical that you want the service to solve for you, getting the vendor to agree to delivering those features timely is a good starting point. To really protect your interest, try to get these commitments factored into the agreement before signing the contract. Having some kind of legal commitment can safeguard your interests.

What if the service provided by the vendor is not business critical? You will really have to assess the criticality of the vendor and what it does for you and decide accordingly how diligently you need to understand the vendor. But even if the vendor is not providing any critical service, generally being inquisitive about the features that they are planning to ship in the next couple of months or quarters can expose interesting things about your vendor and how it can assist or be detrimental to the business problem you are trying to solve with this vendor.

What is the best way to understand this:

  • Asking the sales team might not be enough. Sales teams are infamous for making commitments without checking with their product teams. So again, try talking to the product team about what kind of features they plan to release in the next few months and quarters. Again, how much information you can get depends on how important you are for the vendor.
  • If you are not able to get the time with the product team, get something in written (even email is fine but of course legal agreements may be the best, although relatively hard, option) from the sales team so that you can hold them accountable in the future and even escalate to the vendor’s management if commitments are not met.

Importance of frequency of releases

Every vendor will have their own process for releasing features to customers. Some might not have a defined process for releases. It might be okay if they don’t have a defined process. What is important if they constantly ship features. A defined process, like bi-weekly, monthly or half-yearly release cadence, guarantees the vendor will be always be shipping something and how to factor that schedule in your company’s roadmap.

In absence of significant features being shipped regularly, the product would get stagnant and might not be a good partner for your evolving business.

What is the best way to understand this:

  • SaaS products typically have a mechanism for announcing new features. Look that up and see their past releases. Were they frequent enough? Were they significant features solving the core use-case or insignificant features targeted at a set of customers unlike you?
  • If the vendor does not have a way of communicating what’s new in their product, I’d be concerned at this point. This could be okay for a startup. You can have them make up for this by setting up some kind of recurring office hours until they come up with a more streamlined way to inform you and your team about product updates.
  • Ask the vendor’s sales or product team about their release cadence what were the past few releases like. Sales teams should be typically able to put something like this together if you ask them.

Retrospecting on real-world experiences

I have had first hand experience of being bitten by this because we overlooked the importance of product strategy and roadmap. I’ll try to share some of those incidents (without naming names) to try to paint a real picture:

  1. At my current employer, we decided to switch our vendor for Process X from Vendor A to Vendor B because Vendor B had all the features that we needed for our process’ requirements today while Vendor A had some important features missing. Vendor B was also cheaper. What we didn’t factor in was Vendor A had certain features that we would have found ourselves using 6–9 months in the future. These features were missing in Vendor B. Also, Vendor B got recently acquired and stopped shipping significant features. They didn’t ship anything useful for almost one and a half years, stagnating maturity of process and leaving us in the middle of nowhere. In retrospect, staying with Vendor A would have been better even when a couple of features were missing because those features were eventually added in Vendor A.
  2. Another instance at my current employer was with a vendor that would help us monitor uptime of different applications. We onboarded this vendor many years back and it was extremely relevant then. But the monitoring space has evolved so much over the years (think synthetic monitoring, SLOs, real-user monitoring, etc.). Not knowing where the vendor is heading and what they are going to be building in the long term left us with this vendor that would not be able to help us evolve with time. The vendor kept making UX improvements without really being able to solve for more complicated monitoring requirements. That might be fine for the vision of the vendor and what they want to do with their business. But for us, this vendor was not a good long term partner. Thankfully we had used this vendor in limited places so swapping out was easy and that’s what we eventually did. However selecting vendors and onboarding them is also a time taking process, no matter how easy it is and you might not want to do that over and over again for the same problem.

How do you de-risk technology and vendor decisions in your company? I’m curious to learn about this and happy to share about my experiences about specific risks that you are curious to learn about.