“Just one more thing.” Many of you have heard that phrase – or have even used it yourself – when deciding when to launch an application. Development companies often give in to the temptation to add more features to their apps, far in excess of what is needed, or even advisable. It’s perfectly understandable; developers like to make cool things, and to make cool things cooler, with elegant solutions to complex problems. We all face the temptation to continue adding things to a product in an effort to make it better, which is laudable but not always advisable.
Adding more features will delay your product’s release. It just will. Every new function and feature requires further testing, further vetting, and further development, all of which push back your launch date. These days, windows of opportunity open and close very quickly. Knowing what is good enough for your customers, in order to get an application released to them sooner rather than later, can be the difference between the success or failure of your product.
In short: you need to know when it’s time to stop developing, and just release what you’ve made.
Launching an application: Start by knowing your customers
You need to understand everything about your users in order to properly design your product. Most companies believe they know what their customers want, but there is a critical difference between knowing what they want and knowing why they want it. This means that you have to understand their real goals.
What are they trying to accomplish with your product? If you understand your customers’ goals and communicate with them, you will be able to define what is good enough to meet their real needs. It will help you design solutions that actually fit what they’re trying to do. For example, if a retail business wants the app you develop for them to have a barcode scanning function, it’s important to know what they intend to use that function for. Will it be for the customers to scan an item themselves to check the price, or for the employees to help manage their inventory? Understanding what they want to do with the application will help guide your approach to design the right solution to fit their need.
Knowing your customers’ motivations will help you decide to release your product sooner rather than later. You may be surprised that they will not only be willing to talk to you about this, but will be excited about it. They will look forward to the next release (“What’s coming next?”). Managed correctly, your customers will guide your roadmap for ongoing development.
Minimum Viable Product (MVP) – it’s a good thing
You may have heard the term “minimum viable product,” or MVP. It’s a discipline that says “ship only what you have to.” Some people view an MVP as a lesser or downgraded version of a release, something to feel apologetic about. But if well-planned, this scaled-back product can be even more successful than a full-featured one. When you believe that you can’t ship without this, this, or this, nine times out of ten, some of those things can actually be deferred to a subsequent release, and no one will even notice. If it helps, think about a minimum usable product, rather than viable.
You can even argue that if you release your app sooner with fewer features, you’re guaranteed to have an audience after your launch. You’ll demonstrate your willingness to both grow and support the product, and get your users involved in this process. All of which can help make your product a success.
MVP’s get the product into the hands of your customers faster, so you can begin fulfilling their needs more quickly, saving them money, or time, or whatever your app is intended to do. It also starts your revenue flow sooner, not to mention locking up customers that might otherwise go to a competitor.
The catch here is you need to be prepared and make sure you are technically capable of delivering your app in pieces. An MVP is the start of a long relationship, and a promise to keep delivering. Don’t just drop one and disappear.
Build in stages; the road to “DevOps”
There’s another new term you may have heard: DevOps. DevOps is the merging of Development and Operations into one continuous update-and-release lifecycle. This tends to be spoken of mostly in reference to cloud applications, because cloud hosting enables you to update your product as often as you like. It gets harder if you have a mobile app (that is distributed through app stores), a desktop app (downloaded or [heaven forbid] distributed via DVDs), or IoT devices (field updates and firmware flashes).
But DevOps can be more of a state of mind than a specific process: understand that your overarching goal is to listen to your users, build new features to address their ever-changing needs and wants and the opportunities those present, and getting those features into their hands as quickly as possible.
Once you establish your particular flavor of a DevOps process, you will be confident enough to decide to release your applications sooner rather than later, getting your apps into the hands of users to begin the road to success. As I’ve stated before: A software application that is of any value is never finished. If you’re lucky, it will be a long and fruitful road.
