How To Create a Mobile Strategy that Works, Step by Step
By YML
Coming up with a mobile strategy can be a daunting task.
There are so many considerations to take into account, so many people that need to be involved, and so much complexity.
If you want to develop a mobile strategy that not only works, but drives impact, this article will show you how to do it, step by step.
Let’s do it!
Step 1: Understand the overall company strategy, dependencies and competitors before creating a mobile strategy
The company strategy will drive your overall mobile strategy.
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 cart by engaging stakeholders from several departments to map out touchpoints, strategies, and mandates.
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, but think as big as you can. What exactly is your company trying to achieve?
If your company is led byexpeie44ed leaders, you should be able to get answers to the key questions that will be driving your mobile strategy:
What is the mission of the company?
What do you believe in?
What is your objective? That is, what is the final outcome your company’s strategy wants to achieve?
What is the scope of your strategy?
What’s your competitive advantage?
Your goal is to understand your company’s overall strategy and its annual key performance indicators.
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.
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 not right because the mobile strategy is not simply an extension of your online channel.
Customers expect a mobile app to be more than a website.
The best way to be valuable is by understanding how the customer actually interacts with your company today. 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 understand the end-to-end flow and how your business operates but also because in doing this exercise you actually put the customer first.
Let’s look at this example:
When done right you get to understand the various gaps between channels, departments, 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 app;
B) how and which of these touchpoints can be better served.
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.
1.3. Mobile is not a channel
It’s a touchpoint through which customers can quickly interact with your company in a convenient and seamless way.
Perhaps the biggest disconnect between customers and businesses is that a company looks at mobile as a channel, but 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.
Why should you look at your competitors strategies before building your own strategy?
It will most likely reveal a common set of best practices that will make it to the list of features and functionalities of your app.
You will inadvertently discover things your competitors do poorly. Jot those down as ways you can surpass the competition.
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.
Once this analysis is done, you should have something like this before you draft your own strategy:
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:
What your competitors are offering through their mobile channel
What you’re going to offer
What you’re NOT going to offer
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.
A SWOT analysis 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.
You need to look at internal factors that will impact your enterprise app development.
This is an example of a SWOT analysis done for Microsoft.
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.
Step 2: Define your Enterprise Mobile App Strategy
Once you’ve clarified the overall company strategy and dependencies, you are 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 needed to ensure the program is a success.
2.1. Define the elevator pitch idea that will drive your mobile strategy
Before you launch your mobile product, you’re already dealing with stark competition, limited resources, 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 the right way.
Your entire mobile strategy will focus on getting this right:
What’s the idea?
How will this idea benefit the mobile user?
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.
Additional critical components of a great mobile strategy:
Your idea must tie in nicely with your company’s overall strategy for the next few years.
It must be delivered within the budget and timeframe you commit to.
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, create a roadmap to break down the idea into all the components that need to be executed to deliver on your mobile strategy.
You can also see this as a project plan where projects are spread out based on the expected velocity of a team over sprints or months.
This is what a typical roadmap looks like:
It’s 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.
2.3. Document the resources and budget needed to execute your mobile strategy
Once you’ve identified the elevator pitch idea, you need to understand what it will take to deliver it.
You typically have two types of expenses: capital expenses (headcount) and operating expenses.
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.
For example, 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
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:
Network readiness;
Data access points;
Overall security solution;
Management of the bandwidth extended to mobile users;
Support and maintenance costs;
Performance monitoring tools;
Network load balancer;
Define clear SLAs for the overall performance of the app;
Content Delivery Network.
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.
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 the app actually performs seamlessly.
2.5. Choose agile development over waterfall development as a core component of your mobile app strategy
With the waterfall software development approach 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 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.
On the other hand, with an agile methodology, the requirements and business needs evolve over time.
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:
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?
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 is define all the pieces that will make the final product. Come up with a complete feature set for your application.
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.
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’.
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.
Use them to understand the various users that could be exposed to your application.
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.
3.3. Define your data points & Key Performance Indicators (KPIs)
If done right, this step 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.
As a general rule you should try to align your metrics along the following lines:
Company metrics:
Revenue
Market share
Increase customer satisfaction
Reduction in cost to serve
App metrics:
New users
Increased usage
App rating
Lifetime value
Retention rate
Session Length
Active users
Tracking data is easy 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
Once you have defined your target audience and your KPIs, you need to decide if you’re going to build a native or a hybrid application.
We wrote a comprehensive article on this topic, but 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
Generally, we think 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.
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.
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.
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, you will need to define 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.
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.
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.
Make sure your developers do a good job building the software. For example, run the HTML pages they build through PageSpeed Insights from Google.
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.
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.
In order to minimize this issue, you need to have a very clear testing plan defined even before your developers write the first line of code.
Typically, your test plan should include:
Feature to be tested
What’s in scope
What’s out of scope
Test case
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.
4.4. Define the tools you will need to manage your application successfully
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, 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. Investing in QA testing tools 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
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…
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:
How will the app be tested once in production?
How will any issues/defects be logged, tracked, and fixed?
Do you have a roll-back plan in case all hell breaks loose and the app needs to be reverted?
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.
In conclusion
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.
If you would like to learn more, please visit us at YML.co