What Kind of MVP Do You Want?
Minimum Viable Product (MVP) is a term thrown around in most product development guides as a way to isolate what is key to your product and keep you and your team focused on building what is essential. Building your product, especially in its initial phases, is often a difficult process and can be filled with miscommunications and headaches. While there are many points of contention in building a software product, the biggest point of failure in my experience is a lack of understanding and/or agreement surrounding the business purpose of the MVP.
While the process of defining an MVP typically centers around discussing features or user stories, not enough time is spent agreeing on (and communicating with your team) the purpose of the MVP and subsequently what type of effort they are about to undertake - leading to unmet expectations, hidden requirements, and frustration for both product managers and developers.
The first version of your product shouldn’t solve all of the problems you hope to address in your roadmap. Rather, it should encourage focus on the aspects most crucial to your MVP’s specific purpose. After working with companies for over a decade to bring their visions to life, I see most MVP’s fall into the following categories: Scale Model, Proof of Concept, Foundation and Iceberg. Knowing which of these you are building is critical to making sure you will be achieving what you expected when you are done. In this post, I walk through each type and give direction to product owners and developers on what to keep in mind in each type of MVP.
Scale Model
This type of MVP is where you know what type of product you want to build in the long term and your initial version is focused on building out a trimmed down version of your entire product. In this type of MVP, constraints are added to the product in the form of limiting the complexity or flexibility of a feature to simplify development. The long term goal of this MVP is to slowly remove these constraints and add in non-critical options as the product matures. For example, a Scale Model MVP might allow a user to only import from one file type rather than the 5 you hope to support one day. You might also choose to limit users to having one of something rather than the flexibility to have as many as they want.
What product owners should remember: Suppress the desire to complain about what is lacking and make the hard decisions to keep focused on only the most critical features. Scale Model MVP’s fall off the tracks when product owners can’t say no and suddenly the team is trying to build a fully featured product right out of the gate.
What developers should remember: You are building something where the entire purpose is to scale. While you may make assumptions on the interface to make things simpler, don’t make these assumptions in your data model. Talk about what things might grow eventually so you know where to use lists of values rather than constraining your system to only work in the limited feature set you’ve defined for MVP.
Proof of Concept
This type of MVP is probably the hardest to do well and takes the most organizational discipline to pull off effectively, but can be the most valuable and easiest to grow your product from. In this type of product, you identify a single key feature or portion of your long term vision that you want to test and ensure will be as valuable as you expect it to be. The key here is to be ok with having a very limited feature set, focusing on building out a single component or user story, and then validating this feature with users as soon as possible. Long-term, this type of MVP is very easy to expand, as it usually leads to very little re-writing of the application since the new features/components can be added into the proof of concept- usually by adding other sections or tabs to the existing codebase.
I’ll demonstrate this type of MVP with the scenario of an app for restaurant workers. A Proof of Concept MVP in this scenario would be building an app that just allowed managers to communicate changes to their shift times. Eventually, this app could have messaging from employee to manager, tracking of check in/out times, measuring performance and any number of other features. The Proof of concept MVP says: “If this feature isn’t compelling, the whole long term vision won’t be compelling.” Companies that build this kind of MVP demonstrate the potential validity of their product in a very economical way by building one component that could stay virtually the same in the final version of the application.
What product owners should remember: Get used to saying, “eventually it will do that, but right now we’re just making sure this feature makes sense”. It is really easy when gathering customer feedback to think that if it doesn’t meet all their needs, it is a wasted product- but remember that if your core feature is compelling enough to use without all the bells and whistles, then it will (potentially) be even more valuable later. With this type of MVP, you are in a unique position to gather customer feedback and critical help in determining your final feature set. When users have your product in their hands, you can ask them what the next set of features you should add are, building their personal investment in the product as well as them providing early feedback on your product.
What developers should remember: Don’t invest in building out the groundwork for future features, keep it simple. Often, Proof of Concept MVP’s find out that what they thought was compelling really isn’t, so pivots or significant changes are needed. When developing this type of app, prize flexibility and ability to test different designs over building a system that will stand the test of time.
Foundation
The Foundation MVP is what most organizations who launch a product end up with. This type of MVP is characterized by a small set of features similar to the Scale Model MVP but also the infrastructure created for all of their future aspirations. While on the outside this seems like a good strategy, often the product managers are frustrated during development because features aren’t coming out as soon as they expected due to investment by the developers in infrastructure to the future. Likewise, developers are frustrated when they feel like they are being overly pressured to create for the future without having clear guidelines or requirements. This type of MVP also leads to slow launches and delays as the team gets caught in the weeds solving future problems early in development as more thought and planning is put into future features.
It isn’t all bad news for Foundation MVPs though- this type of effort can sometimes be strategically advantageous for companies that have already validated their product or have significant inherent complication in their domain. An example scenario for this type of MVP is a company that has to create a system that can process and execute on internally defined rules to meet their own process. This type of product needs to be thought through on the front end in order for the complex rules to work, however the initial version might allow for a smaller set of features initially. This type of product should be built only in anticipation of finishing the effort. If there is ambiguity about whether or not the project will continue to completion, try to steer your team towards either the Scale Model or Proof of Concept paths.
What product owners should remember: Developers will work slower than you might expect as they have to weigh the requirements of the entire system when creating even the simplest of features. Make sure you have discussions with your team about all of the future aspirations rather than leaving things unsaid or left to inference. Also make sure that you pad release dates significantly with this type of product, as unexpected complications in the data model or infrastructure for future features can derail these projects. For Foundation MVPs, even if the product seems close to being done, there may still be a lot left to do.
What developers should remember: Don’t look at this type of endeavor as a free ticket to over-engineer and over-optimize. It is still the minimum viable product, so make sure you aren’t building in extra features that aren’t needed. It is tempting while you are chasing down rabbit trails in the data model to make sure you can handle all of the future requirements to build something more sophisticated than needed, but steering clear of this temptation will lead to a more refined codebase and product.
Iceberg
The Iceberg MVP usually occurs by accident when the development team has too much time on their hands and lack a strong direction from the product owner keeping them on track. This type of product is characterized by a product that is already complete and fully featured for the future roadmap, but only a few features are shown to the end user in order to seem like they are trying to keep the first version simplified. The main issue with this type of product is that it doesn’t react well to user feedback. Often a sign that you’ve built an Iceberg MVP comes up when you have to rewrite a lot of code for a feature that wasn’t supposed to be in the MVP after you get user feedback. An example for this type of project is someone who built the groundwork and services for a fully functioning message and notification system on top of a simple time keeping application, but didn’t expose it to the end user. The development team will end up being fine if requirements don’t change after user feedback, so sometimes this type of effort goes unnoticed. Good product owners are able to prevent this type of MVP by maintaining focus on what is being exposed to the end user and giving good feedback about where flexibility should be built in and what can be left less tractable.
What product owners should remember: Even if you aren’t able to code, your function in the product cycle is critical to make sure that the tough decisions are made and the product is kept on track. The product owner should be able to stay away from Iceberg MVPs by not flip flopping on decisions (which leads to developers building more complication by default). If you think you are building an Iceberg MVP, try getting a 3rd party audit of the codebase after showing them what the features are for MVP and see if the code matches the design.
What developers should remember: “Premature optimization is the root of all evil”. This is one of my favorite sayings because often programmers think complication and “cool” ways of doing things make one a better programmer. Simplicity is the mark of a good product creator since simple solutions often solve the problem at hand and allow for complication to come naturally (as it always does) when feedback suggests it is required.
Hopefully this summary of different types of MVPs has sparked the need for a conversation with your team about what type of product you are trying to build. Communication with your team is the most important part of this decision since expectations will only be aligned properly when everyone is on the same page. If you are honest with your team and yourself about what you are setting out to build (or if you are honest about what you have already built) then the process of creating an MVP can be a positive first step towards your product goals rather than a source of frustration for product owners and developers alike.
