For a long time, the idea of a minimum viable product (MVP) was the preserve of the startup world. That’s hardly surprising, given that its origins lie in Eric Ries’ book The Lean Startup. Increasingly, however, corporates are looking to adopt aspects of the Lean Startup Methodology, including the MVP.
Of course, given the differences between startups and corporates, it’s not possible to simply transfer the concepts from one to the other. Every aspect of the Lean Startup Methodology, including the MVP, has to be adapted for the corporate world.
More importantly, we always need to be clear on what the learning goal is. After all, the MVP is a vehicle (artifact) to validate (or invalidate) a hypothesis. At innoway, we use a template from one of our partners Kromatic. You can download it here.
Here are some of the biggest differences between the two:
Urgency
In the startup world, getting an MVP out as fast as possible is crucial. Startups only have a certain amount of runway before they need to bring in revenue or attract new investment. That’s part of the reason it’s important to get something out to market even if it doesn’t have all the features you might eventually want.
Figuring out what works and doesn’t work in a product in the fastest amount of time, means the minimum amount of runway goes to waste.
By contrast, most corporates aren’t dependent on any new products they’re trying to put out to market.
On the one hand, that may relieve some of the pressure to get a product out to market. On the other, it means the team behind the product has to work harder to ensure it doesn’t keep getting pushed down the priority list.
The organisation’s “immune system”
Another major difference between startup and corporate MVPs is that there are generally much fewer internal obstacles involved in getting the former out to market. After all, some startups might get an MVP out while the founder is the sole employee.
In the corporate space, the team in charge of the building the MVP has to navigate the complexities of corporate blockers. These blockers are the “immune system” of the organization, as Eric Ries puts it, and their role is extremely important, which is protecting the assets of the organization. Learning how to work with them, engaging them in the creative process of designing the experiment is critical.
Ideally, the higher-ups within the organisation should try and keep blockers to a minimum but in any sizable organisation that’s going to be difficult to achieve.
Any team trying to launch an MVP in such an environment should, therefore, factor it into their plans.
Testing
One of the most important parts of the MVP process is testing, both internal and external.
The former can be a lot easier at a corporate, simply by dint of the fact that there are a lot more bodies to do the testing. That said, it’s also a lot more people to keep an eye on to ensure that the version you’re testing internally doesn’t leak to the wider public.
When it comes to external testing, however, things can be a lot tougher for a corporate. After all, every new product a corporate organisation launches will be judged against its previous, complete products. Here, it’s important to ensure teams are given a “sandbox”, or a safe place where new concepts can be tested without “breaking the assets”.
By contrast, people are much more likely to forgive the odd glitch when they try out a startup’s MVP.
Any corporate team putting out an MVP, therefore, needs to find out how to test these new concepts quickly without affecting the corporation.
Resources
That said, if an MVP receives generally positive feedback, a corporate can (in most cases) put a lot more resources behind it.
This affects everything from marketing budgets to the ability to scale the team as the product is pushed out to a wider market.
Corporates may not be anywhere near as nimble as startups, but here they have a major advantage.
The principles remain the same
There are very clear differences between putting out MVPs in the corporate and startup spaces. It is, however, important to remember that one is merely an adaptation of the other, not a complete reworking.
The principles of the MVP remain the same in both cases: start with the learning objective, define a falsifiable hypothesis, and design an MVP (product or service) with just enough features to satisfy early customers and to provide feedback for later iterations.
