Software products are often expensive and take a long time to build, which is why you want to make sure you are building something customers will want. But the problem with building software the traditional way is that customers will not actually be able to give you their opinion until the project is finalised and in their hands.
Instead, tech companies start from building a Minimum Viable Product (MVP).
A Minimum Viable Product, or MVP, is an early-stage version of a new product with the least amount of features necessary to perform its intended function. The production team would then add more functionality to the MVP over the course of several development iterations, making sure to collect and incorporate user feedback.
MVPs are commonly used in software products, both commercial and business, however, MVPs are also useful when creating commercial products and devices. They all need to adhere to a simple rule though, they need to provide business value.
For seasoned software development teams and managers, MVP seem to have gotten a bad rep over the last few years - they tend to be expensive and leave everyone with a bitter taste of compromise. Some also started to use the term MLP - Minimum Loveable Product, to emphasise that the focus would be on uncompromised lovability of the deliverable. Here we tried to debunk some of the myths around MVP and some common mistakes we had worked through in the past, hopefully providing a bit more clarity to the concept itself and the right way to execute.
Releasing a minimum viable product instead of a full-featured product can provide several benefits:
The MVP development process allows you to test new business concepts to see if they resonate with your target customers. As you gather feedback, you’ll be able to tell who your core target market really is based on the most active users and how they interact with your product.
Once the MVP has gathered enough information, you will be able to choose which features to prioritize next and adjust the product’s functionality to match user expectations. This continues until either the product is considered complete, or for the entire lifetime of the product.
An MVP is the perfect strategy when you’re trying to catch a shifting or rapidly expanding market. Lots of competitors are scrambling to come up with their own solutions, and the winner is often the first one to make a usable product that answers the market’s needs. Since you’re only focusing on the minimum amount of features, it should be faster to build, test, and release.
Just make sure that the early version of the product is actually usable. It doesn’t help you if you release a shoddy product just to be first. Customers will notice and will ditch you in favor of the better offering.
Your concept sounds great, but do people actually want it?
User experience is a large part of what makes a product “sticky”. And while you can (and should) hire UX designers and leverage their experience, the user himself is the ultimate judge of usability and longevity.
When you release an MVP, you release it with the understanding that the UI and UX design will change over time. Your Product Designers should gather as much user feedback as possible and refine the user interface to suit the user’s sensibilities. They may even be able to identify new opportunities to expand functionality and upgrade the product further.
Most people do not like change. Giving an ability to make an incremental, but small change takes them on a journey and opens up to constructive conversations. All transformation teams take time and very often it is a lot better to start with an MVP rather than a revolution that will disrupt your business. That gives people time to adjust and reap benefits from chunks of functionality, without the fear of overwhelming change.
Building an MVP is a very specific development process, and there are many ways to do it wrong. I have listed some common mistakes below:
Many project owners believe that the MVP should be shiny and bug-free. This is the exact opposite of what an MVP is. Remember, you are building a basic product that is just functional enough to provide value to the user.
You should fix as many bugs as possible, of course, but it should not delay the MVP’s release if they are not show-stoppers. Users can't wait to see what you’ve prepared for them.
This is when you take the “minimum” in MVP too far. In situations like this, you have cut down on nearly every feature and function and released a product that is basically useless. Users will hate your MVP because they can’t actually do anything with it.
You must balance your MVP’s capabilities so that it can still be valuable for users, but not be weighed down by extra unnecessary features that slow product development.
This is the biggest sin when building an MVP. The entire point of releasing the minimum viable product is so that you can use feedback to inform the other features. If you are not going to collect or accept user feedback and you will be acting based only on your assumptions, then you may as well build the entire product in one go and release it. You’ll be wasting just as much development time and money.
For the best chance of succeeding, you will want to recruit people that are experienced in building MVPs. Inexperienced development teams have a tendency to overestimate their capabilities and underestimate the effort required to build and test a viable product. This results in the project going over budget, thus leading to even more of a rush to complete. In the article about the MVP price, we explained all the costs you should be aware of.
The end result? An MVP that is late, expensive, and has poorly designed and implemented features.
CSHARK has decades of accumulated experience in software product development, which includes building both MVPs and traditionally-structured projects. Over time, we have picked up some hard-won lessons that we hope will help the agile development of your own successful Minimum Viable Product. We’ve listed 15 of those steps below:
The “idea” is always the most thrilling part of agile product development. It is when you are the most driven and the most enthusiastic. You have gotten the idea together and you’ve found an important problem to solve! All you need to do now is build the solution. Right?
Your idea might be new, but it might not be practical-or even needed. There are plenty of startups who solved a problem people did not need getting solved. In industry sometimes we call such startups as ‘problem architects’ - those that would design a problem to fit their solution.
The first step will be to approach your target market (i.e. the people affected by the problem your MVP will solve) and tell them about your idea. Do not be afraid of someone stealing your concept - the chances of that are very slim. They are not likely to have a development team tucked away in their basement, nor the million of dollars needed to pay their salaries.
Conduct interviews and discover whether or not the issue you are solving is a real problem, and if your solution is likely to help. Confront difficult questions right away. Better to know your idea’s weaknesses sooner rather than later.
The next step will be to look at any potential competitors. Many startup entrepreneurs claim that “they have no competition,” but all that really means is they did not look hard enough. Someone will have tried to solve the same issue before but in a different way. Investigate their product and see if their attempt at a solution worked, and what you can learn from their experiences.
Idea validation can save you the cost (and heartbreak) of building a poorly-conceived MVP, so do not rush through this step. Make it a non-negotiable part of your agile MVP product development process.
Think big, but start small.
Development teams sometimes have trouble remembering what the “M” in “MVP” stands for. Many decide to pack in extra features into the MVP's feature set, which ends up delaying the launch and wasting production time on something that will probably change anyway. Also, a poorly-executed MVP will also increase your technical debt and may introduce product or system limitations down the road.
In this step, control the urge to tack on extra functions. Aim for something achievable yet effective. The MVP is not supposed to be pretty or comprehensive; it is supposed to be a base around which you can grow the rest of the product. It’s there to collect feedback from product users so that you can watch trends and establish more use cases.
A bloated MVP is often the result of a weak product owner or development process that is ruled by a committee. Strong leadership and a well-defined scope of features will help keep the size of your MVP manageable and get it out the door faster.
In an ideal situation, you would have product designers and software development specialists ready to take your project by the horns. In our experience, however, most startup founders and business decision makers don’t have the resources to build an MVP that matches your vision.
You could always build an internal development team of course, but that takes months (sometimes years) to put together. Even organizations with existing internal resources may not necessarily have the expertise and skills required to build a decent MVP on the first try.
This is not a deal-breaker, though. You can still partner with external teams in order to get the job done.
For instance, you can find a product design studio to help conduct product discovery workshops and turn your idea into a workable concept.
The product design studio would break your idea down into a process that helps understand the user from a product manager’s perspective. Each step would prioritize user experience, thus increasing the MVP’s chance of success. The design studio could then create a product sitemap and wireframes (in the case of a web-based solution) and prepare a low-fidelity version for user review.
When you reach out to users at this point, you are testing more than just the strength of your idea. You are also testing the strength of your brand. This early concept will attempt to use as much of your branding as possible (or as much as you have) so you can know if your key philosophy will resonate with customers.
Then, once this test is done and you have collected enough customer feedback, you can work on creating a high-fidelity prototype of your product. And for this, we’ll need a different type of partner.
A tech partner is an external team that can help you design and develops your MVP. They will often have a full development team with a wide range of technology products under their belt, and a proven agile development process already in place.
Find a tech partner that’s more than just an order-taker. You are relying on them for their tech expertise, so they need to be willing to stand their ground to protect the development timeline and scope. They need to keep what's best for the product in mind and be able to defend their approach decisions in case you request a set of features or changes that would be detrimental to the MVP.
Let the tech partner be a part of the product discovery process. This way, they’ll be able to create a project backlog from the high-fidelity design that the design studio created. The tech partner would also be preparing the architecture of your project as well as selecting the proper tech stack to build and maintain the project moving forward.
The ideal option is to find a tech partner that offers both software development and product design services. The project’s design and development will be more closely coordinated since the team designing the product works in the same company as the programmers and testers that’s going to program and test it.
At CSHARK, we conduct Discovery Workshops as a part of the digital product’s planning phase. Here, we help you to understand the entire development process from start to finish. We go through the details of what needs to be done to successfully deliver the project and provide accurate budget and timeline estimates.
Technology matters just as much as the people. Tech is a force multiplier that helps them be more reliable and coordinate better. Tools can generally be broken down into three categories:
This tool is where you can document the project plan and track responsibilities, timelines, and progress. This is where all members go to refer to the backlog and submit user stories. JIRA and Monday are our project management tools of choice, but you are free to use whatever other tool fits your development team’s requirements.
You need an effective way for people to communicate, both in real-time and asynchronously (so just relying on email is out). Your communication tool should allow coordination of meetings, discussion of ideas and problems, and pinning of oft-used links. We like Slack but, again, the choice is up to you.
You will need a reporting tool that can help you present important information in digestible chunks to the programmers and to stakeholders. Your project management tool will sometimes have a sufficient reporting module, but you may need to use Excel, Power BI, or some other report-focused software.
The MVP development project kickoff involves more than just saying “get to work.” It’s a pre-game briefing.
A proper kickoff involves making sure everyone knows their roles and responsibilities. It involves reviewing the project scope and their part in it. It also covers the different tools software developers will use during the development process and any related explanations.
The kickoff is also a good opportunity to set expectations for people’s schedules and preferred methods of communication.
When possible, conduct your kickoff meetings on site (maybe after we do not need to social distance anymore) and include all members of the project. This should include product stakeholders and subject matter experts.
It’s easy for managers and/or product owners to draft a plan and call it a day. But the MVP development plan you construct in your head may not match what you can do in real life.
Share your plan with the crew and break things down into sprints. Get their input on your proposed schedule and whether or not they think it’s workable. Adjust if necessary and reevaluate your timelines.
The key is to be ambitious yet realistic. Make an MVP development plan that is too aggressive, and it’s going to fail and burn the team out at the same time.
Your programmers should stay in close contact with you and with each other. Schedule daily standups where you can discuss progress. These don’t have to be long; just 10-15 minutes should be enough, depending on the size of the team.
Establish a culture of communication, where people are encouraged to talk and share potential complication they encounter during development. The more challenges are out in the open, the more people will be thinking about it and the faster you’ll be able to come up with a better solution.
Software development is hardly a set-and-forget affair. You have to closely track the progress throughout the sprint, and ensure that the features you build function properly. You are supposed to monitor risks and how changes will affect the timeline and budget.
Look beyond the current minimum viable product and decide on the next feature set. But don’t do it in isolation; confer with the product owner and programmers to see which new features will make the most sense for customers.
No project plan ever survives contact with real life. Even something as scaled down as an MVP will experience delays and rescopes. But that does not mean you should automatically accept all changes.
Before editing the project plan, start from confirmation of the change with the rest of the development team. Does everyone agree? Why or why not?
Try to make small changes that do not affect the scope or functionality of completed features but still align with the development strategy. Record the details of every change in the backlog. Get everyone (especially the stakeholder) to understand and accept the impact of the change before committing the change to the plan.
Test new product features whenever they are delivered. Test them at an early stage of development. Test them before moving to the next phase. Test after updating the production version. Test products before putting them on the market. Test products after putting them on the market. Test the bug fixes that you missed in your previous tests.
Test. Test. Test.
No software product will ever be 100% bug-free, but you can minimize the amount of bugs in your MVP through constant testing. You should also be prepared to respond quickly to bugs once customers discover them (and there will be bugs).
We’ve been making this point all throughout the article, but it bears repeating because it is important. Stick to your minimum viable product.
Control any and all changes to the MVP. Do not alter the plan without good reason. Every change you accept will make it easier for “just one more change” to slip through.
Schedule product changes for after the release, even if they seem like really useful features. If the MVP works out, you’ll have plenty of opportunities to add these new features to the main product. Besides, this is probably a better business decision, because the revenue you get from the MVP can finance the product expansions.
Your MVP has to be lean, but that does not mean it has to be bland.
Make sure you capture the brand in the user experience of the product. This could be communicated by the aesthetics of the user interface, the product’s ease of use, or in the depth of its capabilities. Even something as simple as the color of a button is enough to communicate personality, and you should take extra pains to make sure it aligns with your intended brand image.
As you can see, building a minimum viable product is a very involved process. But this is a good thing because it increases the likelihood that your own minimum viable product will be well-received by your target users. As you collect and incorporate user feedback, your new product will grow in size, scope, popularity, and profitability.