The MVP in corporate innovation – How to make it work

The Minimum Viable Product, MVP, is a well established concept in digital product development, especially within the startup scene. It has been adopted by the corporate world for quite some years now, and is recently being discussed widely as people seem to have picked up on the fact that corporations are failing badly at working with MVPs.

Many blame the concept of the MVP for this, saying that it doesn’t work for corporations. In my experience, working successfully with MVPs is hard whether you are a startup or a corporation. It requires a lot of discipline, but it is worth the effort because it forces you to innovate EFFICIENTLY. It is almost as hard for startups to work well with MVPs as for corporations, the only reason they are more successful with it is because they can’t afford not to, seeing as the alternative is wasting resources on building unnecessary things and moving forward more slowly than they could.

First things first, what is an MVP again?

A Minimum Viable Product, MVP, is a very early version of a product that is built for the sole purpose of testing risky assumptions, and validating key hypotheses. The main purpose of an MVP is learning. Learning about the users, their needs, the solution and what works and what doesn’t. By definition the MVP should contain only the bare minimum of functionality. The main reasons for this are:

1. Building less in order to test each assumption will save time and money.
2. Less functionality will better isolate whatever you are trying to test and make it easier to draw conclusions.

How can I make the Minimum Viable Product work in a corporate innovation setting?

Some things will be the same whether you are at an independent startup or in a corporate setting (read more on the general MVP process). Among those are:

• Identify what the key assumptions that you need to test are

• Figure out what the bare minimum is that you need to build in order to test those – This should be painful. Bare minimum means absolutely nothing else than what is strictly necessary.
• Put enough effort on designing the MVP interface so that early adopters will find it accceptable to use – note the keywords here: early adopters do not have high expectations on usability, they will accept a lot of friction if they get what you’re trying to do.

Working with MVPs in a corporate context, there are a few more things to keep in mind:

Avoid the snowball MVP

In my experience the key pitfall that makes it especially hard to work with MVPs in a corporate context is what I call the ‘snowball MVP’.

Normally the process of defining an MVP goes something like this:

You list the features you think are necessary for testing your key assumptions. It’s a decent sized snowball. Then you discuss with the team. Hopefully you have an experienced team member that has been through the MVP process before and questions a bunch of the features you have included. So you shave off some of the snow and end up with a nice snowball just big enough to fit in the palm of your hand. What tends to happen in corporations is that you take your MVP and you present that to a bunch of stakeholders that need to have a say in the process. The stakeholders are not at all used to working with MVPs and think Minimum Viable Product means ‘a version of the product that will impress our customers, make the competition envious and make us lots of money”. They are not onboard with the idea of releasing something just to test assumptions and learn. They get very nervous when they see how small your snowball is. ‘There is no way the customers will be impressed with that tiny snowball”. So they make you add more features before they dare to let you test it, and before you know it 6 months have passed and you are pushing around a snowball that comes up to your chest and keeps growing. An ‘MVP’ that has been built on for way too long, contains way too many features and has not yet been tested on a single customer. In other words, a huge waste of time and money.

How to avoid the snowball MVP?

Stakeholders will be key to your success as a corporate venture or innovation project in an established corporation, so keep them happy. But in order to keep your initiative moving efficiently you need to keep them out of detail decisions, such as which features should go in your MVP, or which target group you should go after first. Allow them to give input and advice but make sure you have mandate to make those decisions as long as you are working towards the overall goals, which these stakeholder have of course been part of defining.

Don’t drown in the sea of money

In a corporate setting you might not be as pressed for money as an independent startup would be. However, do not take this as a reason to lie back and think that makes it fine to be slower and less careful with managing your resources than an independent startup would. Doing so your initiative risks being closed down for not showing enough progress before you ever find product market fit.

Interested in learning more about digital product development?

3 common traps in digital product development (and how to avoid them)