These days everyone talks about the “Mobile First” or “Mobile First Strategy” in the context of the consumer apps and enterprise apps. Many think that Facebook is the one that publicized this strategy especially when they put big bets on the Mobile usage and hence mobile ad revenue. Of course, not every company is in social space and not you may not even develop apps in consumer space.
Increasingly, enterprises started to take the mobility as the serious endeavor and by now most enterprise software companies have developed the apps in-house or partnered with 3rd party app developing companies. Idea is simply to provide best user experience on the mobile devices; be it smart phone or tablets. The bigger challenge everyone struggles is how to provide value in a way that you can monetize your mobile apps. In the consumer space, companies can provide free apps and later gain the value with the help of in-app purchases, advertising and other viral marketing techniques. Unfortunately, enterprise apps can’t do the same and the amount of R&D spent on these apps is significant to ignore the costs. These costs somehow have to be built into the product pricing and still providing options for the users who do not want to use mobile solutions. Based on my industry observations and experience, below are key components of a “Mobile First Strategy”.
Industry Trends: Most of the enterprise applications serve a specific industry. It is important to understand how open is your industry to the mobile adoption and if going mobile would add value to that industry? More often you get a sense of the industry trends from the analysts, conferences, and customer demands. Also, remember to differentiate the mobile demands from your customer’s IT department and the real end users. It is not to say, if your industry is not going mobile, you should not invest in mobile apps, but the chances your success is more when the industry and users are ready.
Usecases / Users: If there is only one thing that you could focus on in this list, I would suggest you do a good job of evaluating your usecases and users for your mobile apps. As an example, if a specific usecase has a “heavy data entry” operation, making it mobile may not make sense. On the other side, if the usecase has a lot of “data consumption” by managers (like graphs, progress reports), it might be a perfect fit for going mobile. While identifying the usecases, you must also know who the users are. Is your user a mechanic using the smartphone to update his task at the work site? Or your user an executive who is always on the go and wants to see the project progress on his tablet?
Technical Architecture: Strategically it may make sense going mobile, but it may not be fun for the engineering team to march on the “mobile first strategy”. Especially if your product is not built for mobile. Or in other words, if you have a old technology stack and is too difficult to rewrite a “mobile consumable web services”, your engineering will hate your idea of going mobile 🙂 Of course, it’s not the question of “can you re-write your product” to mobile enable but its the question of “does it make sense to re-write”. e.g. some traditional products built on a complex n-tier architecture may not be good candidates to re-write and expose services as RESTful services. Typically you would end up rewriting presentation and/or middle layer to keep clean. Make sure that you factor in the technical architecture of your product(s) before you get too excited about mobile.
License Mechanism: Everyone faces the same question. Should the mobile app(s) be free or should you put a price tag on each mobile user. Is it appropriate to differentiate the Mobile and Web users? Clearly, you need to understand the customers and the Mobile value to the end users. If you get this part right, it is easy to decide if you need to put a price tag on the mobile App. If Mobile is a major channel for users and the value deminishes too quickly without this mobile solution, then you may be able to put a price tag. Else you might have a hard time explaining why you have a price tag >=$.01.
Release Speed: Remember that the applications on the two major mobile platforms – Android, iOS – have an average release cycle of 2.5 to 3 months. This includes the complete development, testing and deployment cycle. Is your organization ready to take on the quite dynamic release cycles? Not only that the release cycle is short, but people expect that you release as quick as possible.
Native vs Hybrid vs Mobile Web: This is a never ending argument. if your users simply wants to access the information from a web browser, you can chose the Mobile Web. users simply loginto the system via browser and mostly interact the same way you they would do it on the laptop or desktop. HTML5 has pleasantly evolved over the years. Based on your need HTML5 (JS+CSS) may be the best option to provide some of the on-device capabilities and also rich user controls. The clear advantage is that you will be able to run these Apps on multiple platforms using cross-compilers. Lastly, If you want to provide a rish users experience and a complete handle on the on-device features, Native App may be the best one. The decision to chose one or the other probably decides how the market will perceive the product. You want to decide and do it right.
Device Selection: Every organization has limited resources to put on a single project. For that first mobile App, you need to focus and a single device and probably single form favor. What should I select between SmartPhone and Tablet. What screen size should i support? These questions have a greater relevance so that the engineering has good time to think and architect the product. Indirectly, the Usercases and Users you selected should hint on what kind of devices to use. Based on If App is used mostly for “Data Consumption” or for “Medium Data Entry/Decision Making”, the decision would change.
Marketing and Sales: Selling enterprise software and going into the customer door steps as domain steps as totally different than putting heads together to sell and market the Mobile Apps. Is the team capable of understanding the mobile technologies and their usage in the customer’s context ? If the App is licendsed, do you know clear value proposition for each release ?
Social and Gamification: There are ways to motivate and encourage human behaviors to do certain thing. With the Social and Gamification features we are able to combine the enterprise software with the social behaviors to motivate the users. E.g. A Work Order specialist (who takes work orders by phone and enters in to the system) services his 1st, 10th and 100th work order and he will be given a Fresher, Starter and Expert badge. The ability to share the work, statuses and documents via Mobile and Web is pretty essential and the underlying platform should take care of that.
Strategy Validation: All the above points are related to internal decision while this one relates to external validation and decision. However good or bad the internal decisions are , the “sexy” application that does not meet customer expectation is of no use. Establish a customer advisory board with key customers who can give you critical feedback and who wants to use this mobile solution. This helps a lot to avoid the later on disappointment from end users.
“Mobile First Strategy” is different things for different people. In my experience, above ten items needs to be considered for a Mobile First Strategy before jumping into the execution. Remember, scrapping a project before it’s even started is much easier than scrapping a project after it’s released 🙂
Image Courtesy : Google Image Search