A concept gathering considerable momentum in the world of software development is the the Minimum Viable Product (MVP). And it tends to be more valuable for mobile and tablet apps than elsewhere.
We all make the mistake this addresses, but I have to confess that I am one of the worst offenders. That’s because once I embrace an idea, all of my creative juices spring into action, and I go all out. My brain wants to run off to explore every possible feature, bell and whistle and extension imaginable. And this can be a really bad idea for a first release of a new product.
The problem arises from our assumptions, and they in turn reflect what we don’t know.
Whenever we do something for the first time, whether to buy a product or build it, we tend to pontificate at length about what is important. Over the years I’ve come to realize that whatever I thought was important usually isn’t, and the real game changers were mostly things that I hardly even considered.
So, when you build your new app (or any other software application, for that matter), you’re likely to put enormous effort and expense into features that may ultimately prove to be largely unimportant or unnecessary. And that’s where the Minimum Viable Product concept really helps.
The MVP concept forces you to focus on exactly what you need, so you can define the feature set required to make it happen. Done correctly, if any feature in the MVP is missing, the app or software system simply won’t do its job. For example, in an e-commerce app, it just won’t work if you can’t show the customer products for sale, add them to a cart, specify shipping and billing options, and process the order. Other functions, such as ‘You might also like’, gift registries, discounts and promotions can all be left for V2.0.
When you add features, you also add cost. Even more important, you add development time, which stands in the way of your initial release. Instead of having customers using your app, your developers remain the only users. Instead of getting feedback from users, you … and your developers … continue guessing what the customer might want. In my experience, you’ll probably be wrong. (Substitute employee for customer if your app is for internal use).
By getting users on board earlier, you not only make a smaller initial investment, you also get a quicker return. Most importantly, more people are on board, pulling to make your app a success, and feeling that they had a hand in shaping it. These early users then become a force to help train later users, and to cheer them on. And because they helped shape your product, it feels to them like it’s theirs.
Another side benefit of the MVP approach is that your initial release is more likely to be stable, with fewer bugs, since the number of bugs tends to rise geometrically with the number of lines of code. Testing involves far more use cases, which in turn makes it likely that more bugs will slip through testing. These bugs will degrade the experience of your initial users, and they are likely to pass on their frustration to the next generation of users.
And what about all of those features you didn’t include in the initial release? You may find that many of them, including ones which would have been a bear to implement, weren’t really important. And your early users will probably tell you about others that you may not have considered, that would be really valuable.
What do you do with all those ideas that were running through your brain while you were planning your app?
It doesn’t hurt to write them all down as they come to you. They can help guide your system architecture and database design, so you don’t wind up with a problem, if those extensions ultimately prove to be important.
You may want leave hooks for them, or use replaceable modules, so you can seamlessly implement these features later. But at least you won’t be bogged down by them while you’re working to get your MVP release out the door.