Minimally Viable Product. Startups and big corporations alike are all obsessed with the concept. The benefits are clear if you do a quick google.
So let’s imagine you are starting something new. You have a great idea, albeit a little vague. (Don’t have a good idea? Click here.)
You’ve read about an MVP and are convinced that the philosophy is for you. It’s time. to build.
So you sit down and realize you have no idea how to define what goes into the MVP.
Hopefully, this article can provide some help and structure to the process.
Defining an MVP
Here are the high-level steps I take in defining an MVP:
List the desired qualities of the MVP project
Enumerate the Key High-Level Decisions about the MVP scope
Collect information about Key Decisions
Enumerate Potential MVP Options
Compare MVP Options Based on Qualities and Key Decisions
MVP Most Desired Qualities
To be honest, if you do nothing else, do this first thing.
Listing out the qualities most desired in an MVP implementation. Write it down and make sure your team revisits it often.
I’ve seen countless teams spend months or years building something, only to look back and think:
Wait, why are we doing things this way?
The team has probably made mistakes. Perhaps the thing they are building is not actually an MVP. Perhaps they have hired too many people or have started building out a customer service department to support the MVP when really, none of that was a part of the goal or desired qualities for an MVP.
Usually, this is because there was not a clear, written document defining the desired MVP goals, that was revised by the team often to ensure they are making choices in line with the MVP they actually want to build.
Suggestions for MVP Desired Qualities:
Fast to Implement - The MVP should be much faster to develop than the full solution.
Demonstrates all High-Risk Items - The MVP should demonstrate all "high-risk" items, meaning items that are technically difficult to do, potentially expensive, or longer to develop. This will inform the roadmap, budget, and schedule for the final product development.
Developed with a Smaller Team than Full Product - A smaller team not only increases the speed of development but decreases the cost of developing the MVP. The MVP development process will inform the headcounts required for the full product development cycle.
Ability to Pivot Away from a Specific MVP Implementation - Given that the MVP is meant to de-risk solving a problem with a particular technical solution, there is a non-zero chance that the first MVP built does not succeed. In this case, it is desirable to be able to throw that MVP away and start again without much hassle to quickly find a working solution.
Key High-Level Decisions About MVP Definition
When considering what to build, you have probably realized there are several key high-level choices you could make. It’s helpful to write these down, as you can use them to weigh potential implementation options next.
Example Key Decisions
Should the MVP be usable as a functional business tool or is it a pure de-risking / demonstration exercise?
Should the MVP focus on exercising specific technology products or focus on completing a minimal set of tasks for a specific business use case or market vertical?
Should the MVP exist in isolation from existing systems and/or business processes or should it be linked to the current systems/tools?
Should the MVP be built upon to reach the end state of the system, or do you plan to throw away the MVP and make a second version for the final system (presumably built quickly given the lessons learned from the MVP)?
Discussion About Key Points
Once the key decision points are known, it is possible to document the pros/cons as well as relations between the key decisions.
I suggest writing these down. As you structure your thoughts, important realizations may occur. For example, if the MVP will be used as a functional business tool, then part of the MVP development will need to include developing training materials for staff.
MVP Definition Proposals
Next, create a table that enumerates the key decisions and possible options. This is hopeful as it ensures the team is considering all possible options and all possible dimensions of every option. If there is a gap, it is easy to see in the table.
Example Decision Table:
Qualities of MVP Options
Now that all the available MVP options are known it’s possible to create a table comparing the options based on the desired MVP qualities discussed earlier.
Example MVP Quality Comparison Table:
Time to Build
With the options enumerated and compared based on the qualities you care about, the team can decide what path seems best. Now, it’s time to start sorting out all the exact details of the MVP given the goals and constraints here and most excitingly, you can start building.
Thanks for reading and I hope this was helpful to you.
If you like the way I structure my thoughts and work here, consider working with me: