March 1, 2017

The Ultimate Guide to Creating a Mobile Strategy that Works

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 “something we have to create because our competitors have one.”

If you want to develop a mobile strategy you need to go down the path of discovery outlined below and fill in the answers to each question sequentially. At the highest level, this is what you need to successfully define a mobile strategy:

Step 1 - Understand Overall Company Strategy, Dependencies, and Competitors

Step 2 - Define the Enterprise Mobile App Strategy

Step 3 - Define the Single Product/App Strategy

Step 4 - Define the Product Management Implementation Strategy

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

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:

1.1. Always start at the highest level.

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.

1.2. Mobile strategy is not an extension of the online strategy.

Focus on your customer’s journey to understand where mobile can become a useful tool for your customers as they interact with your company.

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 can 'intercept' the sweet spot where the mobile application can sit to provide the ultimate amount of value to your existing and prospective customers.

A customer journey exercise is a fantastic way to educate your team about all the steps a customer goes through in their relationship with your company.

This is great not only because your mobile team will actually understand the end-to-end 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:


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 headphones?
  3. What type of in-app customer support would I provide to the user to ensure that in this scenario the customer ends up being satisfied with the overall experience despite a fulfillment and delivery hiccup?

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.

1.3. 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.


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.

1.4. 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.

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 are so successful while innovation rarely comes from great companies. They study the market, they identify something that was missed by other competitors but is really needed by the customer base for that industry, and then they build that out. Think about Amazon for a second. When they went live their mission was very simple: be the pioneer at finding books online, 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 from being successful.

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 app for failure should those users flood the app store with negative reviews.

This is an example of a SWOT analysis done for Microsoft (author is not affiliated with the company, but this is a great example).

swot analysis


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 in line with internal and external dynamics and dependencies.

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.

2.1. Define the elevator pitch idea that will drive your mobile strategy

When I was in high school, I had a great English teacher. I was at an age when I wanted to do everything and get involved in as many extracurricular projects as possible. But Mr. Batrinu would relentlessly tell me one thing: “If you do something, do it well. Do one thing well, then move on to the next big thing.” Your mobile strategy must follow the same pattern. Before you launch your mobile product, 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 on your mobile strategy. In software development, we call this the roadmap. A roadmap is simply a visual representation of all the work the team or teams will do. It is a project plan where projects are spread out based on the expected velocity of a team over sprints or months. If you're wondering what a sprint is, this is a unit of 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:

roadmap example


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.

2.3. Document the resources and budget needed to execute your mobile strategy

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.

2.4. Define the technology stack

So far you’ve defined the what, when, and for how long. When you've done your budgeting for a new application, you've probably done some of the preliminary work 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:

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.

2.5. Choose agile development over waterfall development as a core component of your mobile app strategy

Like many other product creators, I have experienced both the waterfall and the agile approaches.

The waterfall software development approach was borrowed from the manufacturing industry. In the simplest terms, you determine what you want to build, then you build 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:


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!

Step 3: Define the Single 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 make the final product. That includes specific requirements, flows, and features. The goal of this exercise is to come up with a complete feature set for your application. The best strategy is to outline everything you'd want in an ideal world.

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.

3.2. Define your target audience – who is going to use your app and why?

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 of familiarity with mobile applications, you are in a better position to define the various user types you need to design for. This step is ultimately what I would call Empathy 101. You get off your high horse and try to understand the various users that could be exposed to your application. For example, women vs. men, young vs. 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).

3.3. Define your data points & Key Performance Indicators (KPIs)

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:

Company metrics:

  • Revenue
  • 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:

mobile app analytics strategy

Do it well and everyone will thank you for it.

3.4. Determine if you need a hybrid or a native application

native vs hybrid


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).

3.5. 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 more limited amount of screen sizes. On the other hand, Android is the dominant platform with the majority of the smartphone users in the world. Moreover, Google’s app release policy to Google Play is a breeze by comparison to Apple’s stringent and bureaucratic app release policy. In general, we do not recommend companies build their app on both iOS and Android at the same time. Instead, we believe you 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.

3.6. 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 finding the right talent takes time, as does bringing people up to speed, leaving the first iteration of your app to professionals will give you the results you need in a pre-agreed time frame.

3.7. Start your marketing strategy now, before you build your 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.

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.

4.1. Define your Minimum Viable Product

Now you have everything clearly documented or at least outlined when it comes to the ideal state. Depending on the complexity of your business model, you may have close to or more than 100 features and functionalities identified. The next step is to take each and every one of these features and rank them based on a very simple algorithm: 'must', 'should' and 'nice' to have features. In other words, out of the 100 features identified you can certainly launch the app with a subset of features and 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.

4.2. 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.

Page Speed Insights

What this tool will give you is a score for each page as well as optimization strategies that many developers disregard and in doing so cause additive problems 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.

4.3. 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 acceptance criteria for what constitutes a 'pass' versus a 'fail' for a scenario. Typically, your test plan should include:

  • Feature to be tested
  • 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.

4.4. 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.

Another area you may consider investing in is the testing automation tools. At the beginning, as you’re launching your app you may rely exclusively on actual QA Analysts/testers and stakeholders to do all the testing. However, as your app’s usage grows, so will your roadmap. As your roadmap becomes more complex and your release cycle more frequent you need to ensure that your app is 99.99% bug-free 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.

4.5. 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:

  1. How will the app be tested once in production (sanity check)?
  2. How will any issues/defects be logged, tracked, and fixed?
  3. Do you have a roll-back plan in case all hell breaks loose and the app needs to 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.


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.


  • 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
    • Mobile strategy is not an extension of the online strategy – focus on your customer’s journey
    • Mobile is not a channel. It is a touchpoint through which customers can quickly interact with your company in a convenient and seamless way
    • 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

February 16, 2016

9 Reasons you should make mobile app development your #1 strategy in 2017

In a rather surprising move, during the 2015 Thanksgiving shopping week retail giant offered mobile app only deals. If you wanted a 50" HDTV for only $150 (wow!), you simply had to download the app on your smart device - accessing the web from your mobile device didn’t count, you had to have the app downloaded. Amazon was not alone in this move. Target offered 10% off simply by creating a wish list on the Target Kids App. Other retail giants offered deals first on their app and then online. Shifting the focus entirely from desktop to mobile app engagement is certainly a bold move. At the same time, with 1.2 billion smart phones in the world, and 25% of the US population accessing the internet primarily through their phones, with 10% exclusively through their phones, maybe this mobile app development strategy is not without merit.

Eight years after the launch of the first generation iPhone, arguably the biggest game changer in customers’ behavior towards their phones, there are still many companies across the US who have not fully embraced the world of mobile consumers. In 2014, 45% of all US businesses didn’t have a mobile app or responsive website. Things have certainly improved since 2014 when 28% of US companies admitted to not having a mobile app development strategy. By 2015, only ~11% of US companies did not invest in mobile app development.  Despite all this progress, when Google changed their algorithm for search in April of 2015 basically de-prioritizing search results from companies that were not “mobile-friendly”, a staggering 40% of the Fortune 500 companies were negatively impacted by the change since their websites were not mobile friendly.

What all this data shows is that many companies continue to operate in the mindset where the desktop/laptop experience takes priority over mobile. For those businesses that have a mobile app development strategy, new features and functionalities are still internally conceived with the web being the priority and mobile being an extension of the web.

Companies across the board continue to struggle to define the optimal mobile strategy for their business. In this article we explore the top ten reasons why you should make mobile strategy  a priority in 2016. The benefits of a “mobile first” strategy speak for themselves from both a customer and a business perspective.

  1. With 51% of total web viewing occuring on mobile, you need a mobile app development strategy.

Customers literally carry their phones with them everywhere. They wake up in the morning shutting down the alarm and checking the weather on their smartphone. They spend their time in transit to work looking the entire time at their 4-6” screens. They take breaks during the day and they carry their phones with them. They leave work and still their eyes are on their phones. They go out to dinner or to meet with a friend and even then they sporadically glance at their phones. I have even heard of people checking their phone during face-to-face job interview. The point is, the smartphone is with us all the time. I have forgotten my keys at home, my lunch, even my work laptop, but never, ever have I forgotten my smartphone when walking out the door.  The smartphone is the technology I spend most of my time on each day, every day. And I’m not alone. According to Internet Trends 2015 Annual report, people spend more time on their phones than on any other device.

2015 Internet usage by channel (mobile/web/tablet)

Of the approximate 6 hours spent by customers each day on various digital channels, 51% of the time is spent on mobile, 42% on desktop/laptops and 7% on tablets.


If people spend so much time on their smartphones these days, your business strategy must account for that.

2. Customers want to find what they need, fast, and based on their location.

The Uber app is a prime example of a company offering customers a service based on location and need

The Uber app is a prime example of a company offering customers a service, based on location and need.

Turning on your location on your phone, you can catch an Uber or a Lyft. Or, on a road trip, you pull up your Orbitz app to find available hotels nearby. Perhaps you go to your Yelp app to search for nearby restaurants. Sure, many websites offer location-based services that let you enter your zip code to find results but smartphones eliminate the need for customers to manually enter any information and instead provide the instant gratification of finding what they're looking for based on their location. Location based services have become so second-nature to most customers that in 2015, a staggering 75% of all US customers looked for offline, location-based services on their smart phones.

3. Notifications allow you to get to your customers in real time.

The old algorithm of engaging with customers only when they reach your website is gone. Push notifications have made it easier for any business to get in touch with their customers by sending critical information (your order has shipped) or marketing offers (check our sales on the app) directly to the user.  In the past, the most effective method of pushing content, products, and offers to a user was via email. Even in today’s world, emails remain a very effective method of engaging with customers with the average click-through rate hovering around 3%. However, in a surprising turn of events, push notifications are far more powerful mediums of communicating and engaging with your customers than emails ever were. Accengage, a company that specializes in push notification technology for mobile apps, analyzed five billion push notifications sent to 150 million app users. The findings? A phenomenal 6% of all customers clicked on a notification across all industries and OS types. That makes in-app push notifications 100% more effective than your email marketing campaigns. What this means for a company is that they are 100% more likely to convey a message to a user through push notification than through email. This is what makes push notifications so powerful.


Push Notification open rate


39% of Americans check their email 1-3 times a day with only 34% of them regularly checking their email throughout the day. In contrast, customers check their phones 46 times a day. This has redefined not only how people interact with the digital space but also how companies relate to their customers.

We check our phones so many times a day that companies can get to us “in the moment”. For a short 2-3 seconds you get my attention and if you know what you're doing you can convince me to act based on the information you provide me with. And that’s what a micro-moment is: in a few seconds, companies with mobile apps can deliver quick information, based on which I can either act (buy this!) or consume (your pizza is on the way).

Google time/ location notification
Google Calendar time/location notification makes customer's lives easier by reminding them of upcoming appointments.

And your opportunity is huge: not only do you reach me through a push notification but you also provide me with the relevant information and options inside the app enabling me to act in the spur of the moment or return at a later stage. With so many opportunities to engage with me during the day, your likelihood of being effective is much higher when you have a mobile app then through any other means.

  1. Personalization is King on mobile.

Groupon's personalization in-app strategy
Groupon's app excels at personalizing the experience by providing contextually relevant information based on the user's in-app experience.

Here’s the greatest thing about a mobile app: once authenticated, a user need never log in again. In contrast, on a website you can only keep the user online for a limited amount of time either because of online legal regulations or because a user will clear their cache, making you lose the connection with that customer. On mobile this is not an issue. When a customer taps on an app the opportunities are endless. You can show him personalized deals and recommendations. You can take him straight to your homepage or to any other page that you think will convert him. You can show him his previous activity on the app or suggest something new. There are no limits to how well you can personalize a user’s in-app experience.

Consider the page I see when tapping on the Groupon app. This app has completely personalized user experience based on what they thought was relevant for me: informing me of an existing deal, reminding me of deals I previously looked at, and trying to sell me on a new type of service they’re offering which I've never tried before. That shows just how powerful a mobile app can be based on the data points they've collected about me in the past. Don’t miss out – personalization is key on mobile!

  1. Get honest unbiased feedback through the app store ratings and reviews.

As many companies have realized over time, true unbiased feedback is hard to get. Any business that tries to be customer focused will have strategies for engaging users and getting their honest opinion. In a website setting, that is more difficult to achieve. Typically, it’s done through a pop-up which most users will almost automatically, without reading, dismiss. In the app world the conversation is different because the user has a clear way of communicating their point of view. In a website setting if a user doesn’t like what they see they simply abandon it. On an app, especially if they don’t like it, they will leave comments. And though a company might take a hit in download rate if their feedback is too negative, they can easily gauge customer interest, likes, and dislikes, and that way they can easily adapt their mobile strategy. More importantly, when pushing down an update, the company can clearly and concisely call out what's been fixed based on user feedback, as in the examples below:


[su_row][su_column size="1/2"]app updates based on users' feedback[/su_column] [su_column size="1/2"]companies acting on users' feedback for app changes[/su_column][/su_row]
Companies who act on users' feedback get more engagement and loyalty over time.

As we can see from the weather app, the developer is very quick to thank users for their feedback and call out what changes they've made based on user input. The Google app also calls out what is clearly a set of optimizations made based on customer input (improved navigation and load time improvements). Not only is this feedback mechanism good for the business, it’s also good for the customers; it shows that companies listened to them, and that as a user they have a voice in this interaction.

  1. Collect critical information from your customers in a convenient way or allow for easy alternatives on a smartphone.

in app credit card scanner

Companies offering a credit card scanner make it easier for users to enter their billing information

We’ve all been there. You get to the point where you want to make a purchase and now you need to pull the credit card out of your wallet, enter the 16 digit number, the expiration date, the first and last name and the CVC code. When we're really determined to buy a product we begrudgingly do all that. But with a smartphone the process is much easier. With software like any app can simply use the option to allow the customer to simply position their credit card in front of the phone’s camera where all but the CVC code is “read” by the app on your behalf. This advancement not only makes the collection of billing information easier and more convenient to the user but it also eliminates the potential for failure (not entering informational correctly) for the user, something your traditional desktop cannot do.

  1. With an app, you have the customer’s full attention.

Firstly, if you think smartphone users spend their time on their phones surfing the web, you are mistaken. 80% of the time spent by a user on their smart phone is inside an app with only 20% of the time being spent on websites.  Secondly, by the very definition of an app, once you've captured the customer’s attention they will spend more time on your app than engaged in other activities or using other apps/websites. In the traditional desktop world, the user can simply open new tabs and move away from your website. On a smart device, from a user’s point of view, it is very inconvenient to abandon the app, go to another app or website for comparison shopping, and then return. What that means in the mobile world is that if you can attract the customer to your app then your chances of providing relevant content that will result in a conversion are much higher.

  1. Improve overall engagementwith your customers.

If you played all your cards right and ended up with a user downloading your app then you’re in a good position to engage with that customer. Firstly, the user took the trouble of downloading the app instead of cruising in and out of your website. Secondly, your app is now taking up top real estate on a user’s screen. That puts you in a great position to engage with that person. For example, users are more likely to tap on an app if they see a notification count next to it because they see it almost as an unopened email that they need to look at.

  1. Offline mode allows for uninterrupted engagement.

Shazam's offline mode

Shazam's offline mode makes users' experience enjoyable even when mobile data is off.

People find themselves in offline mode all the time. Your office might have poor reception. Perhaps you're on a plane. Or at a cinema, waiting for a movie to start. The point is this happens to all smartphone users. All the time! And when that happens, companies with native applications that support an offline mode are in a great position to delight and engage their users. When your app is loaded on the customer’s phone you’re not so reliant on network or Wi-Fi connectivity which allows you to continue engaging with your users. Some companies that are dependent on the cloud to function properly will even go the extra mile and save the user’s input for later when the user’s phone regains network access.

Frankly, I’m surprised mobile app developers have not yet found a way to trigger notifications to smartphone users with spotty internet connectivity in an attempt to differentiate themselves as an app a customer can use during the internet down times. Give it time!

As we can see, in the world of mobile app development there are 9 strategies not present in the desktop/laptop space which allow for meaningful conversations and relevant product/service targeting campaigns. Most importantly, these 9 strategies are effective and useful for a business because they focus on making the experience convenient to the user. From Shazam’s ability to save a song tag for when I regain phone reception, to Uber’s capacity to match me with a driver based on my location, to Google’s tools that remind me when to head out the door based on an upcoming appointment, to the companies that allow me to scan my credit card and save me the hassle of manually enter the information, these mobile app enabled abilities focus on the customer.

As we all know, the most successful companies are those who make customers’ lives just a little bit easier and help customers fulfill tasks in a faster and more efficient manner. Is your company positioned tactically through a mobile strategy to help your customers get what they need?


Join Our Newsletter