A few things every new mobile product manager should consider
hen creating a product strategy and roadmap for a product, it is always important to consider the platform that consumers will be using to access the product. For most SaaS-based companies, this will be through the desktop experience. However, as mobile phone growth has skyrocketed and increasingly become central to one’s daily life, there are important specific considerations to be taken with mobile apps. Below, I will highlight a couple of key points for a new mobile product manager to take into consideration.
PLATFORM PERSPECTIVE
One of the hardest experiences for mobile product managers — especially those who have prior experience elsewhere — is adjusting their perspective to help suit the target platform. Designing and creating features for the native app experience is completely different from designing and creating features for a website. While there may be many similar functionalities, mobile product managers should take a “mobile-first” mentality to focus their design and creation of features.
For example, a homepage on a website can have a variety of banners that lead to different areas of the experience. Simply cloning this into a mobile app wouldn’t make sense. Mobile users are more interested in short-form content, and there is limited screen space, so the top of the mobile homepage might be different from a web homepage. Additionally, the navigation concepts can vary as well. On web, a dropdown menu might make sense, whereas on mobile, it would be a drill-down into another menu screen. There may also be different accessibility issues, such as disabled pinch to zoom, or mislabeled elements that can affect voice over. Having a “mobile-first” perspective will help any mobile product manager design, implement, and deliver a best-in-class mobile experience.
RELEASE PROCESS
To begin with, the release process of any feature, updates, changes, or bug fixes is completely different. In a typical web-based experience, one can make changes and immediately have them go live after testing. For apps, however, it is a completely different process. When the feature or change is ready for update, a new build has to be directly submitted to the App Store for approval. On average, this can take anywhere from eight to 48 hours. Apple has made some efforts to standardize this, but there can be a good degree of variance. If there is something in the submission that causes the build to get rejected, then one has to resubmit the build (leading to a lag time of a couple of days, and also commanding more effort/work to fix and resubmit). After approval, there is a phased release process. The phased release process is managed entirely by Apple, and will go out to an increasing number of users who have automatic updates turned on (typically the majority of users) over a seven-day period (1, 2, 5, 10, 20, 50, 100 percent over seven days).
It is important to remember and plan for this release process because it means that one would typically want to manage release cycles and launch dates around this delayed process. If there is a hard deadline or emergency, it is possible to immediately push an update to 100 percent of users through the app store interface, but this significantly increases the risks of being able to respond to critical bugs. A phased release process was implemented by Apple in order to allow for monitoring of any critical issues with minimal risk. This way, even if there is a critical bug, it would only affect a small percentage of users instead of all users, allowing for time to triage and fix the bug before any significant problems appear.
Furthermore, there are also users who may not be on automatic updates, meaning they will not see any new feature or bug fixes until updating the app. For these users, it may be prudent to have customer support recommend that they update the app when they experience problems, or for a particularly big redesign/change, leverage a forced update for any user who is using the app. This is not always an ideal experience for a customer, but may be needed depending on the scope of a bug fix or feature change. Because the mobile release process can be so different from a desktop/web platform, it is important for any mobile product manager to get up to speed on the release process in order to plan for, adjust, and coordinate the timing of updates.
PRE-PERMISSION MESSAGES
Permissions are very important in the mobile experience. Not only do they protect the user’s privacy, but they also can enhance the user experience (e.g. can take photos) depending on how a feature is implemented. Having the proper permissions can allow for wider adoption of a feature, or increased engagement on push notifications. However, what many people do not know is that the iOS system only allows for surfacing the dialog box of permissions once (pictured below).
Once a user has clicked “don’t allow,” the dialog box prompt can never be surfaced again. The only way to enable permissions is to guide the user through a tedious, multi-step process. The solution around this is to begin implementing pre-permission messages. A pre-permission message allows for a customizable in-app message to appear (typically during initial sign-up, but it can be surfaced elsewhere as it makes sense) that asks the user to opt-in to the permission. The pre-permission message also gives an opportunity to explain the value proposition of opting in (e.g. enhanced functionality). From here, after a user selects opt-in, the iOS system dialog box can then be surfaced. If a user decides against opting in, then simply don’t show the dialog box, thereby saving the “one-shot” of permissions for a later day!
Ultimately, it can be tough to transition from thinking about a desktop platform to a mobile one. This article doesn’t begin to cover everything, but I hope it gives some basic insight on where to start and things to consider before a product build.
___
by David Wang
source: built in
