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?

Make sure your planned MVP aligns with your business objectives.

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.

Start identifying specific problems you want to solve, or improvements you want to enable, for your user persona.

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:

• User research
• Competitive analysis
• How quickly you’ll be able to iterate on certain types of functionality when you receive user feedback
• The relative costs to implement the various user stories or epics
• Translate your MVP functionality into a plan of development action.

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.