Saying you’re working on an MVP is all hip and cool these days, and part of the now prevalent Agile methodology. But, I posit:

Do you really know what your MVP is?  How do you know when you’ve reached it?

To take a step back, a software engineering MVP is defined as the Minimum Viable Product. Meaning, the first point in the product’s lifecycle at which your product has the minimal feature set and performance specifications such that it has some usefulness to a customer. This is true for any product type: Hardware or Software.



But, how do you know when your product has reached that point? Simple. Just ask.

The MVP is not for you, it’s for your users. So, ask them. Ask them what features they need before they can begin using your software product for some meaningful purpose.

  • What are the fundamental features required to enter the market?

  • What are the bare minimum features necessary for your product to begin providing value?

This is what the MVP is, not what features are the most interesting to you. If you don’t take the time to do this research before beginning MVP software development, you run the risk of spending too much time and money on something that has little value and low ROI.


But, once you have spent the time to talk to customers and understand the market, you must continue on to the next step – which is to write it down! Write down the list of features for the MVP and their specification metrics. This is called a PRD (Product Requirements Document). This document is crucial to you staying on track towards your MVP engineering, and subsequent product development cycles.

Without a PRD, MVP engineering teams run the risk of falling into the trap of feature creep. Feature creep is when new features are added to a product without bound. It can be very tempting to add features because “it will be easy to add just one more…” or because a demanding customer (with a large check) asked for them.

Be careful, as this can be extremely dangerous! If you become susceptible to feature creep you run the risk of adding unnecessary complexity to your product.

The more features you have in your PRD for MVP, the more variables you introduce and thus the more complex your product becomes. The more complex your product becomes, the greater the risk of issues and bugs, which can impact your MVP software development timeline causing delays and excessive costs. Likewise, the more features you have, the more time you have to spend on the MVP software development and testing. The more time you spend developing and testing, the less time you spend getting your product in front of customers to solicit valuable feedback. I’d argue getting feedback from customers, even on just a few features, has huge value when you are at the MVP engineering stage of your product lifecycle.


A PRD clearly defines:

  1. What features are or are not to be included at the various stages of your product, including the MVP and beyond

  2. What performance metrics each of these features must meet

  3. What are the acceptable metrics and what are the stretch goals

When your team is neck deep developing MVP software design, without doubt, new ideas for features will come up. Some will be easy to implement and very tempting to do so, but that brings you back to the feature creep conundrum. In this case, use the PRD to help guide you on whether or not to add the new feature. If it doesn’t align with the original requirements, don’t include it. Period.

Keep your MVP to a Minimum.