In this post, we’re going to highlight a few of the best practices you should consider when building your minimum viable product (MVP). There is a great guide I’ve contributed to by Clearcode which you can Download Here, and there are already a ton of books and guides on this particular topic, but I’ve distilled some of the most important tips for you below.
Eric Ries, author of The Lean Startup, defines an MVP as a “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” The MVP approach allows you to minimize your risk of failure, and puts you in a much better position to raise funding from investors and more easily recruit team members who you’ll be able to rally around your product vision.
The MVP should contain the minimum amount of essential features that will allow you to release your product to a group of early adopters, collect their feedback, and make the necessary improvements before releasing it to a larger group of users.
Essential features are the must-have features that will deliver your prospective customers the essential user experience that will allow them to understand and evaluate your core product offering. Some of the critical mistakes you should avoid when building your MVP include:
- Building too many features: Remember that your goal here should be to build the most-essential features to help your users evaluate your core product offering, so all other features need to be properly prioritized and pushed to later stages of product development. Try not to spend more than three or four months building your essential features. Of course, if you’re entering a very mature market with loads of competition, your essential features list might be much longer than if you were entering a developing market. Be sure to leave out all the bells and whistles and copycat features.
- Failing to segment the market: As I cover in this Blog Post, during the early stages, segmenting the market is absolutely critical and your MVP should be hyper-focused on addressing the key problems of a specific market segment.
- Not having enough early adopters: To validate your assumptions, you need a large enough sample size, but this doesn’t mean showing your product to everyone. If you did a good job in recruiting enough folks for the pre-MVP research phase, then showing your MVP to these people would be a natural next step and you should hopefully have at least 10 users lined up to provide feedback. Receiving feedback from your users is a continuous, never-ending process and over time, as you add polish and introduce new features, your product will look less and less like an MVP.
Now there are several big questions you will need to answer before kicking off MVP development: Who will build my MVP? How long will it take? How much will it cost?
Let’s tackle these questions in-depth…
Who Will Build My MVP?
Determining whether you should build your MVP in house or outsource it to a technology partner is a difficult decision to make. Here are a few key questions to consider when making this decision:
- Is building products, particularly in the target market you’re pursuing, one of your core competencies? If you’re a digital agency that has never built your own products before, then building products is not one of your core competencies and you should most definitely team up with a technology partner. The same applies to product companies who are looking to develop an MVP that is outside of their core product expertise.
- Do you have in-house talent with the right skill sets? Bringing a new product to market requires a team consisting of the following roles: UX/UI designer, software developer, project manager, product manager, and system administrator. At the bare minimum, you need a UI designer (with some UX skills), a product manager (with solid project-management skills), and a full-stack developer.
The product manager role is difficult to outsource, so it is highly recommended that the product-manager role is handled in house, since someone internally needs to take ownership of the project. The key here is to figure out which pieces you’re currently missing and then determine whether or not you should go out and hire these individuals or find a technology partner, keeping in mind your core competencies.
There are many things to look for when hiring a technology partner—such as assessing track record, processes, and cultural fit—and we’re currently working on a comprehensive vendor-assessment framework which we will share in a separate post.
How Long Will My MVP Take and How Much Will It Cost?
As mentioned above, it’s generally not advised to spend more than three or four months to build your MVP. You want the flexibility to change direction in your product roadmap based on the feedback from early adopters, so focus on the most -essential features you can realistically deliver within the those first few months.
As for the cost, this will vary drastically based on the complexity of the project, the size of the team working on the MVP, and the quality of the development talent. A good rule of thumb is to not deplete your development budget during the initial three-to-four months, as you will need to have enough budget to make iterations and add polish after you present your MVP to the first few sets of users. So if your total MVP budget is $50K, and you receive a quote for $50K from a development partner, then do not pursue this project unless you’re absolutely confident you’ll be able to raise additional funding once this initial $50K spent, otherwise the project will stall once the MVP is delivered.
. . .
These are important guidelines to follow, but I do suggest further reading as well to improve your chances of success. Two books I highly recommend are The Lean Product Playbook: How To Innovate With Minimum Viable Products And Rapid Customer Feedback by Dan Olsen, and The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation To Create Radically Successful Businesses by Eric Ries. Both will dive deeper into how you can create products that people will love.