We’ve all heard the horror stories of the large software development project that took longer and cost much more than was originally planned. And in many cases the finished solution still missed the mark on requirements, or even worse, got cancelled because it was no longer relevant. Although there are a variety of reasons this could happen, some of the more common reasons include the following:
- Users couldn’t fully articulate or anticipate their requirements
- The software developers misinterpreted the requirements
- The business’s requirements changed over time
- Software Development
There has been a lot of research and money spent by industry experts, software developers, project managers and companies to develop and implement methodologies and procedures to improve how requirements are gathered, validated, and managed over the course of a project. However, even the best thought out and managed project can still run into these issues.
The Minimum Viable Product
In 2011 the Minimum Viable Product (MVP) concept was popularized by Eric Ries’s bestselling book “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses”. The general idea behind the MVP approach is to launch a new product with the minimum amount of features to receive the maximum amount of validated learning about your customer’s requirements. The MVP is moved quickly and iteratively through the build-measure-learn feedback loop to validate the requirements and merit of the product. Although the title of the book implies that the concept is meant for startups, the ideas can be employed within any organization launching an internal software development project.
The MVP approach to product launches has been validated over time. And some of its core concepts, like employing an iterative & measured feedback loop, are at the heart of other software development methodologies and best practices. Yet, how many software projects have you been involved with that employ these practices? Unfortunately, for many of us the most common answers are very few or none.
Business as usual
So why hasn’t the MVP approach gained more traction? One common reason, particularly in traditional business, is we are risk adverse. We have been taught that we need to know how long the project will take, the cost, the return on investment, etc. before we invest a dime. So we gather all of these details prior to starting a project. Then, with detailed plan in hand we begin the long drawn out process of implementing the solution. And in the end we hold our breath and cross our fingers that we got it right. Sound familiar?
On the surface, the idea of starting to implement a solution before we have all the answers seems counterintuitive. However, the reality is no matter how much we plan we won’t have all the answers when we start a software development project. We can make educated guesses and have the best intentions but we won’t really know until we start getting something into our customer’s hands and receive their feedback. And wouldn’t you rather find out what they really need, what they’ll actually use, and whether this project even has merit a few weeks into the project rather than 6-12 months down the road?
Now we’re not saying that you should abandon planning altogether. It’s still part of the process. However, even the planning can be done iteratively as more pieces of the puzzle come together. The main idea is to make incremental investments towards developing the right solution.
In this post we’ve tried to summarize the core concepts and benefits of taking an MVP approach to your software development projects. For the sake of brevity we hit some of the highlights, but we highly recommend doing some additional research on the topic as you begin to plan out your next project and whether an MVP approach is right for you.