mobile-apps, minimum-viable-productI recently launched a mobile application which, one could say, was in a minimum viable product state. That is, it was lacking some key features, but it could still function fine and still solved the problem that it set out to solve. My reasoning behind the early launch was to get the product out to the public as soon as possible in order for it to start making a name for itself. I figured that since it was easy for me to update it, it didn’t matter as much that it wasn’t in a more complete state. I worry, however, that new users coming across the app might be turned away by its not-quite-complete state and be turned off by it that they’d remove it from their phone before I got a chance to push out my updates to them.
My question is: did I make the right decision? In the case of easily-updated products, such as mobile apps, is it better to launch quick with a minimum viable product, or wait until the application is in a more ready state?
I’ll say to this what I find myself saying to every other question on this site: it isn’t directly related to your answer, but make sure you have your intellectual property first. No matter what, don’t release a product that doesn’t have the patents you want done on it.
Phew, now that that’s out of the way, I think you raise an interesting point. There are definitely some advantages in launching a minimal product.
Corner the Market Early
If you’re the first to be out there with your app’s functionality, you’re bound to receive most of the downloads in the future just through brand recognition and word-of-mouth. It’s way easier to succeed as the first than it is as the second.
Early Feedback
Maybe users want your app to go in a bit of a different direction than you had planned. Launching early like this gives you distinct advantages in that you can have real people using your app in the real world before all your plans are set in stone, and more importantly, before you’ve already invested a ton in some feature that people just turn out not to use that much. You could also find that hoards of people download your app in the first few days and that it might be worth hiring another developer on to push the process along, even if only by a week or two.
Early Profits
No secret, it’s hard to work for nothing. By launching an app, you’re offsetting your income to be earlier, which is good. That might mean it’ll come immediately instead of when you get the app 100% done, or it could mean that you’ll just make the money earlier in the future than you otherwise would have. Either way, it’s good for morale and paying personal and professional bills.
Morale
Plain and simple. Shipping is good for morale. Whether you work alone or with a team, watching a product you’ve worked hard on for months go out into the real world is an exciting–albeit scary–time. If you can show yourself and your employees that yes, in fact, your product will get done with the leap of faith of launching an almost-ready app, you’ll give them something to work off of. Particularly if you haven’t been paying much, as many startups are wont to do.
Get Everyone Comfortable
Users need time to adjust just as applications do. A user won’t pop on your app and suddenly use every feature, nor do you want them to. It’s a process, so getting them started with a fraction of your planned feature-set probably won’t really have all that negative an effect. Give them the time it takes for you to write more, to learn how to use what you’ve already got. They won’t feel overwhelmed by having way too much to do, and you’ll benefit from fewer support calls as the learning-curve builds itself slowly.
Keep ‘em Coming Back
Finally–I think, admittedly this is several “finally”s in–releasing updates to an app is a huge market advantage. Think of when you get used to using an app you love then one day you turn on your phone and, gah!, it was updated with a new feature! It’s an exciting experience for us all. If you can give end-users that excitement every few months, you’ll keep them using your app during that time. The last thing any of us want is to be thrown into the endless abyss of a being a download-run-never-use-again app. And updates help avoid that. If nothing else, it’s free advertisement for their phones to pop up and say “Updated [your app’s name]!”
So, well, yes, that’s all well and good. But it doesn’t really answer the question. Did you make the right call? Well, that depends. I think the first thing to note here is that the “right call” is a subjective matter that cannot be told retroactively. So first off, don’t stress over what the right call was so much as what you can benefit from the call you made. If you launch early then ignore your users, you’ve made a bad decision. But in my experience, users are pretty darn hard to ignore. They tend to navigate ways to getting developer attention. I’ll leave it up to readers whether I mean that in a good way or not.
When all is said and done, though, I don’t think it really hurts your image to have a mediocre launch. How many of us remember thefacebook.com? If you’re going to make it big, having a bit of a bumpy start with a not-so-full-featured app out the gate won’t kill you.
But that all said, for future reference, if I were you, I’d launch it as a beta. You have a choice whether to make it a private, invitation-only beta (and, you know, invite a few thousand people) or a public one and advertise through social media, but I think that’s a great way to launch a mediocre product and still, miraculously get people super pumped over the idea of it.
If it solves a problem people are having, regardless of whether it is polished or not, you should still be able to sell it and get people using it.
If you can’t with your core product that is meant to solve one issue, then you don’t have a product.
You need this validation early as well, so yes, launch away and quickly as long as it solves a problem and doesn’t create anymore in the process. With so few customers to begin with you can stay in close contact with them to ask them what they want to see and that the product is developing.
On the close contact with early users, I can assure you that people love this more than a complete product. They love knowing they can reach out and get changes made if needed, rather than risking it with a larger product that looks great but they might get stuck at a later date due to something they didn’t foresee.
The whole purpose of the MVP is to validate an idea/project/app, check if the model suites the problem it is looking forward to solve, and allow next steps to be built. Sometimes the cost of doing this is losing some of the first users/costumers, since they might find something that is not really complete/suitable to their needs.
However, from experience in several projects, although the cost of losing the first few users, the company was able to convert them back when the software/app was complete.
As I can see, this cost is way lower than the benefits of knowing if you are going the right way, if it fits the market, positive/negative feedbacks, among other incomes of opening your MVP.
Update considering @War10ck comment
It is important to note that by opening your MVP you can surely assume it, depending on how easy it is to build a good test group, you can either choose between a public and a private release.
Naming a MVP as Alpha/Beta could also provide a feedback to the user that it is still on a testing period. Remember to consider what is the best alternative at your stage, if it is looking forward for some users to test privately, opening for everyone, or opening a “registration” to release the test for some selected users. I’m sure there are also other possibilities, but those seem to be the most broad.
All content is licensed under CC BY-SA 3.0.
