As a lone product manager, I often find myself looking online for what would commonly be part of a meeting or a chance encounter at the water-cooler at a larger company: inspiration. This search for inspiration and best practices has led me to many long hours going down different internet rabbit holes. Last week I came across “8 Key Steps to Building a Successful Mobile App” by Nicholas Wright. The advice in this post seems applicable to every company from startups to established companies who are interested in creating an app. From the business perspective, the post is excellent: start with market research, continue with talking with potential users and figure out a revenue stream and business model.
Step 5 in the post, assemble your team, is a crucial one: finding people who can do the research, brainstorm ideas, and, of course, design and implement the app is essential. I am a bit miffed to find that hiring a product manager is tacked on almost as an afterthought. I may be biased but I see the PM’s role as a bit more influential than Mr Wright implied.
That said, I’d like to offer the PM’s steps to building a successful app, beyond the points outlined in the post. It’s important to have a business model and a concrete goal for the app, I won’t minimize those, but building the right app to meet those goals and engage users isn’t always easy.
From the product manager’s perspective, new apps need to overcome two very difficult steps: awareness and adoption. The odds are really not in their favor. Awareness means to bring the app to the attention of users, which is challenging in today’s abundant app marketplace. As of July 2015, there are 1.6 million apps in the Android store and 1.5 million apps in Apple’s store. Although awareness can be considered purely marketing’s responsibility, that would be a mistake. The product itself can be a great marketing tool if it has useful and easy to use sharing functionality.
App adoption consists of two parts: initial installation and continued use. The price is steep for a misstep as 25% of users abandon an app after only one session. The other end of that chart, retention, defined as opening an app 11 or more times, is only 34%. For PMs this means that an app has to impress the user right at the start and continue to prove their value while not annoying the user as they continue to use it. This seems straightforward but it involves many product tradeoffs.
So, given these unfavorable odds, what can PMs do?
- Be the user, always. Look at your favorite apps with a critical eye, from their app store page, through onboarding, to everyday use. Why did you download this app? What made you use it more than once? How is the flow? What makes you open it and what draws you back? Actually, this is really more than a step in the product management checklist. It should really be ongoing, with every app you use constantly. Look at apps that you like as well as the ones you abandoned, or dislike but continue to use. Be critical, but also recognize the good.
- Be the user, this time with a focus. Focus your research on apps in the same category as the one you are planning. Look for apps that are trying to achieve similar goals, apps from your competitors, and apps that are trying to disrupt your industry. All will have valuable insight and help you learn about what users value.
- Read about best practices, for everything, and don’t try to reinvent the wheel for every interaction. Many different aspects of app development have been written about by the best and most experienced product managers in the business. For example, when looking for best practices in creating the app’s interface I found Google’s guide to good app UI, recommended by Mr Wright, to be extremely useful and very detailed. I also like the argument made by Zoltan Kollin not to reinvent elements of UI that work in successful apps. More importantly, Mr Kollin argues that using common UI conventions that users are already familiar with can make your app use easier for the user and hopefully increase the chance for adoption.
- Medium is your friend. Many of the experienced PMs write about successes and failures of features they designed on Medium. Look specifically on Medium for posts about features you are working on.
- Start with the MVP, minimal viable product, the “product with the highest return on investment versus risk.” For PMs a MVP provides a chance for users to interact with your app and provide feedback before the app heads too far in a specific direction. It allows app development teams to change direction if initial response isn’t what they hoped for and to expand upon features that the users liked. Build additional features on the initial MVP and update with new features as often as necessary while listening to user feedback.
- Get feedback. No, not the virtual kind, but actual feedback from users using your app. Create a small group of testers who like your app but are not groupies, those that can offer meaningful feedback. As an Android developer, I have found that Android offers a “closed alpha” release option that allows only a handpicked group of people to have access to the new app or new release. They also offer a beta with limited release options, such as by country, to help developers stage a release. This way PMs can get valuable feedback on new features without “risking” a full release.
I wanted to connect these ideas to a feature I have been working on for my app, Wrapped Up, recently. After releasing basic functionality, it’s clear to me, based on feedback I have received but also by looking at other productivity apps, that notifications are required for the app. Since the framework I outlined above is one I use constantly, I thought I’d describe how I worked with this framework for this feature.
My initial worry about notifications is one of balance: how do I let the user know due dates are approaching without irritating them? This shaped how I looked at other apps and what articles I sought out.
I decided to look at the big guns: email and social media. First, let me say that I look at the app’s default mode, and even though user customization is certainly available for most of these apps, I decided not to look at that for now. Taking a look at Gmail, I noticed that notifications were only for emails in my Priority Inbox, meaning, only emails that I have previously decided (or that Gmail decided) were important. This made for notifications that were timely (notification when email arrived) and relevant (not for less important emails such as updates.) Gmail also unifies notifications, generating only one notification regardless of how many priority emails have arrived. Facebook, on the other hand, is relentless with notifications, with multiple notifications accumulating on my notification bar. This lead me to disregard all the notifications from Facebook, rendering them completely useless. It did not lead me to uninstall the apps, just to swipe away all notifications. Twitter unifies notifications into one notice with many events, like Gmail.
- My app’s slogan and goal is to help users “get the right gift at the right time!” so I chose to look at calendar for notification best practices. First, I noticed that I was only reminded for events on my calendar, not other calendars I have access to. Second, I notice that each event got its own notification but unlike Facebook, these all were important to me. Third, there is many ways to customize calendar notifications from how long before the event users get a notification, how many notifications per event and even what noise to play for each, if at all.
- and 4. I read several posts about best practices and, guess what, they were found on Medium. I came across three really relevant and recent posts: one discussing effective notifications, another on what makes users opt into notifications, and, perhaps the most valuable for me, future trends in notifications. All were extremely useful in helping me decide how to design notifications for my app. I also learned about the importance of getting this part of the app right: too few notifications and users forget about the app; too many and they uninstall it in frustration. It’s a fine line to walk but walk it a PM must.
- MVP: This was a challenge. After all, there is so much to do to make effective notifications and I had just read about so many different needs to consider. Yet my goal as a PM with limited resources is to get the best MVP that I can. In this case I decided on two main compromises for the MVP: no user customization for notification settings and no action within the notification beyond a deep link to the application. To minimize multiple notifications for events celebrated by more than one user, I decided to differentiate between notifications for personal events and notifications for holidays. After all, users don’t need a separate notification for all their friends celebrating Christmas, just one will do.
- Feedback: still waiting for this but I do know that future tweaks of the notification feature will take this feedback into account.
This is just one example of how I use my PM framework for app feature development. Again I stress that as a PM working alone, this framework is essential to me as I cannot release a new app or new feature without understanding more about users and the market. As a newcomer, I try to toe the line with UI conventions without being overly creative to create a familiarity with the app and reduce friction. Hopefully, there will come a day when I can be bolder with these choices while still creating products people want to use.