The launch of a minimum viable product, often referred to as an MVP, is one of the most exciting moments in the lifecycle of any digital product. Real users get to interact with it for the first time and provide feedback on everyone’s months of hard work. 

It’s also the moment when work on the next version can begin in earnest. During the MVP process, the development team compiles a list of features called a “backlog.” Some features are deemed to be absolutely necessary to be included, and some are left in the backlog for later (a process referred to as “scoping”). 

Now that the MVP is launched, it’s time to look through the backlog and decide which features to tackle next.

Two types of feature in your backlog

Features in a backlog after an MVP launch tend to fall into one of two different categories:

• “Nice to have” features that aren’t necessary for the app to function as a product, but would hopefully add value in later versions. 

For example, an app might only have English-language content for the MVP stage (when the user base might be restricted to the UK). Adding additional language support would make sense when the app is rolled out internationally.

• “Fast following” features that were deliberately left out of the MVP, but are understood to be a short-term priority for the post-MVP launch. 

For example, the development team may decide not to include an automated payments feature in the MVP.  The user base will initially be small, and administrators can process payments manually. Leaving this work out allows the MVP to be launched more quickly, but would become a problem once the user numbers start to grow rapidly. 

Both “nice to have” and “fast following” features are important to the success of your application, but how you prioritise them depends on your situation.

Adding features to an MVP with a new development cycle

An ideal way to build on the success of an MVP launch is to keep the same team together and start work immediately on the next version. At this moment, everyone is very familiar with the product, the business case, and has a great idea of what needs to happen next. 

There is an argument to be made that taking a short, planned break between the MVP and the next version is an even better option, however. New users who are engaging with the MVP in the initial few weeks or months can provide essential feedback for scoping the features for the next version.

Sometimes starting a second development cycle just after an MVP launch simply isn’t possible. What happens to the backlog then?

Updating an application through support

Every application needs support to keep it running smoothly and securely after it’s launched. Often this is to update “dependencies,” which are bits of digital technology that help your software run (like javascript or .NET). Support can also include eliminating small bugs or making minor changes to the app itself. Maintenance of underlying components and infrastructure is vital to ensure the application is deployable, secure and performant.

Some items on a post-MVP backlog might be small enough that they can be handled by a support team without the expense of running a new development cycle. If planned correctly, this could include some small “fast following” features which an app needs to grow, but were intentionally left out of the MVP. 

Using support for development work is far from ideal in most cases, though. The Rocketmakers support team will look for opportunities to improve an application, and will invest unused time to make these improvements. The support team is working at its best when it is focused on solving problems rather than creating complex new features.