MVP ie minimum viable product
How long do you want to polish your app / website before presenting it to the public? What milestones should you mark and what should be in those milestones?
First of all, whatever you develop, there is a goal, that goal is 1.0 of the app, the first such goal / milestone, this is your MVP (Minimum Viable Product - the most basic, for early customers - visitors - users of the app already "satisfactory" product from which conclusions can be drawn, feedback for future development).
Why? Every day, thousands of websites are put on the web, tens of thousands of apps go to stores, risk every day, every hour. You don’t have to be someone better than you, at first it’s enough to be faster.
Of course, in many cases we don’t have to compete with time either, it’s still worth pursuing with this approach in mind.You can find out from MVP that your service and/or application in the market is desired or not. If it is, it`s worth further development, if not, you can gain new strength by moving the development in another direction.The point is not to shed light on all of this at the end of the development, when we may have spent all of our savings or at least a significant amount of money for a possibly unnecessary product.Not to mention that with an MVP (in the IT field) we can even put the team to the test, and if we’re not happy with them, we can move on with our needs at an early stage of development.
But what kind of milestones should there be after arming the app/product?
A milestone (usually) is not a feature / function and not even an epic (epic is the combined name of many related features, e.g. the user process, from registration to login could be an epic), but several such epics together. Who will tell you what these milestones are? Usually, the developers or the managers who are in contact with the developers would be the most appropriate. They will recommend you an arming schedule, marked with milestones, with an associated action list for each milestone so you can see exactly when they will be armed.
It’s a good idea to schedule arming for the first half of the week so that any bugs are fixed on weekdays to avoid having our application inoperable throughout the weekend.
There are usually few milestones, but of course their number increases with the size of the project, and the rate of time-completed improvements in the project is worth keeping an eye on. For example, if you have 8 milestones, and by half the time, the company has only managed to fulfill/reach 2 milestones, it is a rather ominous omen - if we assume that all the necessary information was either provided at the start of the project and/or all questions were answered immediately to the developers / managers.
Author: Istvan Dombi
I work on IT development area since 2010, I had luck ever since to work on from simple corporate websites to e-commerce platforms and various API integrations (payment gateways and other third-party APIs) to complex international web applications. My main stack is backend development, within that PHP and GO languages.