MVP in the business / technology sense stands for “Minimum Viable Product”.
In the ‘Lean Startup’ a minimum viable product is the approach taken to minimise the time and cost spent building a ‘no frills’ product or software service in a way that still has sufficient key functionality to allow the concept to be meaningfully tested by early users / customers. Feedback and lessons gained from the MVP phase allow for a more robust and likely to succeed fuller product / software service to be developed and rolled out to the market. Do you have an app or software idea you want to progress?
A Minimum Viable Product (MVP) is the simplest form of a new app / SaaS product which allows a startup team to collect the maximum amount of validated learning about customers with the least effort – not for reasons of laziness, but for reasons of efficiency. An MVP differs from the traditional tech product management strategy of releasing an incomplete version of an app / SaaS product and then iterating based on user feedback. This difference has been summed up by two often-quoted passages from The Lean Startup: “release early, release often” and “the minimum is just that – minimal.” With an MVP, entrepreneurs are able to test their assumptions in the real-world by involving users as they develop their apps and SaaS products. The goal of the MVP process is to get an early answer to the question: is your business idea worth pursuing? As such, the MVP method is a way of thinking about the software product development process that favours early customer feedback and continuous iteration over chasing perfection.
In the early stages of the startup process there are a whole heap of ways the entrepreneur’s tech idea could fail, so the minimum viable product concept is designed to get the app / SaaS to market quickly, cheaply and with minimum features. However, while this sounds great you should be mindful that this approach does have its limits.
It saves time and it saves money. If you build an all-singing all-dancing version of your wonderful SaaS / app / portal service from day 1 and you get it right then super! Annoyingly, this isn’t how the real world tends to work and oftentimes what has been launched will have missed out some important functionality and will have included some other functionality that the market really does not care about. In short the SaaS / app / software that was launched did not hit the bulls eye… going the MVP route allows you to course correct the trajectory of your business model en route to the target making the chances for success far greater.
We are fully conversant in a wide range of technologies. If you have specific requirements re the technology stack you would like us to use (e.g. perhaps you already have a part-developed system / app you want us to finish for you) then let us know. Otherwise, once we have understood what you are wanting to accomplish we will let you know our recommendations re the most appropriate technologies to use to meet your needs.
First we need to understand your business concept and goals.
Then we will discuss and see if we can add any value to your idea for you.
Then we need to brutally pare back these ideas to allow us to arrive at a specification for the MVP phase of your SaaS / app / software.
We then do our development thing while keeping you in the loop every step of the way and eliciting your feedback as we go.
You then acceptance test your MVP service.
The MVP software / app / SaaS can then be tested on some users / customers.
User / customer feedback is collected and analysed.
The collected feedback is synthesised to allow you to decide what to do next on your route to full launch.
Want to start the process today?
Start simple, revise based on feedback, and scale up. Don’t worry about trying to get everything perfect. You can always improve later. Having a Minimum Viable Product will make it easier for you to find out if what you are doing is working or not, by seeing if people are actually using it – this gives you real data rather than guessing. Not building an MVP means you might be underestimating how much work something requires or overestimating the value that users will see in it – just because you know why they should want it doesn’t mean it is necessarily so obvious to the users! Not going the MVP route means you run the very real risk of sinking a lot of time and money trying to perfect a software product which there might not actually be any viable market for. Customers are a fickle bunch, they don’t know what’s best for them!
You don’t always need to build an MVP for a project – sometimes building a full product is exactly what you need to do. MVP’s are a great way to test a new concept, but if you already know (as opposed to ‘believe’!) that the concept will work and what features people want, then it might be more efficient to just build the software.
We are adept at using a wide range of technologies as best suited for the project at hand. Examples of some of the technologies we have used are shown below, if you don’t see what you are looking for then feel free to ask!
As mentioned, in The Lean Startup we learn: “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” In other words: An MVP lets entrepreneurs see if their assumptions about customers and competitors will stand up when faced with real-world use and feedback and determine whether or not the business idea is worth pursuing. It is a way of thinking about SaaS or app product development that favours timely customer feedback and continuous iteration cycles above trying to launch with the ‘perfect’ product.
Regarding features there are two types of MVP’s: Minimum Viable Features (MVF) and Minimum Viable Product (MVP). Minimum Viable Feature: a feature is considered “minimum viable” when it allows a team to release a product or application in order to test its viability in a real-world environment with a subset of the final user base. Example: For an ecommerce store, this could include one or two core features such as product listings or shopping cart functionality. This would be enough for customers to get started using aspects of the site.
Minimum Viable Product (MVP): an MVP is basically more than just releasing some minimum viable features; it’s about launching just the most basic version possible that will allow you to start learning what works and what doesn’t work – it is that version of your product which allows you to collect the maximum amount of validated insight on minimal effort.
An MVP could have minimal viable features; however, not all minimal viable features constitute an MVP. The “minimal viable feature” is one step further along in the process of releasing your Minimum Viable Product (MVP). A minimum viable feature allows you to release part of your application with more functionality than required for testing it with users. This includes only some component parts or only the most basic business logic necessary for testing its viability. An example would be if you wanted to test whether people would be willing to sign up on your site – instead of waiting until you have a fully-functional registration system, you could release the application with only one field (email address) for registration.
The Minimum Viable Product is usually created with minimal features needed for its initial release. These minimum features are included based on feedback from potential customers. This means the features are in line with the users’ feedback and wants so you can create a software product that they are really looking for.
Building a Minimum Viable Product means creating a product that has just enough features to be released into the world as a learning tool. The idea is that by getting something out there quickly, you’ll learn about how to make it better and what needs to be added before releasing a full product. MVP’s should be built with the concept of “I want to understand if people would use this” or “I want to validate this idea”. If you can’t answer one or both of those questions before building an MVP then it might not be viable and could end up costing time and money without any real outcome – which isn’t ideal.
Before starting, decide on what your minimal viable product would look like. The main question when developing an MVP is: What can you afford to put into production that will give you the maximum amount of information in the least time? Start with core features and add more as you learn more about user behaviour and preferences (and whether they really fit your business model). Don’t build everything up front; remember – simple beats comprehensive every time.
Contact MVP Developer – we’re happy to help and can improve your chances of successful launch.
- Not enough money: many tech entrepreneurs don’t understand how much money they need for their startup get off the ground, or overestimate how much money they have. Without sufficient funds to get started, your business could run out of cash before you’ve even begun! Some startups also don’t consider that they will need more than just starting capital in order survive long term. A joint venture / sweat equity approach can help significantly as it can reduce software development costs for launch, sometimes to zero
- No Market Need: Many entrepreneurs believe in their idea so much that if only people knew about it they would be successful; not Understanding Your Customer and the market you’re truly entering is a one way ticket to failure. Emotions and pride aside, failing is a fact of life and if a business idea is going to fail it is far far better that it do so early and quickly. The MVP process allows you to build, launch, test and iterate in quick succession so you have confirmation early on about the viability of your business idea.
- No business plan: Many entrepreneurs start with an idea, but none of them consider where they want their company to be in 5 years or even in 3 months down the line. As the saying goes: “failing to plan is planning to fail”. While it is also true that “no plan survives the light of day” the discipline of compiling a business plan and the research and introspection it necessitates mean that you will be prepared for many of the bumps you may encounter on your startup journey.
MVP costs by definition will be a whole lot less costly than a full system development. If you have a specific budget in mind then it is best to state this so we know to accommodate this constraint as best we can. If you don’t have a budget and just need a rough estimate then we will quickly be able to give you an idea of the cost once we have understood your business concept in overview. Do you want an estimate for your project or to see if we can deliver your MVP within your budget?
One other thing to add, if we like your idea and the suggestion is interesting to you then we can discount some (possibly all) of the MVP development cost in exchange for a small share of your business idea. If that sounds appealing then take a look at our Joint Venture offer page.