The Ultimate Guide To Creating A Mobile Strategy That Works in 2017

4/9/2019 The Ultimate Guide to Creating a Mobile Strategy that Works in 2017
The Ultimate
Guide to
Creating a
Mobile Strategy
https://ymedialabs.com/ULTIMATE-GUIDE-CREATING-MOBILE-STRATEGY 1/68
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 “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:[/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
the Single Product/App
Strategy[/vc_message][vc_message
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
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:
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
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.
Source
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).
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 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:
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.
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:
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!
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:
Do it well and everyone will thank you for it.
3.4. Determine if you

need a hybrid or a native
application
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).
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.
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_1488383826697{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
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
Hello Make a Lasting Impact.
About All rights reserved.
Y Media Labs
News ©2019
Careers
Contact

The Ultimate Guide To Creating A Mobile Strategy That Works in 2017

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Ultimate Guide To Creating A Mobile Strategy That Works in 2017

Uploaded by

Copyright:

Available Formats

4/9/2019 The Ultimate Guide to Creating a Mobile Strategy that Works in 2017

Coming up with a mobile strategy for any

To expect any strategist to simply outline a

If you want to develop a mobile strategy

The company strategy will drive your overall

At this phase, it is critical that you engage

As you’re looking at your company’s overall

1.1. Always start at the

Document your company’s strategy,

Don’t think mobile or online; think as big as

1. What is the mission of the company?

Your goal is to understand your company’s

overall strategy as a complementary tool. In

1.2. Mobile strategy is not

Focus on your customer’s journey to

Typically, executives hired to drive the

that they can interact with your company,

The best way to be valuable is by

A customer journey exercise is a fantastic

This is great not only because your mobile

When done right (most companies

When engaging in this process you will

customer journey mapping above, as a

1. How would I show order status on the

The app must offer the user everything the

1.3. Mobile is not a

It is a touchpoint through which

If you went through the process of

Perhaps the biggest disconnect in the

wanting to interact with a business wherein

To that end, mobile becomes an enabler for

As such, when you’re drafting your overall

1.4. Understand who

Document and analyze what your

market baseline before your team

Conventional wisdom states that after you

1. Analyzing what the competitors do will

anyway. So why do this work in a

Once this analysis is done, you should have

A different view of your competitors comes

In doing this exercise before outlining your

1. What your competitors are offering

3. What you’re NOT going to offer

1.5. Deﬁne the Strengths

After you've done the competitors analysis

By now you know what your company’s

of your company able to add a mobile

This is an example of a SWOT analysis

What’s great about this exercise is that it

Once you've clarified the overall company

2.1. Deﬁne the elevator

Your entire mobile strategy will hinge on

idea of what the mobile application should

1. What’s the idea?

Your idea must be simple, concise,

Additional critical components of a great

1. Your idea must tie in nicely with your

2.2. Work on building the

A roadmap is basically a visual timeline for

2.3. Document the

Once you've identified the elevator pitch

deliver the first version of the app, and then

2.4. Deﬁne the