What Does A Real MVP Look Like?
MVP - or Minimal Viable Product - is a buzzword that was made popular by Eric Ries in his book The Lean Startup. The concept is simple: release as quickly as you can with the minimal required features to get your feedback loop started.
Yet, when we enter into an MVP project, we find ourselves in a sea of unfinished tasks, shifting requirements and developers who simply cannot deliver on time and budget. We get hit with a bad case of scope creep or are forced to release something that is not fit for public use.
So where did it all go wrong? And what does a real MVP look like?
Strip it Back and Strip it Bare
The issue with a lot of MVP attempts is that there is too much required too early on. The point of an MVP release for greenfield applications is so that the foundations are released and more features are added to in a consistent and continuous release cycle.
However, when everything becomes a 'must-have', the point of releasing a minimal product is missed. This can lead you to create a product based on what you think the customer wants, rather than what the customer truly wants.
The point of stripping back your features to create a barebones application is so that you can release quickly to your audience. It prevents your project from being stuck in development for two years, only to find that your market has moved on from the trend.
The feedback loop is missing when you continuously develop but fail to release. Your MVP becomes stuck in limbo and any feedback you get is subjective and internal.
Quality is the Foundation that Sets the Pace for Speed of Future Deliveries
A minimum viable product is more than just a working product - it still needs good habits and foundations in code, infrastructure, and processes to be an effective MVP that is conducive to extensibility and growth.
When an MVP is built with a good base, adding future features becomes easier and faster. When the foundations are weak or have multiple cracks under the pressure of continuous extensions, then the velocity of your application's feature delivery will slow down.
Creating an MVP doesn't mean tacking on features and hope they don't fall off. Rather, it's a process of thoughtfully creating a game plan that is able to adapt to market demands. There is a clear path on where you want to go with the application as a business, but it also has the ability to pivot when necessary if the market requirements change.
Think ‘Minimum Awesome Product’
With the availability of cloud technologies and skilled developers, creating a product that is sub-par will no longer make it in a highly competitive market.
MVP is now synonymous with delivering minimum awesome products that not only take your application back to the bare basics and then build upon it based on the feedback loop or strategic backlog of features, but also delivers a seamless experience that makes your customer want to use your product or service over and over again.
This means interface design that is visually pleasing and intuitive, loading speed that is optimized through the infrastructure based on the geographical location and features that solve a problem.
Types of Features that Make a Product
There are two types of features: the foundational feature and the enhancer feature. When deciding which feature to release, many tend to mistake the enhancer for the foundational feature.
An MVP requires the foundational feature to be decided on and released first before anything else. This foundational piece is also a space for contention and debate, causing the project to shift and delay.
A common strategy to prevent this from occurring is to look at the application, remove the feature and if it still functions without reducing the minimum required user experience, then it's an enhancing feature. If it's a strategic and core requirement, then it's a foundational feature.
There are only so many foundational features in any given application but an endless amount of enhancer features. The ability to distinguish between the two can help prevent your project from running over time and over budget.
Final Thoughts
Not all teams are made equal, and while it is common to assume that everyone hired as a developer has the same quality output, a good team will be able to deliver code that is able to withstand the demands of the codebase growing over time. Without this, your feature delivery cycle will lengthen until it comes to a grinding halt.
When MVP projects start to slip in its ability to deliver, there's a high chance that there are simply too many features to be delivered. Sometimes, it's because the application has grown too complicated in its design for something that's meant to be simple.
A good and effective MVP is one that is simplified with a minimalist approach to product delivery. It is focused on core functionality and user experience, rather than ancillaries that the business guesses that users need.
Co-authored by:
Dave Wesley ~ President, SRG
LinkedIn
Aphinya Dechalert ~ Marketing Communications, SRG
LinkedIn
