Some companies think they can’t replace an app with a new version until the new version does everything the old one does.This is a huge mistake. You can – and should – follow the minimum viable product (MVP) model even when replacing an app. Unless, of course, you’re looking to build an exact copy of your current software on a new platform (which would be a shame) or think you already know everything you need to know to build a better app (unlikely).
While the perception exists that MVPs are more for developing and testing new products, I’d like to argue that those same benefits apply when replacing an older app with a newer version.
Here’s why.
Quicker to Market
With an MVP, you can get to market much quicker than you would if you built every desired feature first. We touch on this in our free webinar, The 3 Secrets to Delivering a Commercial Mobile App in 4 Months.
Getting your product to market quickly delivers a competitive advantage. It can also keep existing customers from jumping ship to a competitor’s product when they see you’re hard at work on a new version. And if they think they can influence or make recommendations on how that product evolves, so much the better.
The Old Version Still Works
Another reason to follow the MVP process for a new version is a simple one: the old product still works. Customers can continue using the existing app for any functionality they require. At the same time, they can start using and testing the new app for the features it provides.
In this way, the MVP could address a critical feature that customers want to see upgraded. They can take advantage of that new feature while using the old app for all their other needs. As time goes on and you add more features through your production sprints, customers will naturally use the new version more and the old one less.
If you can make that process seamless (or at least easy) for the customer, this becomes a very effective and powerful way to transition customers into a new version.
Better Feedback on What to Build Next
Your early adopters are always eager to start using a new app – as long as it provides value. This plays right into the MVP model, where the object is also to provide a product with real market value. By designing a minimum viable product around a value your early adopters want, you can entice them into using that product.
Once customers start using your new version and see the value in it, they’ll want you to reach the point where they can consolidate and use only that version. These first users become your best source of information on what to build next. They’ll make sure you know exactly what they need to see in the new version before they can migrate completely to it.
Analysis of Features Being Used
Once you have a new MVP version in play, you can analyze the usage of your early adopters. Are they still using the older version? Which features are they using? Studying behaviors like these can be even more valuable than direct feedback.
A customer might say they “need” a certain feature ported into your new version. But examination of their activity might suggest that they’re doing just fine without it, or not even using that feature in the old version. This helps you prioritize your product backlog with user stories that bring the most value to your new app. It also gives you some rabbit trails to investigate with your customers as to why they’re using (or not using) certain features.
A few years ago, we built a new cloud version of an app for a client. The original app took five yearsto build… we built the new version as an MVP and released it in six months. Today, three years later, it still doesn’t have all the features of the original version. Our client’s customers haven’t asked for them. That’s the sort of time, cost, and effort you can save when using an MVP and agile approach to building software.
Signaling Progress to Customers and the Market
Returning to the first benefit, an MVP gets you to market quicker. And that has the additional, inherent value of showing the market that you’re actively improving your software. By shipping a new version, you’re signaling that you’re “in the game” long-term and not just sitting on a successful product.
This is especially true when your new version begins with a minimum viable product. Customers see that you’re not just retooling… you’re on a path to make that next version better. Signaling such progress to the market doesn’t end with the launch of your MVP, either. You can continue boosting your market awareness throughout development as you innovate and add features to it.
“But won’t an MVP rob sales from my current product?”
This is the most common objection I hear from company executives about replacing a product with an MVP version. And it’s obviously a valid concern.
Some customers might not want to buy your existing product when they see it’s in the process of being replaced. At the same time, they might not want to use your “limited” new version, either.
So what can you do to alleviate those concerns? There are several ways to approach it.
- Keep the new project in “skunk works” mode until you’re ready to market it. You can enlist some early adopter partners with non-disclosure agreements to provide real world feedback and usage data.
- Target your MVP at a new market segment not directly served by the existing product. This way you can grow market share in the new segment without impacting your sales prospects with the current software. Eventually, the new version may encompass the features your existing customers need and they can migrate naturally to it.
- Bundle the MVP with your current product. Paying customers get both versions of the software, with free access to the new features as you add them. This way your customers don’t have to choose between buying now or waiting.
All of these are legitimate methods companies use to avoid cannibalizing their existing sales. Depending on the situation and the product itself, you might discover other, more creative ways to blend your current and future versions.
What I can tell you is this: using a minimum viable product model to build a better version is always going to be worthwhile. So if you need help planning your next version, or how to mitigate your risks between versions, contact us at Ascendle today.