A Simple Guide to Assessing Mobile Maturity

“Jim, how do our company’s mobile capabilities rank against our competitors?  What do we need to do be the Uber of our industry?”  

If you’re Jim, you have your work cut out.  Often you’ll want to start with an effort to gauge your current “mobile maturity”—where you are now—and then map out steps to grow and compete at a target level.

Assessing your organization’s level of mobile maturity is a daunting task—the mobile ecosystem is a large, fluid and complex web of people, processes and technologies.  And shooting for “Uber-fication” is a tall order only a few companies—all startup/disruptors—have mastered.  What’s more, by the time you complete a typical full organizational evaluation and plot a path forward the landscape will have shifted, sometimes significantly. 

Industry Guide Posts

Looking to leading industry analysts, Forrester and Gartner each provide approaches to evaluating mobile maturity based on progressive frameworks.

Based on the seminal book The Mobile Mind Shift, Forrester has developed the Mobile Mind Shift Maturity Framework (subscription required).  In short, Forrester sees mobile maturity as a progression through four key stages:

Gartner takes a five-stage approach to their Mobile Maturity Model (subscription required) which is more process improvement oriented:

Both models are very useful maps for pinpointing your current position, identifying steps to improve outcomes and finally transforming your business.  However, as Gartner pointed out in a recent webinar, “evaluating all the elements [of mobile maturity] takes too much time” and that “a complete evaluation may not tell more than a limited one.”

Getting a Mobile Maturity Snapshot

So, what’s an efficient and effective approach if you want to get a quick snapshot of your current position?  Based on working with a variety of clients’ (of widely varying levels of maturity) mobile initiatives over the years, we believe that there are seven key areas that go a long way toward quickly determining current mobile maturity level:

1. Prioritization
2. Measurement
3. Ownership
4. Governance
5. Talent
6. Technology
7. Customer Experience

For each area (and in no particular order) we’ll briefly describe three levels of maturity on the scale and also reference related posts should you wish to dig in further.

How does your organization identify and then determine which mobile initiatives will be worked on?  (See also Why Your Mobile Initiative Isn’t Getting Funded)

How does your organization measure mobile initiative success?  (See also Developing a Mobile Analytics Strategy)

 

How does your organization approach management of mobile products?  (See also Mobile Project Vs. Mobile Product)

How does your organization manage mobile initiatives and products over time?  (See also Eight Reasons Why You Need Mobile Governance)

 

How does your organization ensure that top minds are designing, delivering and evolving product?  (See also Magenic Technologies' Best in Class Consultants or Learning on Your Dime)

 

How does your organization ensure the technology foundation for mobile initiative investment will be effective and durable?  (See also Magenic Technologies’ Choosing a Mobile Development Platform)

How does your organization ensure that customers’ (internal, partners, external) mobile experiences are high quality and exceed expectations?  (See also Frictionless Mobile Experiences and Why They Matter)

Closing Thoughts

While the journey toward mobile maturity for each client is unique, we've learned a great deal from our own and clients’ mobile successes (and failures) over the years.

Maybe you’ve been scoring your organization as you’ve been reading.  How did you do?  Of course, the biggest room in the house is always the room for improvement!

Does an MVP Release Make Sense for Your Mobile Initiative?

Over the last several years we talk less and less about building mobile proofs of concept (POCs) and more about producing “minimum viable product” (MVP).  

The two terms are not the same in that a POC is generally intended to address key risks—often technical—or to socialize a product concept internally.  While MVPs can do these things too, the big difference is that an MVP version is released to the market as working software.

However, some product owners have heartburn about the MVP concept.  The idea of releasing what they see as a half-baked effort is believed to be a significant market and brand perception risk.

In addition to assuaging risk-related concerns, defining MVP can be like the proverbial twelve blind men and the elephant—each stakeholder sees the product and its success from their own perspective.  Is it minimum testable, minimum usable, or even minimum “lovable” product?  Or should you wait to release an “exceptional viable product” that is impressive but doesn’t have everything included?  Isn’t MVP just for start-ups?

What is MVP?
What is an MVP-caliber product release?  To give context to the answer, consider the standard MVP definition for all products (software or not):

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Generally, an MVP release has the four key characteristics:

1. Sharply pruned, minimum feature set for a new product that is required to test foundational product hypotheses—what we believe to be true about “early adopter” or target users’ needs and desires, likely behavior, and what is valuable.  What’s “minimally viable” is a subjective call and can be quite difficult to agree upon (see also my post on Capturing the Mobile Moment, a quick guide to targeting the right mobile features).
2. Intended and designed to test, measure and learn how to shape the next product release
3. Minimizes risk by conserving effort, time and financial investments
4. Released to the market and/or end users

For mobile applications there are a several additional considerations that will impact your definition of MVP:

• Target Device and OS.  Much effort, time and money can be saved by targeting a narrow range of devices and operating system versions.
• Connectivity.  Will your application work only when connected or must it also work offline?  Adding offline capabilities will probably add complexity, especially if there is any data synchronization required.
• Integration.  Getting to mobile readiness of corporate data is often the longest duration task for mobile products.  Data that’s readily available will probably influence the MVP feature set.
• Deployment.  It’s no secret that getting your application through app store approval is easier for Android apps—typically a couple days—than for iOS apps (maybe two weeks), which are also subject to a much higher level of design review.
• Management.  If you’re deploying an enterprise or B2B mobile app you may be required to secure, deploy and manage the app through an MDM product.
• Analytics.  Capturing basic user event data and app performance data is a must-have to support the test/measure/learn approach that makes an MVP effective (see also my post on Developing a Mobile Analytics Strategy)
• Privacy, Security, Compliance.  Inadvertently exposing customer or company data can be a disaster—don’t skip this vital step!  If you are collecting regulated customer data, make sure it is properly safeguarded.

Where MVP Fits in the Product Lifecycle

As we decide if MVP is right for your mobile initiative it’s important to briefly establish an MVP release’s place in the product development cycle.

Think of MVP as your product’s introduction to the market or end users.  It’s the first of many releases, each of which builds value based on lessons from prior releases.  Mobile apps in particular require many releases due to not only user feedback but technology changes, market changes, competitors, privacy or security concerns, and much more.

Have you ever looked at leading mobile apps’ release histories in the app stores?  They typically update several times a month for years.  MVP was a one-time event that introduced the product—and only the tip of the iceberg for the product roadmap.

Is MVP Right for Your Mobile Initiative?

Now that we have established what MVP is, identified special considerations for mobile apps, and properly placed it in the product lifecycle, is it right for your mobile initiative?  There are several factors that will indicate if an MVP-based approach to your mobile initiative will be effective and appropriate:

• Is this a new product?  If the answer is yes, then an MVP is absolutely on target.  In short, it is the best way to minimize risk, conserve budget and then apply time/money saved to lessons learned.  If your mobile initiative is not a new product but only an incremental release or minor update of an existing mobile product then an MVP may be unnecessary.

• Is mobile a new platform for an existing product?  If you are migrating an existing product from, say, the web to mobile you need to take an MVP approach.  While you may believe you understand what features and capabilities from the existing web product translate to mobile—and which uniquely mobile capabilities to add to the product—it’s well advised that you will still need an MVP to vet key assumptions.

• Do you have a product roadmap?  Product roadmaps are based on a collection of hypotheses about users’ needs and desires, likely behavior, what will be valuable, and so on.  For mobile apps—maybe more so than other channels because the technology and market landscape is incredibly fluid—the MVP approach is the best way to efficiently validate your hypotheses based on users’ real feedback.  However, if your mobile initiative is not tied to roadmap for delivering progressive value (are you missing an opportunity?) and the initiative is to achieve a highly tactical objective that won’t be measured or improved you may not need an MVP release.

• Are you targeting consumers or internal/B2B users?  If you’re targeting consumers MVP is a must.  Consumers—especially the mobile crowd—are simply too fickle and unpredictable to responsibly do otherwise.  If you’re targeting internal or B2B users with a new product or a product that will evolve over time starting with an MVP release is the best approach.  However, there may be specific circumstances, such as an upgrade of existing product or an extremely well-understood operational capability, where an MVP is unnecessary.  If your initiative seems to fit in the “specific circumstances” bucket, proceed with caution—mobile is full of surprises.

• Is user feedback a priority?  Ok—this is a little tongue-in-cheek.   Every product owner values user feedback.  And this is precisely why learning from an MVP release is the quickest and most time/financially efficient way to test product hypotheses—and then make quickly make changes that reflect what your users’ feedback and behavior (because you’re collecting analytics) are telling you about what they value.

Planning For and Learning from an MVP Release

Most mobile initiatives fit profiles that benefit from an MVP/Product Lifecycle approach (see also my post on Mobile Project vs. Mobile Product).  If your mobile initiative is in this group, here are a few planning activities (among many others) to cover before launch:

• Align with Business Objectives.  Which business objectives will the mobile app support?  (See also my post on Why Your Mobile Initiative Isn’t Getting Funded to ensure you’re on target in this critical area.)
• Identify Success Criteria and How to Measure.  How will you know that the app has achieved MVP success?  How will you objectively measure that?  Conversely, what results will indicate that the product concept either requires a significant pivot—or even a swift death?
• Identify User Stories and Perform Backlog Grooming.  Again, the wisdom and art is in what you exclude rather than what you include.  Prune to the minimum set of user stories that will enable you to effectively evaluate product hypotheses for target user personas.
• Plan to Collect and Analyze Data.  Be sure that the data to support your success criteria is collected and available for analysis to prove product hypotheses.
• Establish a Timeline.  How long will the MVP release be in production before you prioritize your lessons learned and focus on the next release?  Hint:  You will need a high-level of velocity here in order to not lose mobile users—patience is not their strong suit.

Now that your MVP release has launched, you will want to have a laser-focus on quickly learning what to change for your next release.  Several key sources of information include:

• User Analytics Data.  Did users do what you expected or planned for them?  Is their behavior aligned with business objectives or do you need to rethink?
• Application Performance Data.  Did application performance impact user tasks or retention?
• App store reviews (if public) or user interviews (private).  What do users love (or hate)?
• Target KPIs.  Impacted as planned?

Finally, know that mobile has a unique set of concerns; some level of mobile governance will help your new product meet objectives over time.

Closing Thought

Defining MVP release scope and functionality—as well as clearly identifying what hypotheses will be tested—is an important part of a winning product introduction.

Mobile Project vs. Mobile Product

Are you thinking about starting a “mobile project” to build an app?  Think again—your plan may have a high probability of failure.

Why?  Depending on the characteristics of your initiative, planning to build a “mobile product” will be a much more effective long-term approach to meeting business objectives than a project.

What’s the Difference?

First of all, what’s the difference between a project and a product approach?  Isn’t it just semantics?  Actually, they are quite different.

While there is some overlap between project- and product-based approaches, the key difference is that a project is typically focused on delivery of a single mobile app release while a product is focused on achieving business outcomes throughout a product lifecycle spanning multiple mobile app releases.

But that’s not all.  Here’s a summary of a number of significant differences between project and product mindsets (credits to Marty Cagan and Moonshot Horizon):

Why a Product Approach Matters for Mobile

Wouldn’t the comparisons above apply to any application development initiative?  Unquestionably, yes. So, why the big deal about taking a product approach to mobile?

Mobile initiatives are subject to a unique set of vectors that impact success, including:

• Users’ Experience Expectations.  You’re not just competing with competitors’ latest features; you’re competing with well-designed games, social media, music, video and other apps for your users’ eyeballs—and brand estimation.  Frequent updates required!

• Stakeholder/Sponsor Expectations.  They want their app to do that new thing that Instagram does.  How hard would that be?  Popular apps are often updated with the latest capabilities inside of monthly—nobody wants a stale app.

• Fluid Technology Landscape.  New devices, new OS versions with new capabilities, security or privacy issues, integration changes, new tools, regulations, etc.   The ground is constantly shifting.  Keep up or risk quick irrelevance.  Or worse, a security/privacy event.

• Data.  User ratings/reviews, user event data, application crash data, customer service information, etc.—not to mention business KPIs—all must be constantly be monitored and analyzed to ensure key objectives are being met.  Data must also be analyzed to surface insights that will drive and prioritize changes to the product.

So, what are some of the risks in treating your mobile initiative as a project rather than product?  

• Missed Opportunities/Lack of Innovation.  Some of the best-loved mobile apps today started as apps of a different color; that is, they made major pivots or innovated based on user feedback.  Here are two classic examples:

• The founders of SnapChat struggled to attract users, but it started going viral in high schools.  This discovery led to the shift in focus in customer segment.  Today SnapChat is ranked as the #7 free app in the Apple App Store.
• Burbn started as a mashup of Foursquare and Mafia Wars that let you check in to locations, earn points for hanging out with friends, post pictures, and so on. User data indicated that photos was the real opportunity so the team cut everything except for its photo, comment and like capabilities.  What remained was Instagram, the #11 free app in the Apple App Store.

By the way, did you know that Android was originally conceived as an operating system for cameras?

• Wasted Investment.  Analysts believe that mobile apps typically require four major version releases—and typically a pivot—before they begin to deliver on business objectives.  Have you looked at a successful app’s App Store or Google Play release log?  It’s unlikely you will achieve lasting success on the first try.  Alas, your project budget was all spent on the first release.

• Brand Injury.  Whether a mobile app is customer-facing or internal, users will judge your brand based on a wide range of factors such as effectively addressing their mobile needs (or needs not addressed), quality of user experience, device and OS support—and much more.  It’s highly unlikely you will achieve the right balance of these factors the first time around.  Don’t worry; app store ratings and reviews, social media, and blogs will all happily share the story.

• Customer Satisfaction.  Mobile app users are often much more annoyed by a failure to improve (by releasing an updated app) than they are by an initial effort that falls short and is then improved based on feedback.  When you approach mobile as a project, you’re telling your users that their feedback is not important.

If a typical project is delivered on time, within budget and meets key requirements, we happily declare victory—no matter what may happen next.  However, achieving ongoing success with a mobile app clearly requires a much more complex, iterative and nimble journey.

How to Evaluate Your Mobile Initiative

Do all mobile initiatives need to take a product approach in order to be successful?  For the vast majority of mobile apps the answer is unequivocally Yes!  But there can be certain sets of circumstances where a project approach may suffice.

Here’s a few simple criteria for evaluating your mobile initiative:

Might be a Project if…	Might be a Product if…
Corporate-supplied and managed device or only a single device is targeted No vision for future functionality Private distribution (MAM) Not customer-facing (B2C or B2B) Not strategic for the business Success will not be measured Will be owned and managed by IT Static, well understood environment Very small user group	Customer- or partner-facing BYOD/CYOD, public device support Public app store distribution Strategic (e.g., competitive differentiator) or new capability Supports or enables key business objectives Product owner and roadmap focused on customers’ needs Data will be collected, analyzed Investment will be measured; KPIs Dynamic environment Back office/third party integration

Each of the product characteristics indicate that change is highly likely.  Consequently, if you find that your mobile initiative has any of the characteristics of a product, a product-oriented approach is going to be the best long-term approach.

However, even if your initiative has several of the more static characteristics of a project, it would still be advisable to think through the anticipated mobile capability lifecycle.  What might be necessary in six months or a year from now?  The mobile app’s overall context may prove to be more dynamic over time than you think.

Closing Thoughts

Clearly there are many persuasive reasons for organizations to take a product-oriented approach to developing and managing their mobile investments.  And consequential pitfalls for those who don’t!

Capturing the Mobile Moment

If your company’s enterprise mobile efforts are primarily focused on deploying devices and writing policies, you may be losing a definitive battle in the war to win, serve and retain customers, employees and partners.

To wit, we see competitive advantage being successfully realized by business leaders that focus on identifying and leveraging what Forrester Research calls “mobile moments”.  

Prominent success stories like Uber, founded in 2009 and now estimated at worth more than $50B USD, illustrate how responding to a customer’s moment of need with a tailored mobile experience creates significant value.

Mobile Moments

Most of us are familiar with the term “customer journey”—a series of increasingly complex touch points and interactions between a business and its customers, partners and employees.  

Mobile moments are points in time and space along the customer journey when someone pulls out a mobile device to get what he or she wants in the context of that immediate want.

Here’s a simple example in a familiar consumer retail context (more examples):

Mobile Moment	Context	Action in App
Where’s the nearest location?	Nearby, in a car, walking	Locate nearby locations
Can I get a free drink?	Waiting in line	Check rewards balance
Can I pay using my app?	Waiting in line	Check available balance
Pay for my drink/food	At checkout	Use rewards or scan to pay

From an enterprise perspective, it’s important to realize that mobile moments aren’t limited to customer-facing interactions—employees and partners experience many mobile moments, too.  Typically, these mobile moments surface when employees need to consume information, communicate or share information, perform a transaction, or create something.  

In short, companies need to enable employees and partners to make the most of their interactions with customers and colleagues, and take direct action to get things done regardless of location.

Micro Moments

Because opportunities to take advantage of mobile moments have been available for several years now, consumers’ expectations for immediacy, simplicity and context-based relevancy have increased.  Alongside rising expectations, advances in technology such as wearables, iBeacons, analytics, connected products, sensors, interactive icons and notifications have given rise to the “micro moment”.

What is a micro moment?  A micro moment is a mobile moment that requires only a glance to identify and delivers quick information that it can either be consumed or acted on immediately.  Information may be a text, sound, notification, vibration, or icon change that proactively anticipates a need based on user’s context or preferences.

Examples of micro moments include being alerted to a stolen credit card, delayed flight, price change, sports score or bill due.  More complex examples intelligently examine several services to create new information.  For example, a business contact with whom you’ve been exchanging email regarding a meeting is determined to be nearby and your calendar has an open slot—a notification is triggered for you to take action and send an invitation.  (Additional examples of micro moments from marketing and enterprise productivity perspectives.)

Leveraging Mobile Moments is a Challenge

For established businesses identifying mobile moments and strategically leveraging them to create or enhance value can be a real challenge.  Forrester Research reports that:

• Less than half of digital business professionals surveyed have even identified the unique needs of customers on the go
• Only 28% use context to deliver relevant services or to streamline and personalize the delivery of their mobile content and services
• More than a third used mobile apps and websites as scaled-down versions of the corporate website

Clearly, many companies are grappling with engaging mobile customers effectively in their mobile moments, whether they be consumers, partners or employees.  Why?  There are a wide range of inertial factors from significant business process change requiring a mobile mind shift to technical architecture limitations.  

In short, a successful effort to engage mobile users in their mobile moments will require new, innovative approaches to all aspects of your business.

Where to Start?

Begin with creating a strategic plan to assess business opportunities to leverage mobile moments:

• Identify, organize and prioritize business mobile moment opportunities based on user needs, value, complexity and ability to execute
• Build an integrated roadmap with client product owners and stakeholders, including features, supporting/shared technologies, and dependencies for prioritized initiatives that lays out a plan for product development for near (~1 year) and long-term (~2+ years)
• Assist clients in identifying KPIs and success scenarios to ensure that the right approach is taken to realize objectives
• Envision and develop proof of concept for target near-term initiatives that richly illustrate key interactions and may be used to socialize a very tangible representation of product value

The Right Moment for Enterprise Mobility is Now

One of the toughest elements in mobility for many enterprises to understand and internalize is that mobility is not a destination…it is a journey.

The mobile ecosystem (devices, OS's, development frameworks, etc.) is changing so rapidly that enterprises waiting for the “right time” to jump into mobility will be at a competitive disadvantage.

Get a good partner to help you, get a strategic plan based upon your business’s mobile moments and get going on your own mobile journey.

Developing a Mobile Analytics Strategy

Would you invest in a stock if there were no way to track its valuation?  Owning the stock would be a blind venture:  no way to know if you should buy, sell—or if you’ve already lost your shirt.

Similarly, to make confident investments in a mobile products portfolio you need to establish clear measurement of progress against business objectives, proactively track performance, and create actionable insights to guide future product development.  

Mobile analytics enable you to execute on all these critical tasks.  And, according to MIT research, top performing companies tend to leverage analytics 5 times more than competitors.

Here are a few examples of how mobile analytics data enabled companies to directly improve business results:

• Comcast used analytics to improve its recruiting mobile app’s user experience and saw a dramatic impact on its overall recruiting results, with mobile applicants increasing by over 20% overall and mobile candidates completing their applications at a rate of over 50%
• Overstock.com used insights gained from Flurry’s mobile analytics to increase in-app purchases per user by 25%
• Airbnb improved conversion rates 5x using Mixpanel’s mobile analytics

Creating a mobile analytics strategy would seem to be a obvious part of every mobile product development effort.  However, it is often an after-thought at best.  Why?  

The simplest answer is that delivery teams focus on what’s needed to get an app to market, not how to manage business results.  But—much like managing a stock portfolio—it’s imperative to plan from the start how to measure, track and improve a mobile product over time.

Now, mobile analytics can be a complex topic.  There are a variety of vendor solutions, many of which are web-oriented solutions that have recently bolted on mobile capabilities rather than being truly fine-tuned for mobile.  (On the other hand, the traditional web analytics solutions more readily offer cross-channel insights, especially if your choice of mobile analytics tool is not integrated.)  In any case, among the mobile-focused vendors, while there is a lot of functional overlap, products are often targeted for specific business models or types of analysis.  

So, how to start?  Here we’ll explore three steps to creating and implementing a mobile analytics strategy.

Plan

Initially, there are three main categories of information you should focus on supporting:

• Business Measures of Success/KPIs.  Each product has a unique set of business outcome or success measures—these KPIs can include business results, technology performance, user behavior, and so on.  Whatever the business objective, make sure that the data required to calculate each KPI is accurately captured.  Also, know that KPIs may change over time as you gain insight and product matures.  Your objective is to ensure that all stakeholders can track the KPIs by which products’ contribution to the business is measured.
• Technology and Operational Monitoring.  Track technical aspects of product performance; for example, response time for a key operation, which devices are being used, app crash details, network connectivity, etc.  Your objective is to proactively surface defects and performance issues—before they are posted in a negative review or result in app deletion—that prevent users from enjoying an optimal experience.
• Engagement, Tracking User Behavior.  Prepare to listen for users’ signals about how and when they use the app, favored features, interactions and paths through the app.  Your objective is to connect the data points to surface insights on how to improve the aspects of user experience that are important to overall success.

In short, the data you track should support creation of information that either alerts you to issues to address or opportunities to explore.  This information will be historical (older than 24 hours), operational (today) or real-time.  

Plan to start simply:  Start small, test data accuracy and relevance, and iterate often—just like you’re doing with your mobile product as a whole.  Then assess the data and information you’re getting (or not getting) and optimize data being tracked—or even which tools are being used—to ensure you’re  generating actionable information.

Next, over time and as your analytics capabilities become more relevant and accurate, plan to generate insights from users’ cross-channel experiences, not just mobile.

Finally, ensure that everyone—including the development team—has access to the data so that they can suggest ways contribute to product improvement.

Select Tools

When should you select mobile analytics tools?  The answer is as soon as your product feature roadmap and supporting technology stack is established.  

As noted above, there are many mobile analytics tools available.  What’s more, mobile analytics tools are relatively new and immature.  So, what approach and which tool(s) to choose? 

Selection of the right analytics tools for your specific application can be a complicated task as vendors tend to be focused on various aspects of analytics; for example, app store analytics vs. crash data vs. defined user event analytics.

Here are some general principles to guide you:

• Start with what’s free and basic—a combination of Google Analytics and Flurry.  These two popular tools, along with the app store tools (if your app is in the public app stores), will provide a strong foundation.  Also, there are open source options, such as Countly, available.
• Understand your product’s category.  Don’t pick an analytics tool geared for mCommerce if your app is more focused on content delivery.  Also, assume that over time a blend of tools will be necessary to meet your specific needs.
• Understand your product roadmap.  Pick analytics tools that will grow with you—and that you can still afford—as you add features, users, platforms and/or countries.
• Look for features that enable you to clearly comprehend and quantify user behavior.  Two such features are   session playback, which lets you watch a simulation of actual users actions in your app, and heatmaps, which help you visualize which parts of your applications are highly utilized.
• Ensure that app architecture is designed to enable you to easily use multiple and/or switch mobile analytics tools as needed.
• Consider how you will track user activity across devices.  Tools like Google’s Universal Analytics track user paths across devices.

As you refine your selection of tools and approach, don’t forget to leverage enterprise data from operations, customer support, marketing or other relevant sources to build unique insights into your business and its customers.

Act

Beginning to collect product analytics data when your app goes live is missing a very valuable opportunity:  beta and/or pilot data.  A pre-release period using an early adopter group or a savvy user set (for example, through PreApps) can yield a significant amount of actionable analytic data.  

You may discover, for example, that real-world users don’t use your app the way you envisioned and you need to make navigational or usability changes, drop or add features, optimize technology performance or re-prioritize your roadmap—valuable insights that will make your general availability release more successful.

Analytics data is often your first alert—before user reviews or even a phone call from customer support—that something is amiss.  Consequently, when your app goes live establish a regular schedule to review analytics data.  If your app is customer/consumer facing you may choose to review salient data daily with a full weekly review, including carefully sifting through data to discern trends and user signals.  Make sure to provide all stakeholders with regular KPI reporting, as well as actionable insights you’ve developed.

Finally, make sure that the information generated from your mobile analytics is appropriately factored into continued product roadmap planning.  Objective data should play a significant role in feature prioritization (what to keep, improve or drop), evaluation of underlying technology performance, user experience design effectiveness, and quality to name just a few areas of influence.

Closing Thoughts

We believe that all enterprise mobile apps—whether for the employees, partners or customers/consumers—can significantly benefit from the insights enabled by mobile analytics.  We'd recommend that everyone plan to deliver durable value by developing and implementing a clear mobile analytics strategy for each mobile product in their portfolio.