When looking for a company to start your custom software project you may hear the word MVP a lot. But what does it mean and how do you use it?
At FrogSlayer, we cut through the technobabble as much as possible; but we find that it is still useful to explain since it is so heavily used.
MVP, or Minimum Viable Product, is one of the many terms that originated in the Lean and Agile development process and is now part of the common software development vocabulary.
An MVP is the first version of a software product and includes only the core features which allow the assumptions about the software to be validated.
Validation in this case typically means validation from customers, but it can also come from peers or investors.
Facebook did it?
One of the most famous examples of a successfully executed MVP is Facebook. Mark Zuckerberg’s early roll-out was to a niche college student market, and had a sparse feature set consisting of linkable and customizable profile pages. Even though Zuckerberg’s goal at the time wasn’t to validate what would become the largest social network in the world, he accomplished just that with his first major release.
Start with the RDP
When clients come to us to develop a software product, the first step is to conduct a Research, Development, and Planning (RDP) phase. In this initial phase, we work with clients to define and outline their needs and goals.
Anyone developing a new software product has more ideas than they do time and money, so one of the final deliverables of this process is a list of prioritized features. These features and needs based on our own research into the business and market in conjunction with what the client communicates with us. Based on the individual timeframe needs of a product, these features can then be prioritized and organized into phased releases
MYTHS
Must include every important feature
Indistinguishable from any other first phase of a project
Only for consumer-focused startups
FACTS
Should include the fewest number of features that allow for validating the core assumptions
Allow for validation of hypotheses and changing direction before costs become too high
Have a high value for any size organization, and even for internal projects
MYTH #1
One of the most common misconceptions regarding minimum viable product development is that an MVP has to include every important feature that customers and users ask for during initial planning. Instead, the feature list, or “backlog,” should be used to identify the bare minimum features which comprise the minimum viable product.
This should be an active process which seeks to move as many lower priority features as possible to later stages of development. The advantages of a quickly deployed and low-cost MVP cannot be realized if it is weighed down with too many non-critical features, which is one of the reasons the preceding RDP phase is so important.
MYTH #2
Another myth about MVPs is that they’re just all the best features that will fit in the first budget and schedule, and have no bearing on the rest of the project. One of the key principles of developing software with an “Agile” philosophy is that feedback from users, clients, and customers is critically important, hence the need to ship new features on a regular basis in order to get feedback.
This is one of the key reasons that the minimum viable product puts the most critical and difference making features in the first release, to get feedback on them as quickly as possible. It’s then important to use that feedback to make changes, introduce new features, and re-prioritize the features that have already been listed.
Many of the projects we complete for clients are not the mass-market startup applications that often come to mind when discussing terms like MVP, but the same principles can be applied for both internal applications and new ventures undertaken by larger organizations. For non-revenue producing internal tools, the minimum viable product serves to check other metrics, such as adoption and usage. Custom software tools are developed to solve a problem of efficiency or fill an unmet need, and by creating an MVP which serves as a solution to that problem and nothing more, the potential solution and the specific approach can be properly assessed.
WHY FROGSLAYER IS DIFFERENT
A key tenet of FrogSlayer’s approach is iterative development where new pieces of functionality are delivered as they are developed and tested. This provides for quick turnaround, feedback, and fixes and manifests itself in the way we provide frequent status updates and the ability to try out new functionality as it is completed instead of waiting until the very end of the project.
These principles function hand-in-hand with our approach to minimum viable products. The MVP functions as a unique and first phase in our iterative development approach, with successive releases adding functionality and making modifications as market and user needs require.
Building software is typically a difficult and unpredictable process, with around a 70% failure rate for software projects. FrogSlayer’s success rate is much higher than the industry average, and we accomplish this in part through our iterative development approach and use of client and market feedback through tools like MVPs and RDPs.
Just like you, we’re focused on your users and business results. If you’re a new or established business looking to build your next software project, reach out to us for free pre-project consulting, or a free code/ architecture review if you’re looking to expand or modernize an existing system.