The Ultimate Guide to Creating a Mobile Strategy that Works in 2017

Transcription

1 The Ultimate Guide to Creating a Mobile Strategy that Works in 2017 Coming up with a mobile strategy for any company, big or small, is a daunting task. There are so many considerations to take into account, so many people that need to be involved, and so much complexity. This article, however, will show you step by step how to end up with an actual mobile strategy. To expect any strategist to simply outline a plan that is specific to mobile is unrealistic. A mobile strategy does not exist in a vacuum. It is not its own separate silo. It is not an extension of a company s online strategy. And it is certainly not

2 [/vc_column_text][vc_message message_box_color="sky"]step 1 - Understand Overall Company Strategy, Dependencies, and Competitors[/vc_message] [vc_message message_box_color="sky"]step 2 - Define the Enterprise Mobile App Strategy[/vc_message][vc_message message_box_color="sky"]step 3 - Define the Single Product/App Strategy[/vc_message][vc_message message_box_color="sky"]step 4 - Define the Product Management Implementation Strategy[/vc_message][vc_column_text]And if you'd like a little hands-on help for corporate planning sessions, check out our detailed Mobile Strategy Checklist at the bottom of this article. Step 1: Understand the overall company strategy, dependencies and competitors before creating a mobile strategy

3 The company strategy will drive your overall mobile strategy. In order to come up with the necessary information that will allow you to define your mobile strategy you need to understand and document where your company is, where your leaders want it to be, the market conditions it operates in, the strongest competitors, the customer journey, the strengths, weaknesses, opportunities and threats your company is facing, as well as how mobile as a touchpoint can become an asset to the company. The importance of this initial phase in the overall process of defining a mobile strategy cannot be overstated. It is the foundational element for your division to be successful. At this phase, it is critical that you engage stakeholders from various parts of the organization to get the best understanding of the current processes and priorities of your company. Start by engaging stakeholders from the Marketing, Operations, Business Development, Logistics, and Account Management teams at a minimum. Expect to spend at least 2-4 weeks working with key people in your organization to map out these touchpoints, strategies, and mandates. As you re looking at your company s overall strategy, these are the key elements you need to focus on:

4

5 Document your company s strategy, key performance indicators and target goals for the next five years. Don t think mobile or online; think as big as you can. What exactly is your company trying to achieve? If your company is led by experienced leaders, you should be able to get answers to the key questions that will be driving your mobile strategy. 1. What is the mission of the company? 2. What do you believe in? 3. What is your objective? That is, what is the final outcome your company s strategy wants to achieve? 4. What is the scope of your strategy? 5. What s your competitive advantage? Your goal is to understand your company s overall strategy and its annual key performance indicators. You need to understand and document how your company is generating revenue today, through what funnels, and its overall portfolio of products and services. In addition, you need to understand its plan to increase and/or maintain its revenue targets over the next 1, 3, and 5 years. This is in order to ensure that the mobile strategy you develop will be in step with your company s overall strategy as a complementary tool. In short, you want to be able to articulate the definition of success as it is currently seen at the highest level (C-suite) at your company so that when you come up with a mobile strategy you're able to measure against the same definition of success as your executives Mobile strategy is not an extension of the online strategy. F t j t d t d h

6 Typically, executives hired to drive the mobile strategy only look at the digital team s strategy. However, this is incorrect because the mobile strategy is not simply an extension of your online channel. Customers expect a mobile app to be more than a website. An application is something very intimate in many ways; it s something you actually take the time to download on your phone, which will take both real estate and memory on the customer s most precious device. Alternately, a website is something a user can abandon once they re done with a task. And so, by definition, your mobile app must have more value than a website. It must make the customer believe that they can interact with your company, on a repeat basis, in a way that ensures their lives are better served by having your mobile application on their phone than going to your website. The best way to be valuable is by understanding how the customer actually interacts with your company today. Literally the end-to-end process. Once you know that, you

7 This is great not only because your mobile team will actually understand the end-toend flow and how your business operates but also because in doing this exercise you actually put the customer first (versus just pompously claiming to do so). Let s look at a very simple example: Source When done right (most companies never really bother to do this organically) you get to understand the various gaps between channels (offline, phone, online), departments (sales, fulfillment, online, customer service), and business processes. As you can see in the above example, the sales cycle worked, but the fulfillment of the order was delayed only to be saved by an in-store experience and great customer service. When engaging in this process you will already be able to start thinking about A) the touchpoints in this end-to-end process that can be added to your mobile application, and B) how and which of these touchpoints can be better served by your mobile application. For instance, if I saw the customer journey mapping above, as a mobile product manager I would already be wondering: 1. How would I show order status on the mobile app? 2 How would I notify the user in app that there is a delay in shipping for these

8 The app must offer the user everything the web does and more so that users have an incentive to download the app onto their personal devices. Additionally, there are mobile-enabled features that are by default providing a much better experience on smartphones than online (geolocation, notifications, data capturing, etc.). For a detailed analysis of these features, take a look at our >Mobile App Development article Mobile is not a channel. It is a touchpoint through which customers can quickly interact with your company in a convenient and seamless way. If you went through the process of understanding the mission/vision/strategy of your company as well as the customers journey in their relationship with your business, then you will understand what mobile really is. It s not (just) a platform. It s not (just) an extension of the web. It s not (just) a funnel. It s a touchpoint.

9

10 Perhaps the biggest disconnect in the world between customers and businesses is just this: a company looks at mobile as a channel mobile/online/in-store/call center. Customers don t think about it that way. We just think in terms of wanting or not wanting to interact with a business wherein mobile is only one of the touchpoints and, increasingly so, the most convenient and natural touchpoints of all. To that end, mobile becomes an enabler for your company a way to wow your customers by helping them get whatever they want from you as quickly, efficiently and smoothly as possible. As such, when you re drafting your overall strategy you must understand how all other touchpoints fulfill the customers needs and internalize the reality that your mobile strategy will be just another touchpoint - but preferably one that is slightly faster than the rest Understand who you re competing with. Document and analyze what your competitors do well and what they do less well, so that you can define the market baseline before your team creates a great app.

11 Conventional wisdom states that after you went through the three steps outlined above you should focus on setting specific mobile business objectives for your application. That comes a little later. Instead, I suggest you first focus on what your competition does. Why look at competitor's strategy before building your own strategy? 1. Analyzing what the competitors do will most likely reveal a common set of best practices that will make it to your list of features and functionalities anyway. So why do this work in a vacuum when this analysis can reveal it for you? 2. When doing the analysis, you will inadvertently discover things your competitors do poorly. Jot those down as ways you can surpass the competition. 3. You will also discover things your competitors don t do at all. Make note of them too as they may very well help you differentiate yourself from your competition as soon as you launch your application. This is why some startups

12 because nobody else was doing it well at the time. Once this analysis is done, you should have something like this in front of you before you draft your own strategy: A different view of your competitors comes from simply creating a spreadsheet of your competitors apps where the team would rate them by 'good', 'bad', and 'very bad' practices. For example, you can simply look at the navigation menu for all your competitors and split them based on best/good/worst navigation. At Y Media Labs, we call this the experience brief. In doing this exercise before outlining your strategy, you should be able to highlight and consider: 1. What your competitors are offering through their mobile channel 2. What you re going to offer 3. What you re NOT going to offer 4. How what you re offering will be different and, yes, preferably better than your competitors 1.5. Define the Strengths and Weaknesses as well as the Opportunities and Threats that can help/prevent your product

13 After you've done the competitors analysis but before you actually start defining your mobile strategy there is one last step you need to take: a SWOT analysis. SWOT stands for Strengths, Weaknesses, Opportunities and Threats it s an analytical framework that can really help you define and overcome the biggest challenges your company is facing and be aware of all the forces that can influence your success or failure. By now you know what your company s strategic direction is, how your customer is engaging with your company, how mobile fits into your internal organization s ecosystem, and what your competitors are doing in the mobile space. The competitor analysis already positioned you for success by identifying the external threats and market opportunities. But you need to also look at internal factors that will impact your mobile development. For example, are the internal policies, business rules and processes created in such a way that you can achieve success when implementing a stellar mobile strategy? Is the infrastructure of your company able to add a mobile presence? Do you have the infrastructure to support the traffic of your mobile app? Even if you re expecting a small amount of traffic post-launch, bad app performance will deter even the small number of users and could easily set up your

14 Source What s great about this exercise is that it makes you self-aware of all the different factors that can impact not only your mobile strategy as a whole, but ultimately the success of your company. And most importantly, your mobile strategy will be directly impacted by this analysis. For example, if internal dynamics are such that not all stakeholders are buying into the need for a mobile strategy, then in your first year s plan KPIs and deliverables would look very differently than in a scenario where the C-suite fully supports the initiative It also helps you define a mobile strategy that is

15 Step 2: Define your Enterprise Mobile App Strategy Once you've clarified the overall company strategy and dependencies, as well as worked closely with various stakeholder groups, you are now finally in a position to think about the overall Mobile Strategy for your team. At the highest level you will need to focus on the use case(s) for your mobile application, the resources needed to execute your idea, and the technology stack need to ensure the program is a success Define the elevator pitch idea that will drive your mobile strategy

16 you re already dealing with stark competition, limited resources, tight schedules, internal limitations, and an increasingly demanding mobile user base. So the more you re trying to do, the less likely it is that you'll do all those things in a manner that is acceptable to all your internal stakeholders and current/potential customers. Your entire mobile strategy will hinge on getting this right: what is your company s idea of what the mobile application should be in order to be successful? This is a two-fold question: 1. What s the idea? 2. How will this idea benefit the mobile user? Your idea must be simple, concise, memorable, feasible, and inspiring. Becoming bigger than Amazon in overall sales is probably neither feasible nor concise. The best format for your strategy is this: we will build this so our customers can do that. It is the big 'what' followed by the big 'why do I care.' It is preferable that this idea is long-term, yet realistic. Your C-suite must be able to imagine the possibility that what you re suggesting as a strategy can actually be accomplished. It is visionary, yet pragmatic at the same time. Additional critical components of a great mobile strategy: 1. Your idea must tie in nicely with your company s overall strategy for the next few years. 2. It must be delivered within the budget and timeframe you commit to. 3. You must account for contingency plans (what if things don t go as expected, and what s plan B?) 2.2. Work on building the mobile roadmap Now that you have your overall idea clearly defined, you need to break down the idea into all the different components that will need to be executed in order to deliver

17 measure used by teams following an agile methodology that can vary from one company to another from 1 to 3 weeks. This is what a typical roadmap looks like: Source A roadmap is basically a visual timeline for your team that can be used to communicate milestones to stakeholders outside of the development team, but also to ensure there is alignment between your company s overall strategy for any given year and your product deliverables for that period of time. Because a roadmap simply represents project X time for any given deliverable, it can periodically change due either to a shift in priorities or because a certain deliverable took more time than expected. However, for mature companies, 80% of the roadmap is expected to remain more or less the same for the year Document the resources and budget needed to execute your mobile strategy

18 Once you've identified the elevator pitch idea, which is ultimately your strategy, you need to understand what it will take to deliver it. You typically have two types of expenses: capital expenses (headcount) and operating expenses (infrastructure costs, platform, licensing, software, etc.). Your biggest investment will be in people, and one reasonably expects the costs to be higher for the first year when trying to deliver the first version of the app, and then to decrease over time as work is more focused on optimization and adding other functionalities. A multi-year budget plan is probably the best way to go about this. Of course, the budget will influence how quickly you can deliver the MVP as well. After all, if you need 20 developers to deliver MVP in 6 months but you only get funding for 10 then your revised estimate would be that MVP won t be delivered for one year. Additionally, once the budget situation is resolved, you can focus on the actual roadmap, to which we turn next.

19 to account for software and hardware costs tied to running your app. But there are a lot of other considerations you should take into account and work with the IT team to ensure that the underlying technology is in line with the business goals of the mobile app. Most of the things you need to settle are called, generally, 'non-functional requirements.' These include, but are not limited to: 1. Network readiness 2. Data access points (secure user authentication, tokenization of information passed over the network, information storage, data management, etc.) 3. Overall security solution (data encryption and payment processing security) 4. Management of the bandwidth extended to mobile users and the costs tied to it 5. Architectural support and maintenance costs 6. Performance monitoring tools (ensure your app is actually up 99.99% of the time and that each page actually loads in an appropriate timeframe 5 second page load time ain't nobody got time for that!) 7. Network load balancer to ensure you can manage concurrent users in a reliable way 8. Define clear SLAs for the overall performance of the app and make sure the IT team actually signs up to them. Consider uptime and downtime for the app, backup policy, disaster recovery, response time, processing times (how long is it acceptable to see the 'spinning wheel of death' on the app), acceptable query time 9. Content Delivery Network, which will deliver content to the user based on their geographic location and the origin of the homepage You may not think of these issues as you re using apps but the reality is that these are critical to the success of the app. In addition, never take for granted that the IT organization will do the due diligence and proactively define the standards. If I had a nickel for every engineer who asked me, "what s the big deal, it s only taking 10 seconds to load," I d be very rich by now. This is a great example of a typical mobile enterprise technology stack:

20 Source: Mentor Europe Blog The bottom line is that nobody will care about the app as much as you do, and therefore you need to clearly document and establish internal alignment to ensure that, beyond the awesome look and feel and functionality, the app actually performs seamlessly Choose agile development over waterfall development as a core component of your mobile app strategy

21 it with the understanding that any changes after the original design phase will be cost-prohibitive and avoided as far as possible. In this methodology, everything goes through a stage gate approach: you first define the requirements, then you design based on the requirements; you implement the design; you check that what you implemented matches the design; you release and maintain the code. In this methodology, everything is rigid and only what was agreed to upfront will be executed. Additionally, projects get delivered in large chunks - often multiple projects touching the same flows come together and they all get delivered usually months away from when requirements were first discussed. In an agile methodology, the ultimate imperative is that requirements and business needs and solutions ultimately evolve over time through team collaboration, learnings from current customers, data points, and other forms of insights. Because requirements change all the time, the best way to develop software is through an iterative approach: you define the quickest way to deliver what the customer wants, and then you develop it as soon as possible (MVP), launch it, test it, and if need be, make subsequent iterations. The goal for teams following the agile methodology is to deliver as often as possible, even as often as every two weeks. In following these principles, agile teams are more likely to adapt to changes quickly and embrace new challenges without being constricted to the predefined timeline that the waterfall methodology adheres to. At the highest level this is how the two methodologies are different:

22 Source: Again and again, the agile methodology has proven significantly more efficient and productive than the waterfall methodology. Reacting to customers constantly changing needs and providing easy solutions to their problems is always better served by a methodology that embraces change instead of fearing it. In addition, agile teams usually adopt a 'can do' attitude versus following rigid processes that have been defined in a vacuum. We suggest that adopting an agile methodology should be one of the core components of your app strategy and mindset!

23 Product/App Strategy 3.1. Create your product strategy by defining clear use cases based on the customer journey You know what the end goal is now. You know who your users are. The next big question is, what would it take to deliver on your idea? There are many great ideas out there that fail. It s not the ideas arena where strategists/executives fall short. It s the lack of a reasonable and actionable execution plan that causes the demise of many (most!) great ideas. Once you ve outlined the overall mobile strategy and rallied internal stakeholders, you need to clearly lay out the process/plan through which you will deliver on your strategy. The first thing you should do as a team exercise is define all the pieces that will

24 Now that you ve documented everything you can think of you need to ask yourself what the specific use cases you want your app to excel at are. In an interview with the Business Insider, Y Media Lab CEO Ashish Toshniwal had this to say about use cases: The number one secret is to focus on one or two main use cases. Let s not overwhelm the user, but really focus on one or two use cases and do them really, really well. [Source] If you think about it, this is the secret behind most successful apps. I use Lyft/Uber when I want to get a quick ride, Shazam when I want to know what song is playing at Starbucks, Groupon when I m looking for a restaurant deal, Instagram to share pictures, SpotHero to book a parking spot, and so on. The most successful apps are like great credit cards. When I open my wallet, I go directly for one specific credit card. It's the same with great apps. I need/want something so I go for a specific app. If you nail down your app s primary and secondary uses in such a way that the customer s mindset is to always go to your app when accomplishing a task, you re setting yourself up for success Define your target audience who is going to use your app and why?

25 It s natural for everyone working in software development to simply think of its customer base as a potential user of the application. But the reality is that there is no such thing as 'one user'. More importantly, when product managers start defining requirements, they will naturally define them with their understanding of what 'the user' needs, often making themselves the user for whom the app is built. Depending on how experienced a user the manager is, this proficiency will be reflected in the end product. At the end of the day, the real problem is that you re building your app for a variety of user types. Knowing what these user types are in advance will help you more accurately define the functionalities your app should build for. This is where personas come into play. The best way to do this is through a workshop with stakeholders from your organization. When you bring internal people to the table with their experience at the company, but also with their various degrees

26 old, power users vs. inexperienced user. Another way of thinking about personas is frequency of engagement frequent users (who use the app every day/week/month) vs. recurring users (who return to your app only once every three months) vs. infrequent users (who only interact with the app once a year). This exercise is critical because it will help you and the team define requirements and create user experiences that will cater to as many user types as possible, thus increasing the likelihood of your app adoption and long-term success. It also forces you to be in the right mindset when you actually end up writing the requirements, which is to build for your most common denominator. This would also help your user experience architects and designers tremendously when building the experience, because they will build their sketches/comps to account for all user types versus building one experience only to then have to change and refactor it based on subsequent data points about users. I once redesigned a cart and checkout experience where the user would see when the product added to the cart would ship from the warehouse. I originally labeled it "Product X ships in [X] days". Most of the users understood what that meant. However, we started getting feedback from a certain inexperienced user type (which I didn t account for) that they understood 'ships in' as the day when it gets delivered, versus the day when it ships. So after doing a round of user testing we changed the verbiage to Ready to Ship in. Despite the subtle difference, this curbed the complaints to the call center and ensured both experienced and inexperienced customers understood. That s where the value of defining personas upfront comes into play. You get to design for the most common denominator and hopefully account for the majority of all user types in the process (rule of thumb: design for 80% of all your user types) Define your data points & Key Performance Indicators (KPIs)

27 Despite being the seventh step in the process of creating a strategy, I personally consider this the single most important task. If done right, you will clearly measure the effectiveness of your strategy against your Key Performance Indicators, thus proving the value of your program to the company. If done incorrectly, you risk either not delivering on your strategy or not being able to prove that certain metrics (sales, adoption, etc.) were the result of your mobile strategy. Despite the fact that there is never a good reason not to have this step clearly defined, so many product managers and programs simply ignore it or do a half-baked job. C mon, don t you want to know if what you re doing is working or not? All mobile product managers and executives should clearly define not only the strategy for measuring the effectiveness of the application/program but also setting specific targets for each year to ensure that what is delivered matches the original target goals. Everyone agrees in theory, but many fail in practice. As a general rule you should try to align your metrics along the following lines:

28 Market share Increase customer satisfaction (NPS score) Reduction in cost to serve (rerouting of tasks to the mobile app typically done through the call center) App metrics: New users Increased usage (we hope to get X sessions after the first 6 months) App rating Lifetime value (is your mobile user spending more? Is he more loyal? Etc.) Retention rate (track the user s app usage after 7, 30, 90, and 180 days of downloading the app and compare his/her engagement on the app versus engagement through other channels) Session Length (how much are users interacting with the app equivalent of 'time on site' measures the engagement of a user with your brand through the app) Active users (monthly active users or daily active users depending on the app a great stat to follow) Tracking data has never been easier with so many tools out there. The secret is to know what to track and to do it well from the beginning. This table shows you just how robust tracking can become for mature applications: Do it well and everyone will thank you for it. 3 4 D t i if d h b id ti li ti

29 Source Once you have defined your target audience and your KPIs (both at a company level and mobile-specific), you need to decide if you re going to build a native or a hybrid application. We wrote a comprehensive article on this topic, which you can access here. In short, we always recommend native applications because they're more secure, allow you to provide the best-in-class user experience, have the best performance, and allow for an offline mode. In addition, it's easier to be found in the app store and you can access the device-specific hardware/software (GPS, location, Shake, Calendar). That being said, if you re in a hurry to go to market you may consider the less optimal approach and build a hybrid application. It has lower origination costs, a faster (initial) speed to market, and you can use one source to deploy the app across platforms (Android and ios at the same time) Determine the first platform you want to build the app on - ios or Android In a separate article, we've covered whether a company should first build on ios or on Android. Generally, you should first build your app on ios because ios users are more likely to spend money on apps and on in-app purchases, the ios platform is easier to work on, and overall it takes less time for developers to deliver the final application. In addition, there are only three versions you need to account for and a f O

30 should build your app first on ios, then use customers feedback and in-app engagement to improve the app, and only then start work on your Android native application Decide whether you want to build your app in-house or if you re going to use an external agency Should you outsource the development of your application or should you hire more people? This is a decision your company needs to make, and there is no simple answer to the question. It depends on your budget, desired speed to market, and the current pool of talent within your organization. In general, if you do not already have a mobile strategy, you should consider outsourcing the first version of your application to an external agency. This is advisable because companies like Y Media Labs already have a set methodology in place and the resources needed to expertly deliver the app on time and on budget. In parallel, you can begin the process of hiring full-time resources (product managers, user experience architects, designers, business/product analysts, developers, testers, program managers). But since fi di th i ht t l t t k ti d b i i l t d l i th

31 app! In general, companies wait until an application is already built before starting their marketing strategy. This will not produce the same results as starting to market your application as it's being built. If you start early, you can engage current and prospective customers in the early stage of the app development process and get their input into what you're building and whether it will suit their needs. Starting the marketing campaign early will allow you to engage with various influencers who can promote your application by word of mouth or through their digital channels even before the app is ready to launch. Finally, we always recommend getting the press kit ready well before the app is live so that you can engage the press and provide great content to generate excitement. Another strategy we recommend is starting a blog around your app and soliciting input around key functionalities and flows through the blog and your marketing social channels (Twitter, Facebook, LinkedIn, etc.). No matter what marketing strategy you employ, you are always in a better position if you start your marketing activities early and continue the conversation with your current and potential customers along the way.

32 Step 4: Define the Product Management Implementation Strategy Once you have successfully defined the what and the how much, the last step in the process is your Implementation Strategy. In short, what you need to define is your overall Minimum Viable Product, the overall project plan, and the standards and processes that the development team will need to follow in order to deliver the project on time and according to your strategy Define your Minimum Viable Product Now you have everything clearly documented or at least outlined when it comes to

33 have other features prioritized after the first launch, with more to come later down the road. A different way to look at it is simply based on priority. You can divide all functionalities based on priority 1, 2, 3. At the end of this exercise you should get something like this: The goal of prioritization is to define the minimum viable product. That is the leanest application you can build which would allow customers to successfully use the app based on your business goals while allowing you time to start developing non-mvp features. These non-mvp features can be based on what you ve ranked as Should/Nice to Have or on insightful data you can now gather from your users who are interacting with your MVP app Define and enforce your non-functional requirements Just as you need to define best non-functional SLAs, you need to ensure that you have great coding practices clearly defined. I won't go into too many details about this, but basically you want to make sure your developers do a good job building the software. One thing I often do with my team is run the HTML pages they build through PageSpeed Insights from Google. Go to this link and enter any page on any website in the world.

34 to their mobile apps. The useful tool analyzes both websites and mobile apps. It is also a simple and very useful way that teaches you to write page-level non-functional requirements and to enforce them with your developers. Some of the common coding practices often not followed by developers include leveraging browser caching, compressing files and images for mobile views, minifying HTMLs, eliminating render-blocking JavaScript and CSS for above-the-fold content Define your Testing Strategy If you work in software development you know this. Some bugs will get to production. And when they do all hell breaks loose. All eyes are on you and everyone expects urgent updates. People become paranoid. They point fingers. They isolate an issue and blame, blame, blame. It doesn t matter how much good work your team did the bug gets all the glory and attention. In order to minimize this issue (realistically you can t really eliminate this entirely), you need to have a very clear testing plan defined even before your developers write the first line of code. You need to be able to define the roles and responsibilities for the testing team, the structure of the test plan and operating systems, and versions that need to be tested. What versions are tested will always stay the same. The only thing that will change from one release to another will be the test cases and the

35 What s in scope What s out of scope Test case: e.g., tap on the search bar, enter 'media', tap 'show results' Expected outcome ios/android OST version for which this is tested and passed/failed Additionally, from a strategic point of view, you should decide early on if your company will invest in any testing automation tools that will run in both your QA and production environments. Defining this early on makes the testers jobs a lot easier and more streamlined. If you go the manual route you still need to ensure you have a clearly defined strategy for how/when tests are conducted, as well as the pass/fail criteria Define the tools you will need to manage your application successfully As you can imagine, building an application is just the beginning. It's not a done deal once you ve submitted your app to the app store. As you re implementing your mobile strategy there are so many tools you need to adopt and implement. For example, most companies nowadays use JIRA to document requirements and track time and progress for the software they build. In addition, once the app goes live you may choose JIRA or TicketNow to document and track any production issues discovered now or in the future. What about tracking the overall business performance of your application? Will you use Google Analytics? Or do you want a more robust tool such as Omniture/SiteCatalyst? Another critical consideration you need to account for is the overall performance of your application. How you re going to monitor, what automatic alerts you want to get, and the overall performance SLA. There are many great options out there such as Dynatrace, Splunk, AppDynamics, and FogLight, to name just a few.

36 your release cycle more frequent you need to ensure that your app is 99.99% bugfree when new versions are launched to production. Investing in QA testing tools like qtest, PractiTest, Test Collab, TestRail or others would go a long way to ensure the application is bug-free when it hits production, and they will also reduce your overhead cost for the QA team Production-ready and post-production support If you ve followed this strategy step-by-step and the universe was aligned in your favor you will get to this last step. The glorious day has arrived. After months of hard work your application is about to go live. You ve done all the testing and all scenarios passed. You ve also gone through the tedious process of submitting your app for release on ios or, if you re on Android, you re going to simply push it to the world. But before you actually pull the trigger and launch your application, you need to make sure you actually have a clearly defined strategy for the following:

37 be reverted? 4. Do you have version control of the app? There are lots of details that go into production support and overall support ownership. All this needs to be clearly called out and documented well before the day comes when you can say hello to the world. Summary: There s a lot to be said about building a great app. It gives the team a great sense of empowerment, and, when tracked correctly, it produces great value to the organization. At the highest level a strategy for building an app is very simple: think big, act small, release, test, and improve. But as we've seen in this article, a good mobile strategy requires a lot of thought, managing many moving pieces, getting alignment across the organization, and coming up with the right budget, resources, methodology, processes and contingency plans. We are confident that if you follow the process above you will be well positioned to successfully build, release and manage your app.[/vc_column_text][vc_column_text css=".vc_custom_ {padding: 10px!important;background-color: #eff9ff!important;}"] MOBILE STRATEGY CHECKLIST Step 1: Understand the overall company strategy, dependencies, and competitors Analyze your company s strategy, key performance indicators and target goals for the next five years

38 Understand who you re competing with Define the Strengths and Weaknesses as well as the Opportunities and Threats that can help/prevent your product from being successful Step 2: Define Your Enterprise Mobile App Strategy Define the elevator pitch idea that will drive your mobile strategy Work on building the mobile roadmap Document the resources and budget needed to execute your mobile strategy Define the technology stack Choose agile development over waterfall development as a core component of your mobile app strategy Step 3: Define the Single Product/App Strategy Create your product strategy by defining clear use cases based on the customer journey Define your target audience who is going to use your app and why? Define your data points and Key Performance Indicators (KPIs) Determine if you need a hybrid or a native application Determine the first platform you want to build the app on - ios or Android Decide whether you want to build your app in-house or if you re going to use an external agency Start your marketing strategy now. Before you build your app! Step 4: Define the Product Management Implementation Strategy Define your Minimum Viable Product Define and enforce your non-functional requirements Define your testing strategy Define the tools you will need to manage your application successfully Production-ready and post-production support FACEBOOK

39