Here is one of the many seemingly nonsensical sentences you may utter when you are a Mobile Product Manager:
“It’s 9 o’clock at night. What are you still working on?”
“I’m trying to figure out the difference between Firebase Analytics and Google Analytics.”
It may be to your partner, your roommate, or the bartender at your local brewery. They will all likely respond with either an “oh” or the more dangerous “what’s that?” which they will immediately regret within moments of asking.
You thought building an app would be fun and easy, didn’t you? They do it all the time on TV! It’s got to be easier than decoupling a monolith into microservices! Oh you. Silly, naïve you. While I would argue that no software development is “easy,” mobile app development has a series of unique challenges that are not so obvious at the outset. Without further ado, let’s take a look at some of the trials and tribulations that you are likely to encounter and, with any luck, conquer during your time as a Mobile Product Manager.
#1 – Don’t Read the Comments
“Don’t read the comments” was the first piece of advice that our Engineering Director gave me when we first met. Goodness do I wish I had heard it sooner! It felt like I was posting my first YouTube video. Essentially, the world is full of vitriolic people who find sadistic power in the anonymity provided by the internet. App store reviews are just as gruesome as any YouTube comments section. It’s worse, in fact, because not only can they say terrible things about your app, your product, your baby, but they can also quantify it on a scale of 1-to-5.
The only thing worse than someone posting “this app is a piece of literal flaming garbage” is to attach a “1-star” rating to the end of it. Now, the flip side to this is that if you completely ignore the app store reviews, you will likely miss bugs that have somehow escaped your testing and made it into the wild (more on that in a bit). Do you notice multiple users commenting on the same strange crash, cryptic error message, or UI bug? If so, you should probably investigate that as soon as possible.
Mobile PM Pro Tip
Get anyone, literally anyone, to read through the app store reviews and summarize any recurring themes for you. This should include both positive and negative reviews. At the very least, use one of the many tools out there for app review aggregation. This will (A) save you a TON of time and (B) take the emotional toll out of it. As a Mobile Product Manager, I personally noticed an increase in my daily outlook once I handed off reading the reviews.
Have a dedicated team, even just one or two people, respond to the reviews. At ParkMobile, we were able to boost our replied-to reviews by an average of 1.2 stars. This adds up across thousands of reviews and ratings! Here is a comprehensive guide that I referenced many times when I was figuring this out.
#2 – Be Careful With Delivery Commitments
When you are releasing an update to a web app or a new version of a service, you pretty much own the pipeline. However, for a mobile app, a third party (Apple or Google) has complete control over if and when your app will be available to your users. Their review processes differ, but essentially they are taking extra steps to ensure that you don’t release something trashy, explicit, or malicious into their ecosystem.
Apple claims that “On average, 50% of apps are reviewed in 24 hours and over 90% are reviewed in 48 hours.” However, if you are down to the wire on a release deadline, one or two days of delay can hurt a lot. In addition, if your app is rejected for any reason, you’ll need to remedy the cause of the rejection and then start the review process all over again. Guidelines for the process can be found here (Apple) and here (Google).
Mobile PM Pro Tip
As a Mobile Product Manager, it is your responsibility to communicate timelines to key stakeholders outside the development team. However, make sure they understand that your team can be held accountable for hitting the date for submission to the Apple App Store and Google Play Store, but timing after that is out of your control.
Mitigate risks by ensuring you have a backup plan in place in the event of a rejection. At ParkMobile, we have a “release captain” assigned to every app release that is responsible for keeping track of the review and notifying the team of any issues. Concentrating responsibility like this allows the team to focus on their next chunk of functionality without distraction and ensures that any issues will be known and responded to quickly.
#3 – Monitor Your Releases
Even without Mobile Product Manager tools like A/B Testing or Beta Releases, which you should use whenever possible, both platforms allow you to release your app in small increments and scale up to 100% rollout. This is your single greatest defense against bugs that sneak past testing. Even with the most comprehensive testing automation in place, a moderate-complexity app can contain any number of issues at the time of release. Beware, if you release immediately to 100% of users and there is a major issue with the app, there is little you can do besides scramble the jets and get a fixed version out asap. Take it from someone who learned the hard way: no one likes this fire drill. It will bring team morale down and draw scrutiny from outside the team.
Mobile PM Pro Tip
Combine the phased app release with a dedicated release captain and a dedicated app review team. Then there’s someone who checks for crashes and someone that checks for bugs. This will give you the opportunity to halt the release at the current percentage should a major issue arise. Ideally this is at less than 10% rollout. Note that each platform handles releases differently. Apple has a standard 7-day phased release schedule for auto-update, but anyone can manually update to the latest version by going through the App Store. This also means any new user will be getting the most updated version.
Google follows a different methodology and allows you to manually enter any % of users for the release and increase (but not decrease) it whenever you want. Which users do and do not fall into that percentage is a matter of dark magics that should not be questioned, but only if Google determines that the user is part of the current % will they be able to download/update the latest version of the app.
Before the release, the Mobile Product Manager should specify a KPI target for crash-free users. Then, have the release captain automatically halt the release if the percentage drops below the target. For a mobile application, this target should be above 99.0% unless you are paying down some major technical debt.
2x Bonus Points
Make sure to clearly communicate with your app review team on the planned trajectory of the release. Also, ensure they know new version number as it appears in the app store. Have them keep an eye out for any issues specifically coming from this new release.
Pro Tips for a Mobile Product Manager – Part 1 of 2
This was Part 1 in the series. In Part 2, I’ll provide three final pieces of advice for any Mobile Product Manager. Stay tuned!