How you narrow down a MVP
I often see companies starting with a MVP and then from there — iterating from feature to feature, focussing on a product market fit. This is a good way to go, however in my experience it can be difficult to know when your product is ready for market. It often takes a lot longer than expected and there’s always more that can be added.
Companies often over-engineer their MVP, forgetting what it really is about. So, I want to share my thoughts on what an MVP is and how it should be built. Let’s start with the definition.
Definition
Minimum Viable Product (MVP) is a core product with just enough features to deliver value for early customers and learn from them.
Now that we know what a MVP is, here is how we build MVPs.
How we build MVPs
A MVP tackles just a few core features, from which you think they are solving the problem of users plus one that aligns with your business objectives. If you catch yourself thinking of too many edges of the product, just ask yourself „does my MVP really need to have this? Is it solving the core problem I’m trying to validate?“.
It should provide you data, insights and analytics, from where on you can make the best the decision for further developments, improvements and iterations of the product. So translate your MVP functionality into a plan of development action. A good example of MVP is a landing page with a brief description of your product and its features.
You can also create an interactive prototype, which shows how the final product will look like. It’s hard to say what exactly can be considered as an MVP, but there are some common features:
- Simplicity
- Clear value proposition for users (what problem does your product solve?)
Sometimes a MVP mustn’t even be a “real” product, it can also be just a dummy, a lead form, a frontend with no backend at all. It’s all about testing an idea with real users before committing large budgets.
