Embracing the MVP Mindset in Software Development
You can have a little bit now, or everything never. And this isn’t a bad thing. It can be a hard truth to swallow in software development, but this is critical to understand to keep your product development fast-paced, agile, and profitable. One of the biggest temptations that comes with building software is to code every idea ever brought up in the boardroom before the first external user ever experiences the product. THIS is a bad thing.
The Dangers of Aiming for Perfection Before Launch
Waiting to launch until your software is “perfect” is a recipe for stagnation and lost revenue opportunities. If you wait until the product is perfect, you will never launch the product. Here are some reasons:
- The software will always have bugs.
- A perfect product for stakeholders will always look different.
- The users need to inform your decisions on features to strive for perfection… for your users.
Understanding the Minimum Viable Product (MVP)
Outside of the ESPN channel, MVP stands for “Minimum Viable Product”. It is a product built with the minimum feature set to validate a product idea. You should launch a working product that meets some of your users’ needs so that they will want to use it, then use their feedback to validate and improve the product. It is impossible to anticipate every need or want your user will have. And some of those wants may be bad ideas.
Therefore, however tempting, it is important not to try to anticipate all possible needs with the first product launch. The best long-term plan for building software is to narrow down and build a few features right, then validate those features and add more features to the product backlog with your users’ help.
Addressing Common Concerns and Misconceptions
A valid opposition to this ideology would sound like, “Why would I launch a product to the world with only a few features? I want to reach ten million users tomorrow, and if the product is ‘incomplete’, none of the users will want to keep using it.”
The Benefits of Launching an MVP
Here are some of our opinions/facts:
- Launching an MVP will save you time and money on software development.
- Users will want to use your product if it does what they want better than other solutions/options.
- Users would rather have four rock-solid features than thirty features that are hard to use, or that they don’t have any interest in using. (There’s nothing worse than using a cluttered program where you need to find 1 tool out of 500.)
Learning from Industry Experts: Insights from Eric Ries
Eric Ries, author of The Lean Startup, said in a talk at Google, “…the biggest waste that product development faces today is not building things inefficiently, but building things very efficiently that nobody wants.” It is a lot easier to stomach a company failing $20,000 into development rather than $2,000,000 by finding out that the target audience you thought would be interested in your product actually doesn’t think your product fulfills a need for them.
Even if there was market research done before development started, by the time you finish a $2,000,000 software project the market could have shifted or your competitor could have seized your planned opportunities. By building the right things at the right time, your resources won’t be wasted but rather optimized. This is especially important for startups.
Establishing a Feedback Loop for Continuous Improvement
Once you define your problem, conduct user research, define your MVP, build your MVP, and finally launch your MVP, it’s important to set up a pipeline of feedback. This helps to set in motion the continuous improvement of the product towards “perfection”.
- Define what you are trying to learn.
- Plan how you will facilitate getting feedback.
- Put a process into place to make that feedback actionable
- Then act on it!
Building for the Future: Iterative Development and Sustained Growth
User feedback is the foundation for how to keep iterating on your product and building the right things at the right time throughout its entire lifecycle. And of course, the features that didn’t make the cut for MVP can be built immediately after the last MVP feature is completed. The intention is not to limit the product, but to develop features iteratively so that the product can be sustained. With a defined MVP you will have a cheaper, shippable product to start validating with customers sooner.
By Morgan Brown