Your initial release is going to be the one you have the least control over when it comes to planning which product features bring the most business value. The reason you are constrained is because certain things must get done and decisions need to be made for the first mobile app release. This weeks post is most useful to experienced teams that are new to mobile development and need a cheat sheet on what are the most important things to know when planning the initial release. Since we are agile, the goal is to release an acceptable app early to market without sacrificing too much quality that you can not respond soon enough to market feedback.
Top 10 Considerations For Mobile App Release Planning
1. What device(s) and operating system(s) is your app compatible with? You should keep track of the OS version and build number of the devices being used by the QA teams in conjunction with the code updates released by the development team. Even if you are using a cross platform mobile development framework, it may not make the most sense to worry about all mobile devices this early on. Shave time by choosing Android platform and indicate the compatible devices and software version. iOS will take a lot more time to get the first app submitted and approved by Apple, this does not include the timely process of activating an iOS developer account.
2. What are the CRUD requirements for the selected end users? For example, is this a view only app? Should all or only some of the data update?
This is pretty specific to the end user’s function and what this target audience expects. Shave time by limiting the number of user interfaces so there is less opportunity for users to assume and update should be available. If it is appropriate to your project, go for a view only app with minimal update capability and build an API to a 3rd party web service.
3. Which of your end users benefit the most from mobile apps?
In our case here, we are assuming you know little to nothing about the consumer profile, so you may want to go for users that have already adopted the need for mobile apps. Catering to one or a few users can minimize the need for permissions and access control functionality. Shave time by focusing on the needs of one end-user perspective.
4. What is the baseline functionality required from a technical standpoint to provide enough business value? login, sign up, forgot password, etc.
Be sure to only include those items which are deemed required by your development team. Studies have shown that only 20% of all features in any given software application are used 99% of the time. Let your market provide feedback on what is missing. Shave release time spending more time grooming the product backlog after each sprint looking for opportunity to release.
5. Is the app a free download, if yes how will you promote it?
If this is a free app, then you don’t have to worry about payment gateway providers. If you do need a payment You should involve the marketing department early on so they can get the most bang for company bucks. The strategy for a free app should always be purposeful and the right data must be captured for marketing and/or strategic use. Furthermore, your app may need to have the appropriate ‘forced’ update configuration.
6. What does the competitive landscape look like?
What ‘category’ and ‘price’ is this app searchable in the marketplace? Go do it now and keep doing it every sprint planning meeting because that is what potential buyers are presented with. Ensure your app is compelling enough to bring the most business value to the target end user AND buyer.
7. Who owns the data and should it be hosted in the cloud?
Depending on who your target end users are, you will need to research legal and security concerns that would prevent adoption of your mobile app. You may need to have a legal binding terms and conditions agreement to protect yourself and the company. If the data needs to be hosted in the cloud, you should start shopping for a vendor right now or seek the guidance of the marketplace or iOS developer community for possible short-term solutions that make more sense for your initial release.
8. Will you need to support the app with manual processes? Can the product handle a high volume of end users?
In this case, the worst case is the best case. If your app happens to go viral, but users experience poor performance, it can backfire and actually hurt the company reputation out the gate. If your app has functionality dependent on a manual process by the scarce human resources, there should be a protocol in place to handle the volume and still respond to customers quickly. Sometimes it makes good business sense to NOT automate processes for the first release, just make sure there is a plan to automate when the need arrives. Another precaution is to invest in performance testing and load balancing toward the end of the release cycle and then again immediately before releasing to market in a true production environment.
9. Which UI/UX do you design for first? Tablet or mobile phone?
Your creative director will have a strong influence in this decision but he or she will need to know what the strategy is and what the current situation of the front-end developer(s) skill set is like. After you finish answering 1-8 above, this should be an easier question to answer. Tough to suggest how to shave time for this decision, typically a mobile phone app has less functionality and features and the creative design could have a shorter lifecycle with less UI/UX flexibility.
10. Notifications and alerts
Be very cautious of what automatic notifications are triggered by the app and are not configurable for the end user. There is nothing more annoying to a mobile user than getting notified of items they do not care about. This could make or break the success of your app and should be tested thoroughly by your QA team prior to releasing. Shave time by not adding any notifications or alerts until your end-users request for it.
I encourage my reader to share experiences related to any item above that would be helpful to all of us and/or submit additional items to include for considerations. Remember, every project is different and each company has their own strategy. This is just a guide to cut through the distractions and prioritize your precious time on the important things that to prevent an ‘Oh No!’ moment after releasing to market.
Assumptions to this perspective: Agile environment, fixed target date, new product development, no roadmap yet, no clients yet, SaaS mobile and market research is slim. In this first release, it is more about building a reputation for your company in the mobile space and proof of vision stages. Note: If you don’t meet all the items above, these considerations are still useful for all Product Owners.
Releaseplanning: A collection of user stories that is, at minimum, acceptable to market or meets the needs of internal initiatives. Best way to maintain a release plan is to get the software in a state in which each sprint produces release ready software and have a potential end user that will help decide when it is show time for the app. Do not accept user stories that are incomplete!