You’ve likely heard about the concept of the Minimum Viable Product or MVP. The idea is to build the simplest software solution that satisfies the business and user needs — then begin iterating. Keep improving the product in release after release.
The MVP concept is controversial if only because defining a minimal viable product is difficult. Doing it well involves a methodical and agile software development process something like the following:
- Generate a product vision statement including goals and objectives
- Build a product backlog containing mostly epics
- Prioritize the backlog using the vision statement as a guide
- Deliver product increments until the MVP is reached
The primary issue I have with the MVP is the Product part. By definition, a software product is something to be sold to customers. It generates revenue. It takes a lot of work to build a software product good enough to generate a major revenue stream. In essence, the barrier to entry is high — perhaps too high.
Lower the bar
A complimentary approach is to aim for the Minimum Viable prototype or MVp first. A software prototype is something people can use, analyze and examine. It may be called beta software and offered at no charge to encourage participation.
The advantage of the prototype over the product is that software development teams can get working software into the hands of real users sooner. This enables teams to get feedback early and often. There is still the problem of defining the MVp but because it’s a simpler software system, the definition will be easier and faster.
The resulting software development process will look something like this:
- Generate a product vision statement
- Build a minimum product backlog
- Prioritize the backlog
- Deliver prototype increments until the MVp is reached
- Release the MVp and solicit user feedback
- Keep releasing prototype increments until the MVP is reached
- Keep delivering product releases
photo credit: Daquella manera via photo pin cc