From Sign Off To An MVP In 90 Days - How To Make It Happen
Is it possible to release a minimum viable product, or MVP, within 90 calendar days of a new project being signed off?
This would be considered a blistering pace, but it is possible, and at Rocketmakers we always consider this when circumstances allow. Lots of things need to be in place before this is attempted, though - more on that below.
Before first, let’s examine why releasing an MVP so quickly is desirable in the first place.
For an MVP, speed matters
An MVP release is the first opportunity to test an app in a real commercial environment. This is useful for many reasons, but perhaps the most important one is the opportunity to gather feedback from real end users (and not just a test audience).
In a very few cases, this feedback might tell us that the end-user’s problem has been precisely identified and solved, and that the project is perfectly on course.
Much more often, however, user feedback tends to be a mixed bag, validating some ideas, while making it clear that others need work. That’s okay - learning from users what they really want is what an MVP is useful for.
The faster an MVP can be released “into the wild,” the sooner that feedback can be captured, and the sooner the next iteration of that digital product can begin.
But how fast is fast enough?
There’s no right answer to this question, but - when we can - we like to consider a 90 calendar day timeline.
The 90 Calendar Day Challenge
For an MVP to be launched within 90 days of sign off, several factors need to be in place.
One obvious one is that you need to make sure the team you need is available! For more general projects, Rocketmakers usually has plenty of experienced and highly capable designers and developers who are ready to join projects as needed. When a project requires more specialist knowledge (like machine learning or 3D modelling), we usually have people ready to get on board fairly soon, but there may be a delay while they finish another project.
Another key factor for getting an MVP launched quickly is the “scope.” This is the list of features the MVP will include. As the term “MVP” indicates, this needs to be kept to a “minimum,” but agreeing what is a “must have” for the first version can be a time consuming process. Work shouldn’t begin until the scope is finalised, however, so our hope is always to get this done at sign-off. The better the client understands their ultimate vision for their digital project, and the stages the project will need to progress through to get there, the more quickly the scoping process can take place.
There’s also Tech Debt. This might sound like a bad thing, but “tech debt” is often just being strategic with resources during the MVP process.
When an MVP is built, it will likely have a few hundred users at most. Depending on the application, it might take months or years before that number rises to the thousands or tens of thousands. Is it a good idea to build the MVP to handle tens of thousands of users from the start?
Usually not. A complex, robust software architecture takes time to implement, and has a higher running cost than a simpler system. If an MVP will only have a few hundred users, we recommend building an app that will work beautifully for a few hundred users, but not investing the time and resources in a version that does the same for thousands more.
Later on, if the app is successful and the user base begins to scale, there will be time to pay back that “tech debt.” As long as the MVP has been built in a way to make scaling straightforward and simple, this won’t be a problem.
Oh, and by the way, at Rocketmakers we build most apps using a system called Orbit which makes scaling straightforward and simple. We know exactly how to help you leverage your”tech debt” for maximum advantage.
Is a 90 day MVP launch really possible?
A lot has to go right to get an MVP launched 90 calendar days after sign off, but it is possible. When it works, getting a new digital product out into the hands of end-users so quickly is a huge benefit, and can really accelerate development of further versions.
Whether or not it is possible for your project depends on all of the factors discussed above, plus a few smaller issues that will be particular to your project.