Why an MVP is so important for startups and new businesses
This post is about why an MVP (Minimal Viable Product) is so important during the early stages of a startup or any new business. It is critical to get that workable solution done as soon as possible, it can make or break a business if you spend too much time building your product.
During the time of a new start-up, once you are passed the planning stage you will start to think about the implementation. You write the code or build the prototype for the service or product you have started a journey with. It is very important not to go too far with your implementation, it is easy to get carried away, with features, with ideas and with more advanced long-term goals.
If you think you have a good business idea and you have begun the implementation already, you should stop now. It is best to plan out what your service or product needs to be ready for market, ready for validation and for a workable MVP to test with.
For the best possible chance of a successful start-up launch or even more business growth you need to consider what kind of MVP you need, I went through this process with my business, Bakup.io. Different services and products will require a different stage of MVP, this can be related to the market itself, the type of users and the requirements of what makes a service or product good, or at least good enough to launch with.
#What is an MVP?
Each start-up with have different needs, these needs will directly correspond to its market, the users and the purpose. Because each start-up or business is different, their MVP will be too. In basic terms an MVP is just a level at which your service or product is usable for the first time, it will have the most pared down version you can possibly build to get that launchable service or product. An MVP is the most basic version of your start-up, kind of like its first stage. It won’t necessarily have all the planned features or advanced nice-to-haves but definitely a solid foundation to which to build on long-term.
It’s not that your MVP has to be so basic that its worse than a competitor or won’t meet user expectations, it is more about getting your service or product to market as soon as possible. Some MVPs will require advanced features early on and in that case, it is fine, as I said before it depends on your use case and the market. For example, a social network start-up will require a lot of integration and easy accessibility. So that social start-up will probably benefit from making a web and mobile application for its MVP whereas, a start-up which focuses on enterprise B2B (Business to Business) software won’t necessarily need a mobile application to start off and thus will have other priorities for an MVP.
#How do you know when you have an MVP?
It is easy to over complicate an MVP but by using one simple rule we can simplify this down – As long as your service or product is a workable solution which actually solves your customers problem and it does what it needs to do, you are either very close to an MVP or already have one.
I say very close because, you also need to consider your market and your target audience. Some markets will require a set of MVP features based on current competitors, user requirements or things like product useability etc.
Once you have tested your service or product internally and get to the stage where you have something which could be tested publicly, you likely should be considering to launch your business. It is important to get to the market stage and test how valid your solution really is.
Consider your market, really focus on user requirements and what they will be happy with, maybe your idea won’t be as good as a competitor to start off with but is approaching the problem differently?
Don’t go all out on advanced features and all the bells and whistles, keep it simple, build your workable solution and focus on your target audience and what will make them want to try out your product.
#Using an MVP to validate your idea
Just because you may think you have a genius idea it doesn’t always mean it will ultimately work. Huge amounts of start-ups fail each year, there is nothing wrong with failing but you must choose to learn from failure. An MVP can help get your product to market and begin the validation phase.
Before you (and maybe your team) burn yourself out trying to build the best product ever, consider getting an MVP done first, plan out strictly necessary features only for your market. You can then use the MVP to validate your idea, MVP validation can be so helpful early on.
An MVP can act as a safety cushion, it allows you to adapt your product early on without much technical debt. There are many benefits from validating your MVP, let’s discuss some in further detail and why they can be important.
If you are building a product and don’t know your market very well, an MVP can be very useful in understanding your target audience in more depth, before any long-term project commitments. To be successful at user growth after a product launch, knowing your product is validated is key, if you know people want what you have, it means you can validate spending more time on the project. Market validation is about confirming that there is a need for your product or service, making sure people actually see value in what you’ve built. Some founders change their idea or pivot the business if they find out their initial start-up has been heading the wrong direction, this is a great thing to realise early on rather than when it’s too late.
Before you fully build your product with all its advanced (and future) features or proper infrastructure it is important to confirm that your product design is correct, that it is actually capable of scaling long-term. It is crucial that your foundation is solid, that your code, design or prototype is something you can build off. Does it perform well? Is it actually capable of solving the problem it was built to solve? – An MVP is a great stage to test the technical capabilities of your product, it is easier to change the foundation at this stage rather than later on, things get complex quick once you advanced from a foundational level, technical debt is real.
This is something which I tackled with Bakup.io, I went through numerous design stages and different implementations with my co-founder. We changed more than half of our product during our main MVP stage, it was very important to us, we were able to validate the right set of features before we started to focus on user growth.
During the MVP stage of Bakup.io we actually changed our pricing model and even made future plans for long-term features based on the feedback we got during the MVP stage. It is so important to understand your pricing model and how the company will make money. Financial validation is where you can test out your pricing or subscription model, you won’t know until users actually start singing up and reacting to your pricing, you may realise you need to change in some way, not all pricing models suit every start-up, monetisation can be tricky in the early stages of a business, be prepared to change for the better.
#Product Development Life Cycle
Your MVP should be about acting on certainties rather than assumptions, the MVP is vital to verify your product concept. To add some more detail to the product development life cycle, this stage should only focus on the foundation first:
Your idea, you should have a starting point to grow from, really simplify down the idea to its simplest form, focus on the core requirements
Set out and plan the criteria for an MVP, don’t over complicate it, just the basics and the core requirements of your target audience/market, don’t waste time on low utility features
Build the actual MVP to specification, it is ok to change throughout the build, just don’t go too far, always revaluate user requirements, testing is so important early on
Always listen to your users, they are the ones who won’t hide how they feel about your product, not everyone is right but keep a high perspective on feedback, analyse data and have multiple data sources for user interaction and performance metrics
From what you have learnt, it will come time where you can decide to either change your MVP or build on top of the foundation you have, focus on high-priority features first, once you grow, users will want a more complete product before any fancy low utility features
#MVP Strategy Outcomes
Even if you were to build your product to completion and spend enormous amounts of effort implementing all your advanced and long-term features before launch, you will likely be burnt out and the quality of the final 20-30% of the product will be poor. Working on a product for too long can force you to lose perspective.
User feedback is very paramount early on in your products life, an MVP can help you make primitive decisions, you may not realise something about your product until real world users try it out. You may decide to completely pivot the way things work, to improve things for your users, because of them. It is best to make these decisions during an MVP rather than a “finished” product.
The payoff from doing a proper MVP comes from what it makes possible. Early on you don’t always know what users want, it can be hard to predict trends in the market and each type of business is different, an MVP enables you to not go all in before you can validate your idea and product design. During an MVP you may find yourself going through different product iterations before you find out what works in your market.
Overall, the main outcomes to focus on from an MVP are:
Save time and money on further product development, work on certainties before you commit to long term goals, understand your users
Collect data for research and statistics to later aid in product refinement for future features
Get a chance to present the idea to potential investors and act as a proof-of-concept in the real world
Make business decisions based on your experience during your MVP, product or feature iterations can guide you in the right direction for growth
#The Lazy User Model
The lazy user model of solution selection (LUM) is a model in information systems proposed by Tétard and Collan that tries to explain how an individual selects a solution to fulfill a need from a set of possible solution alternatives. LUM expects that a solution is selected from a set of available solutions based on the amount of effort the solutions require from the user – the user is supposed to select the solution that carries the least effort. The model is applicable to a number of different types of situations, but it can be said to be closely related to technology acceptance models.
The model draws from earlier works on how least effort affects human behavior in information seeking and in scaling of language.
Earlier research within the discipline of information systems especially within the topic of technology acceptance and technology adoption is closely related to the lazy user model.
I’ve mentioned the Lazy User Model in relation to doing an MVP because I believe it is useful to help you understand what your users want, you can use this model to decide what features to select for the MVP (before it has been built) and for features after your MVP phase.
Some people can get confused on what to work on after an MVP, you all of a sudden go from working on everything and anything, in order to get the MVP working and then suddenly launch a product and end up sometimes confused where to start after product launch.
There is a lot more depth to this model but briefly it starts from the fact that there should be a definable “user need”, a “user requirement” that can be observed. The idea is that you should be able to put an array of features in front of a user and they should pick the one which makes them more comfortable, users most of the time want features that make their interaction with your product more effortless. Usually with this model the features are simple, they are features which only solve a problem, they fulfil the needs of the user. However, one solution might be useful to one user but maybe not useful to another, that is why it is important to analyse the whole situation.
You can choose many ways to implement the data collection, this could be through a feedback form, a clickable button with a range of choices to a solution etc. Whatever it is it will need to be unique to your service or product to work. The model’s foundation is that the user will pick a solution/feature based on the lowest effort required and this is defined by:
- Monetary cost to them
- Time and energy needed
- Mental and physical effort
This is only a short introduction to the Lazy User Model (LUM) but it is out of scope for this article to discuss further, if you wish to use this model with your MVP, there are lots of resources online.
For me personally an MVP was so important when I was building Bakup.io, at first we were unsure which features we needed to build for our launch, we had already spent months on our product at the time. We got to the stage where we felt like we should have been launched already. That is where the MVP strategy came in and saved us, saved us from burn out and from wasting more time not being in the market. By focusing on an MVP build we were able to select only the core features we needed for launch, it gave us hope and a light at the end of the tunnel. We could have gone on for months but we knew we needed to just get the product working and out there.
You can spend so much time perfecting your service or product but eventually you’ll need to “hand it in” and let the market take over. You can’t keep building forever, get your foundation right and accept that it takes time to have a “perfect” product. Overtime you may find that your target audience changes, this is vital for a successful MVP phase, find your audience and build from there, the MVP should show if you have this right or not.
It’s not about cutting corners or building a low-quality product, it’s about getting your foundation right and understanding what your target audience really need – There is always time to build those advanced features and nice-to-haves later on. If you are struggling to define your MVP, maybe you should focus on building a MLP (Minimum Lovable Product), users should want to use your product at its most basic form.