Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Turning the Tables on 3 Mobile Product Management Myths

DZone's Guide to

Turning the Tables on 3 Mobile Product Management Myths

Think you know how to successfully manage a mobile product? Compare your knowledge with the points raised in this post and let us know if you agree!

· Mobile Zone
Free Resource

Your success as a product manager rests primarily on one thing and one thing only: a thorough understanding of your user.

Sure, your position at the company requires you to act as a linchpin between all departments: development, marketing, sales, and customer success. But the common element underpinning the mission of all these different departments? That’s your user.

  • Your development team should be creating a product that meets the needs of your target user.
  • Your marketing team should be launching campaigns to appeal to that user.
  • Your sales team should be directly pitching to that user.
  • And your customer success team? It should be trying to put a smile on the face of that same user.
  • Mobile product management stands links all company departments

Since, as a mobile product manager, you’re standing in the middle of these different teams, you need to know your mobile app user inside out. It’s the only way you can manage your teams to success at full speed.

The following three mobile user myths, however, may be hindering your path to success. And we need to bust them once and for all.

Myth #1: The Key to Happy Users Is to Build What They Ask For

If you fall for this myth, you’ll end up running around in circles for months on end trying to fulfill pointless (or even contradictory) user requests.

The co-founder of the digital magazine The Next Web, Boris Veldhuijzen van Zanten, found this out the hard way when his company fell for this myth and took requests to build an Android app (in addition to their iOS app) seriously:

“We had gotten enough requests for it and had gotten the impression there were thousands of anxious Android tablet owners holding their breath for an Android version of our magazine. Unfortunately, we’ve found out that although Android users are very vocal, they aren’t very active when it comes to downloading and reading magazines.”

The problem wasn’t so much that the users who asked for the Android app didn’t want it. The problem was that the loudest users didn’t reflect the majority of users.

Reality: You Need to Systematically Process User Feedback

A few feature requests should never guide your app’s development.

Your user base at large, however, can help immensely in steering your app in the right direction. But instead of taking random requests, you need to systematize feedback collection so you can see the bigger picture of what users want. There are many ways to do this:

  • Online surveys: Send a message to all your users asking them to fill out a quick online form. For a greater response, consider offering a reward related to your app or product.
  • Social media: If sending links to a survey seems like too much friction, why not try social media? Your users are already there voicing their opinions, anyway. When the founder of Airbnb, Brian Chesky, took to Twitter in late 2016 asking users what his company could launch in 2017, he got over 2,000 replies in five days. 
  • In-app message: If your app has an inbox or a natural flow for messages, why not ask users about changes you’re considering when they next log into your app? A word of caution, however: minimize the interruption as much as possible to avoid friction.

Myth #2: Mobile App Users Are the Same as Web

The users of your app may all be the same people as the users of your desktop website. But behaviorally speaking, they’re not the same users at all.

Physically speaking, the users of your app may all be the same people using your desktop website. But behaviorally speaking, these people are not the same users at all.

Because here’s the thing:

  • When Johnny logs into the website of his favorite sports team from his desktop or laptop at home, he’s doing so with an ice-cold beer by his side and plenty of spare time to catch up on all the latest news of the game.
  • But when Johnny checks his favorite sports app during a 3-minute break at his desk, he’s only looking for a quick glance at the latest scores, so he knows who to razz and who to avoid around the water cooler.

Same Johnny, different behavior. And as far as good mobile product management is concerned, the two examples above point to different users.

Mobile users are different from web users on two main points:

  • App users are task-oriented. (Quick check of game scores, the weather, flight info, etc.)
  • App users are easily disengaged. (The minute an email pings, a door opens, or the cab arrives, they to put the app away.)

Reality: Users Behave Differently on Apps Than on the Web

The general rule of good mobile UI dictates that mobile tasks should be completed in three or fewer clicks.

And if you want your app to reach that 3-click goal, you shouldn’t distract or delay users with the superfluous (even if relevant) messages and info you give your desktop users.

Mobile apps are a get-in-get-out situation. And, paradoxical as it may sound, the easier you make it for users to flow in and out of your app, the deeper you’ll hook them.

Myth #3: Each App Update Requires Extensive QA Testing

Mobile app users today have higher standards than ever. At a minimum, they expect apps to be fast, responsive, and bug-free. A lot of product managers worry that without extensive QA testing, they’ll get caught in the lengthy app store development cycle, unable to fix a feature gone wrong.

While this was once true, the nature of mobile app development has changed. You can use feature flags to shorten the QA cycle, and test new features on a select group of users, before rolling them out across your app.

Reality: Use Feature Flags to Accelerate Development Cycles

The ability to make quick, iterative changes allows you to learn faster and build a better product.

Dropbox’s Waseem Daher often highlights the importance of continuous iteration over perfection: “If you take a look at the version history of most apps today, you’ll notice that updates come in slow, lethargic releases every few months. Contrast that to the top apps in every vertical, and you’ll find that those top teams are instead releasing every 1-2 weeks.”

Here is version history of Uber’s APK as an example:

  1. Uber 3.129.8 APK (11/28/16)
  2. Uber 3.129.7 APK (11/26/16)
  3. Uber 3.127.3 APK (11/11/16)
  4. Uber 3.127.1 APK (11/3/16)
  5. Uber 3.126.0 APK (10/26/16)
  6. Uber 3.125.1 APK (10/20/16)
  7. Uber 3.124.2 APK (10/17/16)
  8. Uber 3.123.2 APK (10/11/16)
  9. Uber 3.122.3 APK (10/5/16)
  10. Uber 3.121.0 APK (9/27/16)

Mobile apps are constantly evolving because technology is constantly evolving. Don’t waste your time trying to create the perfect feature, before releasing it into the wild. 

Let users get involved. Let users show you what to fix and what to cut. Let your app evolve and improve through continuous testing and iteration. It’s the only way forward in this fast-paced app world.

A Great Product Manager is CEO of Product

As Ben Horowitz, founder and partner at Andreessen Horowitz, writes, “Good product managers know the market, the product, the product line and the competition extremely well and operate from a strong basis of knowledge and confidence. A good product manager is the CEO of the product.”

And that solid foundation of knowledge and confidence around your product can only be built through understanding of your user.

Topics:
mobile ,product management ,mobile app development

Published at DZone with permission of Wei Kuan Lum, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}