3 common questions about mobile strategy deployment

I meet with our clients and prospects frequently to discuss mobile trends and possibilities and I really enjoy these conversations.

Talking about the new and exciting things going on in the mobile world is a lot of fun, mostly because we’re talking at the 50,000 foot level and are safe from the chafe-causing regions where the rubber meets the road.

By the time the conversations get down to ground-level and actual functionality, design, and implementation strategy are being discussed, there are usually a lot of “navigators” and one very lonely and scared “pilot” racing along a few feet from reality trying to avoid the ditch on either side of a successful path.

I’m not trying to paint a completely bleak picture for mobile deployment, but I do hope to propose some sort of logical game plan for getting mobile commerce to work for your company using the right mix of navigation and piloting skills.  To do that, I thought I’d answer three frequently asked questions with some detail what I consider to be the right approach.

So, buckle up and try not to hit the eject button if the conversation gets a little uncomfortable.

Where do you think companies go wrong with mobile implementations?

The single biggest area I see companies make wrong turns is by letting the excitement of mobile lead them down roads on which they are unprepared to drive. Because this is exciting stuff to talk about and everyone knows about mobile because they own a mobile device, so it is normal for lots and lots of ideas to come out about the way mobile could and should be used.

What is less common is for people that set the course for mobile (navigators) to come to the table with a map that shows why a specific route should be chosen.

For example, a lot of companies enter into mobile discussion thinking about implementation technologies before they even discuss functionality. I can’t even count the number of times these conversations have opened with statements like, “we want a native mobile app” before there is any idea what the company needs to offer to the customer.

Sure, there are many reasons to go down the native iOS or Android road but it begs three other questions:

• Is the right road to get to your customers? Research what types of functionality your customers would use on a mobile device and then figure out the right technology to deliver that functionality.   The most basic and necessary mobile commerce functionality for a smartphone is search, product info, add to cart, and buy.  Trying to duplicate a complex web site by assuming your customers need everything that’s on your web site delivered in a mobile context is like saying you want to hike the Appalachian Trail and bring along everything you have in your house.
• Do you have the proper equipment (skills) to be driving on that road?  Once you know the functionality that you want to deliver, it’s time to choose the technology with which to deliver it. Think beyond the first release and make sure you ready for what each release requires over the next several quarters, at least. Also, ensure you aren’t making technology decisions without considering the impact to your internal staff, whether they will develop the app or just support it.
• Can you drive to the end of that road without pulling over?  Giving the mobile product manager (the pilot) the authority to get all the way down the road to a first release without multiple navigators tugging at the wheel is easier said than done. In a mobile context getting core functionality to the customer is important. Once that’s done, start working on the next release. Mobile implementations are not stagnant; they flow. Understand the path to success is a road and not a parking lot.

Should we develop mobile web or native apps?

The implementation technology decision is an impactful one, indeed.  When an organization sets up no criteria for development based on customer need, company requirements, and in-house skills, this can descend into a fiery internal techno-feud that would send Hatfields and McCoys running for cover.  The truth of the matter is that almost all mobile functionality can be accomplished with any method. There are some things that are not possible (yet) in a mobile web context on some native devices but as technologies advance these are becoming fewer in number.

Native apps tend to be more responsive and you’ll have complete access to the device’s capabilities.  However, getting your app on an app store can take more time that you’ve planned on.  When going native, make sure you plan for ample approval time so that you don’t schedule a marketing campaign around a new app that hasn’t been released yet!

There are numerous “hybrid” approaches to development and two of my current favorites are Trigger.io and PhoneGap.  Essentially these apps allow a development team to write code in HTML/CSS/Javascript and package this in a native application for multiple platforms.  Armed with this combination there’s little a web development team can’t do that a native app development team could. The gap is narrower now than ever and if your requirements aren’t screaming native in it’s purest form, you should at least consider this hybrid approach. 

What is the next big thing in mobile?

In an earlier blog post on predictions for 2014, I called out several items pertaining to mobile that I think we’ll see develop rapidly in the coming months. The biggest of these will be the proliferation of mobile payments.  When offering a mobile commerce experience, it is extremely important to offer the customer a convenient and secure way to pay. As pointed out in a recent blog by a colleague, if users can’t pay easily, they won’t pay at all.

The second important item in mobile payments is that, when done correctly, consumers can be more protected from fraud by isolating sensitive credit card information to a few parties. Making sure to have these options available and easily used is one of the most important things, if not the most important thing, to consider when rolling out mobile functionality.

Regardless of whether you’re pursuing mobile web, hybrid, or native applications, this can be accomplished in any approach without tremendous difficulty.

This is a great time to be involved in mobile technology! It’s exciting for our clients, for their customers, and for people like me who love aligning technology and business.  All that excitement can lead to some circa 1999 irrational exuberance unless efforts are made early on to agree on an approach and criteria for going mobile.

This means having the difficult conversations with navigators and pilots and making sure the road is understood. Otherwise, bring boots and shovel and get comfortable with the idea of digging out of a ditch.