In the mobile world, we live in an alphabet soup. There are more acronyms than you can shake a stick at, and once you figure out what the acronyms stand for, you have to figure out what they mean. When you start to look at the list -- BYOD, COPE, MDM, MAM, MIM, EMM, MEAP, MADP, TEM, MRM, CoIT, and MEM -- you quickly realize there's a bunch of terms that mean different things to different people. In some cases, these are catchy phrases that when abbreviated might make it easier to write a 140-character message on Twitter. In other cases, the terms are made up so that a company can market its purported expertise over that of its competitors.
In the end, though, all they succeed in doing is dragging the focus from where it really belongs to the shadowy corners where they can air their laundry list of expertise. There is always a solution seeking some problem.
The dirty little secret that everyone avoids is that in this mobile world, you really only need to care about a few things: the user, the need, and the data. Everything else is superfluous. Once you understand that, mobile becomes much easier no matter what type of company you are. As the saying goes, "How do you eat an elephant? One bite at a time."
Let's take a deeper look at these pieces:
- Start with the user. This can be your employee or a consumer of your product. In either case, the user is the person who will work with the mobile device and whatever app you happen to provide.
- The user accesses that app because doing so fills a need. That need may be for entertainment (a game or a media app, for example), for directions to a place or restaurant, or for work (to accomplish something that gets the job done).
- Whatever the need is, you fulfill it is by providing the data that the user wants -- when and where they want to get it. You do this by building apps that allow the users to handle the data in whatever way they see fit.
You succeed based on how well you fulfill the user's need. You can build a great app that enhances users' flexibility and agility compared to how they formerly did things, or you can create a crapplication that makes them want to do anything but use your app. It all revolves around how you present the data that the users want and how you let them manipulate it. It's about their user experience. This determines whether you are a success or failure.
Notice I haven't said a word about who owns the device, how you manage the device, how you build the app, or even what type of technical experience the users have. I concentrated on fulfilling the needs of the user the best way you know how. This doesn't mean that you don't need a way to manage or secure this experience -- those are all parts of satisfying the need. As for the data, it is your asset, so you want to make sure you can protect it while still allowing the users to apply it when and where they need to.
The trick is to stop approaching mobility from a device level and working your way down to the user. Instead, you need to work your way from the data that is needed on up to the user. When you take this approach, the likes of BYOD and COPE have only small consequences. MEAP, MADP, native versus HTML5, and so on all work themselves out because you started with the data and the need. You built the app based on the requirements, not the other way around. You thus avoid building a fancy doohickey that becomes a crapplication because it tries to be everything to everybody.
Sooner or later, you need to stop looking for that special something everyone is happy to sell to you by throwing the latest acronym at you, and instead figure out what it is you're trying to accomplish. The goal is to make your users flexible and agile by giving them the data that they need, when and where they need it, with a kick-ass user experience that makes them more productive. So stop worrying about the alphabet soup and start worrying about your users, their needs, and what data they require to get there.
This article, "BYOD, MDM, COPE — don't drown in mobile's alphabet soup," originally appeared at A Screw's Loose and is republished at CITEworld with permission (© Brian Katz).