All May we were telling how to build a successful MVP, so that at the end of the day you have nothing to regret and the whole process of creating the product was smooth and easy. In the previous articles, you should have learned how to figure out scope and vision of the products as well as how to choose features for your MVP right. Today we will cover the final part of building a successful MVP.
Step 6. Choose Technologies
By the steps we will cover in today’s article you should have already figured out who is going to develop your project. Because here you will definitely need their help. Choosing technologies is extremely important for many reasons: it basically defines:
- How expensive the product would be
- How long it would be developed
- What are the limitations and risks
Of course, it is hard to decide it all yourself, so it is highly advisable to contact technical specialists, who will help you make the right choice. Besides, you should already know on what devices you plan to use your product and generally understand what it is: mobile app, desktop software or web-product. Or maybe all of them?
In the case of Volition, it was necessary to create a user-friendly online store within a short period of time.
And Ruby on Rails is well known for solving these kinds of problems So obviously it was selected. Generally, Ruby is a good choice, when one needs quick results. That is one of the main reasons we love it so much.
By the end of this step, you should know what devices you want your product used on and what technologies are expected to be employed to achieve that.
Step 7. Make milestones plan
As you know, good planning is the key to success. And MVP is not an exception. Remember, we were talking about funding stages and selecting features for MVP. Now when you take a few more steps and have a clearer understanding of what your product will look like and what technologies will be used for it as well as their approximate cost is time to settle down with MVP.
Again, you will need help from your technical specialists here, who will have a different view of the features and provide a better estimate of them. In 9 out of 10 cases, estimates will change (and unfortunately in the majority of cases they will be higher. So be prepared for that and understand that this happens Since more details are available now it is better to agree to a longer development phase than to change your marketing strategy later when the team doesn’t meet the deadline.
It is often the case when you have to make MVP a little smaller to make the release earlier. There’s nothing wrong with that. Usually, one can always find a couple of features to hold off on and deliver a little later.
Taking all this into consideration it makes perfect sense to create a milestone plan. Split your MVP and Backlog into phases and rather than set strict deadlines set rough guidelines for when you expect this or that part to be delivered. Again, guidelines or deadlines are always set together with the team that is going to develop the project, otherwise, they won’t make any sense and will probably fail.
When setting milestones think of delivering separate parts of functionality that can be tested and looked at independently. If one part can’t be used without another one, it is better to put them all together in 1 milestone. The amount of milestones directly depends on the project itself, but generally, it is recommended to make short milestones 1-2 months each. This would help you to get better control over the product development and your budget.
This is the part where building MVP ends and the actual work on the project starts, but we will tell you about this at a later date.