Minimal Viable Product (MVP) refers the the minimum amount that can be produced and still obtain value.
This value does NOT have to come in the form of something released to the public. This can come in closed user testing, in which the value we gain is the feedback we receive. To that end many in the Agile community advocate for the term Earliest Testable Product (ETP), rather than MVP.
Simple answer - It unlocks value earlier
Building a product takes time, and using traditional method means the customer won't get any value until the end of the big bang release. Using MVP means the customer starts seeing the value from the product far faster
In addition as we gain feedback throughout this helps us insure that what we're building is also the right thing. Perhaps based on that feedback we may find that actually we only need a simple solution making it both cheaper and taking less time? Or perhaps we find that we can build something that the customer never imagined they needed but could help them immensely?
The first step in developing your MVP, before weighing which features to build, is to make sure the product will align with your team’s or your company’s strategic goals.
What are those goals? Are you working toward a revenue number in the coming six months? Do you have limited resources? These questions might affect whether now is even the time to start developing a new MVP. Also, ask what purpose this minimum viable product will serve. Will it attract new users in a market adjacent to the market for your existing products? If that is one of your current business objectives, then this MVP plan might be strategically viable. But if your company’s current priority is to continue focusing on your core markets, then you might need to shelve this idea and focus instead, perhaps, on an MVP designed to offer new functionality for your existing customers.
Now that you’ve determined your MVP plans align with your business objectives, you can start thinking through the specific solutions you want your product to offer users. These solutions, which you might write up in the form of user stories, epics, or features, do not represent the product’s overall vision—only subsets of that vision. Remember, you can develop only a small amount of functionality for your MVP.
You will need to be strategic in deciding which limited functionality to include in your MVP. You can base these decisions on a number of factors, including:
Now that you’ve weighed the strategic elements above and settled on the limited functionality you want for your MVP, it’s time to translate this into an action plan for development.
Note: It’s important to keep in mind the V in MVP—the product must be viable. That means it must allow your customers to complete an entire task or project, and it must provide a high-quality user experience. An MVP cannot be a user interface with many half-built tools and features. It must be a working product that your company should be able to sell.