Minimum Viable Product (MVP) for the enterprise
I recently led the development of a minimum viable product (MVP) in an enterprise environment. The objective was to prove the feasibility of serving end-users through a new digital channel, leading to reduced costs and higher customer satisfaction. The product was offered for a pilot group of users to measure the usage and engagement, so that we could extrapolate the benefits of a full product for a wider audience.
Building products in enterprise environments is challenging because there can be a lot of moving parts, stakeholders and conflicting priorities. It’s akin to trying to dance in an overcrowded dance floor without stepping on someone else’s shoes. Nevertheless, we were able to successfully deploy the MVP and measure outcomes that led to the customer wanting to move ahead with the full product. Here are some things to consider / take into account before and during the development of an MVP for the enterprise (in that order):
Build the business case
Start with the final objective of the product that you’re trying to build. What is the new product trying to achieve? Higher revenue? Lower cost? Faster go-to-market? Whatever the final desired outcome is, you need to build a business case that not only proves that the new product will be able to achieve it, but also demonstrates quantifiable measures to that effect. Needless to say, this will require collation of data from a variety of sources to build a model. When collecting data to build the business case, keep these points in mind:
- Cross-functional effort: Be ready to reach out across teams and functions in order to get data. In enterprise environments, data is almost always available, but you need to find the right team and contacts to help you.
- Maximum granularity: Prepare to drill down to the lowest level of detail when collecting data. This will help answer questions from the executive sponsors when presenting the business case. It will also help show the extent of due diligence performed in building the case.
- Educated assumptions: There may be some parameters in your model that you may have to assume, as data may not always be available. Even in such cases, make sure that there is a rational basis behind such assumptions instead of shooting in the dark.
Stakeholder buy-in
The next step is to socialize the business case with all possible stakeholders — both internal and external — with a specific focus on executive sponsors. The key is to build confidence in the product and its ability to achieve the desired outcome. One way to do this is to build a proof-of-concept (POC) that showcases the capabilities of the product. If this is not possible, detailed wireframes of how the final product will look and how it will integrate into the existing application landscape will be helpful. It will also help to have multiple versions of pitch decks to suit different groups of stakeholders. Executive sponsor presentations should be heavy on demonstrations, benefits and specific asks.
Pick easy-to-implement, independent features
When there is enough confidence in the product, it should be easy to get an MVP implementation started. For the MVP to be successful, select at least one use case that establishes an end-to-end workflow for the user. This will make sure that the MVP is easy to implement as well as independent of other functionalities of the final product.
In an enterprise environment, the list of features that should be chosen as part of the MVP is a function of dependencies on other teams / applications / interfaces. Make sure you connect with all upstream / downstream application teams to go over the required features and get them on board.
Pick representative sample of end-users
It may not always be possible (and not a very good idea) to release the MVP to the entire population of end-users. In such cases, try to conduct a study of end-user population to understand the demographics and distribution. This will enable you to choose a sample of end-users (the pilot group) appropriately. Keep these things in mind while choosing your pilot group:
- Based on the end-user distribution, pick your pilot group such that the sample is representative of the population
- Talk to the pilot group to make sure they understand the scope of the MVP. This will help set the expectations appropriately
- Choose end-users who are willing to commit time to test and give feedback
Identify stakeholders and their priorities
Stakeholder management can make or break your MVP. It is important to identify the right set of stakeholders who have not only the influence to help you remove showstoppers, but also the responsibility to keep moving forward. A majority of stakeholders may want to be informed (PMO, executive teams, operations, etc.) but there will be a few whose approval will be required (business, compliance, architecture, security, etc.) and thus, will need to be more closely involved.
It will help if you can develop a stakeholder RACI matrix, and socialize the same with everyone. Ensure that all stakeholders understand their roles in the development of the MVP, and communicate with them regularly so that they stay informed of the latest updates. Have separate meetings with every different group of stakeholder that you have identified — R, A, C and I.
Release management
Enterprise environments often have a rigorous release management process owing to the large number of projects executing in parallel. When planning the sprints for your MVP, make sure you take into account all the tasks to be performed to align your product ship dates to the existing release dates. This will make sure that the release management team is aware of your project and can accommodate your changes into their schedule. You should have at least one person on your team who is well aware of all the processes to be followed in the existing environment.
An alternative, if possible, is to obtain a waiver for your MVP to be able to ship independent of the existing release management process. This approach probably will not win you many friends, but if you are able to get the backing to accomplish it, the flexibility and the iteration speed it lends is well worth the trouble.
Data collection
This is probably the most important part of building your MVP. It is important to collect as much information as possible about each point of end-user engagement with your product, especially when you are building an MVP. This is because the data you collect during this stage will be the building block for extrapolating to a larger scale when the final product is built for the general population of end-users. Make sure you are focused on data as much as you are on user experience.
After going live with the MVP, use the data collected to build a dashboard (preferably interactive, using Tableau, PowerBI, etc.) showing engagement and how it leads to the desired outcomes. Use the same parameters from your business case to show whether the extrapolated numbers for the final product match up to what you pitched. If they are reasonably close, you should have no problems in getting the go-ahead for the final product.
