How to Minimize Vendor Lock-In as a Reluctant Product Manager

If you’ve become too dependent on your development team, you might end up being stuck with source code that can’t be maintained, let alone expanded. Vendor lock-in is best prevented at the beginning of a development project, but even when it’s already happened, there are still things you can do.

What does vendor lock-in look like?

Vendor lock-in is a big issue in software development, and all too often, it is an insiduous process. As a reluctant product manager, you might not be aware of the risk until a key developer or the whole team leaves, and you learn the hard way that essential knowledge about the system is lost.

At that point, you might find that the development team seems hesitant or even incapable of making changes. And even when they do, you might be confronted with bugs, as the development team doesn’t have a full understanding of the system.

What causes vendor lock-in?

The most common causes for this situation are:

How can vendor lock-in be prevented?

If you’re at the beginning of a development project, you are in a great position to put the right measures in place:

  1. Above all, ensure that at least the main workflows are documented and covered by functional tests. Ideally, you’ll want an executable specification, following the Specification by Example paradigm. This is a collaborative task for a business analyst and a senior developer.
  2. Have an independent QA person review all source code during the development process to see if it is well-organised and clearly written.
  3. Ask an independent software architect or senior developer to do a risk assessment on the choice of technology stack, so that you have a better understanding of the chances of it going out of date at some point.
  4. Make sure that technical knowledge is spread across teams and documented. For example by having an in-house software architect or developer work alongside an external development team.

How can vendor lock-in be mitigated later on?

The good news is that in most cases, you’ll still be able to get unstuck at a later stage. The bad news is that it will cost more money and take more time.

In any case, the first thing you need to do is getting an executable specification in place (again, Specification by Example is the preferred method here).

This is a tedious task, as you basically need to reverse-engineer the requirements of an application that has already been built — so it will feel like putting the cart before the horse. It is a necessary task however: tests will be your only way out of this predicament.

Once the tests are in place, you are in a much better situation, and you can:


As a product manager, you need to be aware of the risk of vendor lock-in, which is getting stuck with development and maintenance at a possibly very unfortunate time.

As is the case with so many problems, the cost of vendor lock-in goes up for every day that it is ignored!

Stay informed of new posts?

Sign up below and you will receive a weekly digest of new posts.

If you change your mind, you can unsubscribe at any time. You will not be spammed, and we will keep your email address private.

Article index