What Will My Mobile App Cost?

** This post inspired a white paper -- download it here. **

There’s one thing about custom mobile development that everyone wants to know: What will my mobile app cost?

Unfortunately, there is no simple formula from which to reliably derive an estimate—mobile application development is a distinctly complex undertaking where myriad decision points impact cost.

However, based on our experiences developing a variety of mobile apps for a wide cross-section of companies and industries, we believe that—while there’s no magic eight-ball for estimation—there are seven starting strategic perspectives that will help you factor in key cost considerations.

#1 – There’s No Free Lunch (Expect to Invest)

Like any other significant upgrade to your business capabilities, building an effective enterprise mobile app will not be cheap.  Yes, you can get an agency to build you a beautiful mobile app—but it will be built for a three-month campaign, not architected for enterprise integration or a product lifecycle.  Yes, you may get some recent college grads in a garage to knock out a functional app, but it’s unlikely these guys will be 22 year-old versions of Steve Jobs or Bill Gates.  Finally, yes, you can get some offshore shop to build an app; however, it’s hit or miss whether these developers will truly understand cultural context (or you), properly implement security or securely integrate your back office—and they might even sell the secret sauce in your code to a competitor.

Takeaway:  Building a mobile asset of true value will require a commensurate investment of time and effort.  There are no shortcuts that can sustain your investment given the chaotic nature of the mobile space.

#2 – It’s a Product, not a Project (Lifecycle Plan)

If you’re looking at developing a mobile app as checking a box—“Hey, look we have an app!”—you might as well burn your money.  

The reality is that successful mobile apps (where success is measured as driving business outcomes) are planned and managed as products, not projects.  Thinking about your mobile initiative as a product with a lifecycle is much different—and critical to your success—than planning for a project!  (See also Mobile Project vs. Mobile Product)

From a cost perspective, the implications of product lifecycle planning include:

• Establishing a product roadmap to create progressive value.  Expect that you will incrementally implement product features over time, most likely starting with a “minimum viable product” (MVP) release (see also Does an MVP Release Make Sense for Your Mobile Initiative?).
• Establishing a product release plan with a cadence to support a “test and learn” approach.  Your ideal release cadence will be dependent on many factors.  A few principles are in play:
• You will make mistakes of all sorts.  No one gets it 100% right the first time or can afford to rest on their laurels.  Users will generally forgive mistakes that are quickly addressed in a new release.
• It’s much more effective to try a few new features that you can discretely evaluate than to roll out a ton of new features at once.  This implies frequent, small releases.
• The device landscape will change rapidly.  New operating systems versions, new devices, security issues, as well as other changes will require you to update your app in order to remain operationally viable.  (Yes, you will be subject to less flux due to these factors in a private enterprise mobile app where you control devices and deployment.)
• The competitive and market landscape will change rapidly.  Mobile is a key point of both competitive differentiation and innovation.  Expect that both competitive pressures and technical innovations will require you to regularly re-prioritize your product roadmap and release plans.
• Identifying and empowering a product owner.  This person must have the business and technical acumen—as well as the authority—to quickly make product decisions to direct the product development team’s work.  Ideally, they have product P&L responsibility and report in to a product management organization or business unit, not IT.
• Building and maintaining a product development team.  Teams that function at the highest levels of velocity and quality tend to be composed of long-term resources, especially in key leadership roles.  Assume that success will require velocity (ability to frequently release product updates) and quality, both in terms of user experience and software quality attributes such as reliability, performance, and scalability.

Takeaway: Plan to invest in building a product development team that will remain significantly intact over the planned product’s lifecycle.

#3 – Good Help is Hard to Find (Expertise: People and Partners)

Now that you’re bringing together a product development team, what types of expertise are going to be required?  While precise skills are technology-dependent, at minimum you will need core team members with the following skills:

• Product Owner / Product Manager with mobile product management skills (see also Magenic Technologies' Product Owner or Product Manager?)
• Mobile Architect with mobile application architecture and enterprise integration skills
• Mobile Developers with specific experience and expertise on your chosen development platform and technology stack, including the ability to integrate supporting systems
• Mobile User Experience Designers who understand mobile devices, mobile interaction design, your chosen platform’s design guidelines, and mobile design/prototyping tools
• Mobile QA Engineers who with deep understanding of mobile device functionality, context and interaction models, mobile test strategies and tools, and an ability to test data at the code level

In addition to the core product development team, there may be also be extended team members from customer service, marketing, analytics/BI, back office systems’ IT (and this may be a significant need), operations, legal, security/compliance or other groups, depending on your industry and focus.

A major decision at this point is determining whether to make a long-term investment in full in-house mobile expertise, bring in staff augmentation resources to form a blended team, or work with partners to outsource development on a long-term basis (or until you reach a point where it makes sense to bring development in house).  In any case, locating, attracting and hiring resources with the right skills and experience—whether FT hires or through a partner—is a challenging task with many long-term implications.  (See also Magenic Technologies’ Are You Ready to Bring in a Partner to Create a Mobile App? and Best-in-Class Consultants or Learning on Your Dime?)

All staffing models can work; however, keep in mind that it will prove wise to work with mobile experts when building your mobile app’s foundational releases or tackling a complex initiative.

Takeaway:  A mobile product development team is composed of many specifically-skilled resources, many of whom are in short supply.  Plan to invest the time and funding in identifying and composing the best team you can find—it will be a top indicator of impending failure or success.

#4 – There’s a New Delivery Ecosystem in Town (Processes, Tools, and Infrastructure)

Delivery Methodology as Cost/Risk Control

As you’re assembling your product delivery team understand that this team can’t work efficiently or mitigate your considerable risks using a traditional waterfall-type delivery methodology.  The timeline from initiation to delivery is too long for a big bang release, there’s little room for re-prioritization, and your measurement of success will be totally different—you’re shooting for a business outcome, not merely coming in on schedule and within budget.  From a cost perspective, plan to embrace an Agile delivery methodology to reduce risks, increase flexibility, and best manage spend.

Mobile-Specific Tools Required

If you hire internal resources, plan also to invest in mobile-specific product development tools for developers, designers, and quality assurance engineers.  Additionally, you may need to also invest in enterprise mobile management (MDM/MAM) tools if you’re also investing in devices and/or using a private enterprise app store.  Furthermore, you may also need mobile analytics tools, mobile marketing tools—the list can go on.

Many mobile tools now are cloud-based and relatively inexpensive.  That said, licensing or usage-based fees can add up.  If you work with a partner and plan to bring development in house in the future, make sure that you own all tool licensing and subscriptions.

Infrastructure:  The Long Pole in the Tent

Believe it or not, updating your back office systems’ ability to support mobile applications may be your largest expense.  The integration architecture built to support web- or desktop client-based systems is poorly suited for serving mobile devices communicating over fragile (or offline) data connections with very high response, performance and scalability expectations.

In addition, your mobile app may require cloud-based services such as AWS, Azure, or Google Cloud—you will want to understand the various pricing models and available services.

In a recent interview with Diginomica, Kevin Benedict sums up the issue well:

“What we’re learning is that creating the world’s coolest mobile app isn’t going to do any good if your infrastructure can’t support real time interactions with your ERPs, and other business solutions and processes on the back end.  Mobile applications are driving this digital transformation back into the enterprise.  CIOs are saying, ‘We have to do this in order to be competitive, because more and more of our business is being transacted through our mobile applications.’”

Takeaway:  New delivery processes, mobile-specific tooling, and potentially extensive (and expensive) infrastructure updates will be needed.  Existing CapEx/OpEx financial cycles will be challenged to support an agile delivery team.  Significant CapEx—and leading time to implement—may be required to update back office infrastructure.

#5 – Expect Disruption (Competitive, Technology, and Market Pressures)

The harsh reality of the mobile world is that you can execute with all the prior strategic perspectives in mind and still be blindsided by an unexpected disruption or a competitive innovation that leaves you questioning your product’s enduring value proposition.  While this is also true of other channels, in our experience the innovation cycle is much more rapid and compressed in the mobile apps space.

From a financial perspective, these unexpected events create a variety of impacts from the relatively simple, such as supporting a new device, to the complex—perhaps a competitor is now driving his mobile app experience using artificial intelligence (AI).

Takeaway:  Plan to be financially flexible in order to quickly respond to the market.  Again, your customers will forgive you for falling momentarily behind if you establish a track record of responsiveness.  Better yet, plan to make the investment to be a mobile leader!

#6 – It Takes a Village (Digital Transformation)

As indicated earlier, to work most effectively toward enabling your mobile app’s capabilities to drive business outcomes you will need to form an extended team and socialize awareness so that all work in harmony to meet the same objectives.  

For example, if your industry is retail and your app is customer facing, what do your sales associates know about your mobile app?  Are there any promos in the store—or in promotional media—to advertise the app and its benefits?  Is the app integrated with your loyalty program?  What about integration with social media or coupon apps?  Does your web site highlight the app?  What happens if a customer calls Customer Service with a question about the app?  Is there an operational opportunity to use the app to significantly improve customer satisfaction such as through Buy Online / Pickup in Store?

Whatever your industry, know that you will need to identify and rally all customer (this includes internal users!) touch points in the organization to create a cohesive and consistent user experience.

Takeaway:  Plan to make the necessary investments of time and effort to raise internal awareness, make supporting roles and responsibilities clear, providing training or change management guidance, and communicate product plans and progress.

#7 – Innovate and Disrupt (Separate from the Field)

Have you considered that simply a having a cool mobile app won’t be the engine to drive targeted business outcomes?  Maybe everyone in your industry segment already has similar mobile apps.  Now what?  Can you afford to be a “me too” entry?

Depending on your market position and competitive pressures, you may need to consider investing in the necessary research to create an innovative new way of doing business that leverages customers’ “mobile moments” (see also Capturing the Mobile Moment) and fundamentally alters the value chain.  Innovation is typically an expensive proposition—think about the capital required to launch AirBnB or Uber.  Note that their mobile apps are only the tip of the iceberg in terms of technology and cost.

Takeaway:  Consider the possibility that a mobile app may only be a small part of an innovative streamlining of your industry’s existing value chain.  Creating something of this magnitude will require a full range of investment, not just a mobile app.

Closing Thoughts

Embarking on a mobile product journey is exciting but also full of risks, not least of which is being unprepared to make the necessary financial moves to ensure your initial investment is not lost. Making sure your financial bases are covered at the outset will go a long way to positioning your initiative for success.

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.

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.

Frictionless Mobile Experiences—and Why They Matter to You

We’ve all now heard how important a great mobile user experience is to customers.  But what is a “frictionless” mobile experience?

In the mobile context, “frictionless” means to simplify key elements of the user experience to the point where they’re almost unnoticed, taken for granted—and therefore truly delightful, and ultimately more useful.

Popular Examples
Let’s look at a few well-known examples:

Uber

Using location-tracking technology Uber knows where you are (you don’t have to supply an address) and the driver closest to you.  This makes getting a cab quickly one button press away—it couldn’t be any simpler.

Then, when your ride is complete, you just walk away.  No fishing for payment or tip, no receipt—no waiting while the cabbie fumbles for their manual credit card imprinter.  Secure.  Awesome!

Amazon

Amazon launched one-click buying in 2000.  Complex on the backend, but a simple-as-possible customer experience.

Now, with Amazon Dash, Amazon has made buying replenishable items even easier.  You’re out of laundry detergent?  Click a button mounted by your washer and another container of laundry detergent is shortly at your doorstep.  The cost of the Amazon Dash Button is rebated on your first purchase and shipping (with Prime) is free.  With apologies to Office Depot, this is the “Easy Button”!

Square

Square has something for both retailers and customers.  First, for retailers, Square is a small device that turns any connected smartphone or tablet into a point of sale terminal.  And transaction fees are lower than most competitors.

For customers and retailers alike, Square delights by associating your credit card with your account.  As a result, the retailer now has no need to print a receipt as your receipt will go directly to your email address—and you don’t have to carry a receipt or enter your email address (after the first time).  A very simple transaction for both parties.

Now let’s look at how to create a frictionless experience from another angle:  the learning pattern the experience requires.  Typical mobile experiences tend to be cognitive; that is, the learning pattern requires the user to read basic instructions in order to learn how to use an app.  Frictionless app experiences, however, tend to be perceptional where the learning pattern provides the user just enough information to allow an empathetic engagement where the user can “feel” their way through the experience.  No instructions required.

Here are several more examples from a learning pattern perspective:

Domino’s Pizza iPad App

By using a known, almost pre-prescribed perceptual learning pattern, customers engage and “play” with building the order they want.  Little or no cognitive learning is needed and the experience is almost entirely perceptual.  Customers are engaging in the experience without really knowing it.  The “why” can be understood by Domino’s mission statement: “Sell more pizza, make more fun."  The experience was so well received it got Domino’s a webby. 

Motion Savvy App

Natural user interfaces (NUI) are redefining what “frictionless” experiences can be.  Not only can they provide intuitive engagement patterns that are built on a perceptual learning model, they can take very complex cognitive learning patterns and translate them. The Motionsavvy mobile app uses a NUI to provide a masterful engagement model that will only become more mainstream as a learnable model.  Voice, eye tracking, gesture tracking and location will be the new input devices for these emerging models.  The “Why” is rooted in the source of all of user experience… the right accessibility offered in the best mental model.  Leap, Kinect for Windows, and Myo are all emerging and will redefine how we engage with our devices.

Shyp App

Using a very simple experience the customer becomes part of the process verses just engaging with an app. Simple, direct, and a clever model that plays on the embedded expectations that customers already have with regard to buying and selling on the web.

So, why does all this matter to you?  Because without a conscious focus on creating a frictionless experience pitfalls await.  A few examples:

• It is all too easy to simply duplicate an experience designed for the web
• Mobile’s unique hardware capabilities are not well used (e.g., GPS/location services)
• The mobile ecosystem is not effectively leveraged and you lose opportunities to add value

In short, you risk losing mobile users and that means losing significant business to competitors who are thinking how to create a frictionless experience.

How to Eliminate Friction
So, how can you make your mobile users’ experience frictionless?  Here are a few suggestions to get started:

• Simplify registration and authentication.  Use Facebook, Google+ or another service—don’t make users create yet another user account with IDs and passwords they won’t remember.  Use biometric authentication—no one forgets their thumb.  And don’t make a user log in unless they have logged out on purpose (secure apps like financials, healthcare, excepted).
• Respect users’ time (and lack of patience).  Can data be loaded in the background?  Can important information be shown on one screen instead of two?  Can a transaction be completed with one tap instead of two?  Or better, can you do something valuable for the user without their explicit input (e.g., use location services to fix their location, determine time to get to an appointment, etc.)?
• Use appropriate learning patterns.  “Intuitive” is overused when describing mobile user experiences.  But what we’re aiming for is an experience that flows (e.g., is perceptional), needs almost no explanations, clearly identifies objectives and makes it easy to perceive how to reach them.
• Remember.  Remember me and my data so that I don’t have to re-type anything.  If I have to input data, make it easy—for example, accept voice input or a text message (see what /Slash has done to make things easier).
• Leverage context.  Is the user at home, in a store, at an event or favorite haunt?  If they’re in a store, push information they want like offers or coupons.  If they’re at an event, inform them when friends are nearby.  Anticipate needs and desires.
• Technical ecosystem.  To make things even more seamless, make sure you take advantage of the users’ technology ecosystem.  For example, a user may have a smartwatch, TV device, tablet, etc.  How can those devices—all with their unique usage contexts—become part of a complete and satisfying experience?
• Experience ecosystem.  What partnerships with other apps might support your offering of a complete experience?  For example, Spotify partnered with Nike+ and RunKeeper to deliver music while users are exercising.  Sonos, who makes wireless audio systems, partnered with Pandora and Spotify to enable Sonos users to play their music libraries from directly inside the Sonos app.  Less friction, more satisfaction.

And, last of all, pay attention to the user experience through analytics and automated reporting of application issues—there’s always room for improvement.

Closing Thought
Create the frictionless mobile experiences users crave and meet your business objectives successfully.  Do something amazing!

Eight Reasons Why You Need Mobile Governance

Starting your enterprise mobile journey often appears deceptively easy.  

Someone identifies a business need for mobility, responds to a stakeholder’s interest or competition demands a mobile capability and then you either build or buy a solution.

What's the Worst that Could Happen?
However, companies quickly find that this ad hoc, tactical approach to enterprise mobility leads to a number of unfortunate results.  A few typical examples we see:

• The “brand injury” – User experience and brand representation is poor and creates any variety of off-message perceptions by employees, customers and/or partners.
• The “one-hit wonder” – No plan for product enhancement, not built for support and maintenance, architecture creates many risks such as privacy breeches, compliance problems, performance issues, etc.  See also “brand injury.”
• The “money pit” – Development approach is unsuited for meeting business objectives and much re-work, delays and technical debt result.  Or pursuing this project eats up budget for another more strategic project.  Executives regret they ever approved the work and mobile as a whole loses momentum.
• The “over-promise” – Inexperienced product teams are unable to meet business objectives due to technical challenges/delays, lack of stakeholder involvement, unrealistic expectations for success (or no defined success criteria), lack of user insight or inability to pivot based on actual results.
• The “stinker” – Skunk works project distracts key resources from valuable work, duplicates another initiative or is not aligned with the business, no effective leverage of best practices, infrastructure, existing code or business logic.  Who approved this?!  See also “one-hit wonder.”
• The “duplicate” – Someone decides that what’s needed is a mobile app that duplicates all the functionality of an existing web app or fat client app.  The app doesn’t address users’ “mobile moments” and is quickly on its way to life as shelf ware.  See also “brand injury” and “money pit.”

To avoid these common pitfalls, companies should make the investment not just in mobile development, but also in mobile governance.  

What exactly is mobile governance?  While mobile development is the execution of a specific release of a mobile product roadmap, mobile governance focuses on how to most effectively execute on all aspects of an organization’s mobile strategy, including management, measurement, best practices and standards—all with the objective of being best in class and achieving competitive advantage.

To better illustrate what mobile governance is and how it can help you be more effective, here are eight reasons why you need mobile governance:

Strategic Alignment and Focus

Making the right investments in mobile requires involving stakeholders from across the business, as well as key partners and customers.  This diverse group is best positioned to identify, organize, prioritize and fund mobile opportunities for the company as a whole and ensure alignment with overall business objectives and digital strategy.

To facilitate stakeholders’ priorities, the mobile governance team must socialize and manage mobile initiatives as a cohesive program made up of a number of product development efforts which will yield clear benefits.

Plan to periodically review prioritization—the competitive landscape and technology opportunities are highly fluid.

Business and Technical Oversight

Business oversight through the mobile governance team can prevent many of the negative scenarios described above.  Focus areas for business oversight include:

• Product portfolio management and product roadmap direction
• Legal and compliance
• Marketing and brand alignment
• Operational alignment, integration and readiness, including acceptance testing, pilot programs

Like business oversight, technical oversight has a major role to play in prevention of negative scenario development by providing clear guidance and support in the following areas:

• Support for and best use of enterprise mobile infrastructure
• Best practices for architecture and development, security
• User-centered design, adherence to platform standards
• Technical standards and approaches, preferred tools
• Quality management and testing methodologies, tools

Expectation Management

Like all nascent technologies, mobile is full of hype.  And, according to Forrester Research, even the most successful mobile applications take at least three major release cycles to find the right balance and meet business objectives; many must make a significant pivot after the first and/or second release.  Consequently, one of the most important functions of the mobile governance team is to set and manage expectations, including:

• Return on investment (ROI)—and when to typically expect it
• Total cost of ownership (TCO) for a product with many releases vs. a project
• Challenges and barriers to success.  Common example:  Immature or non-existent mobile infrastructure is a serious barrier to the best laid product plans and may require significant remediation and investment to enable the business to meet objectives for mobile initiatives
• Need for innovation and velocity.  Many sponsors expect they’ll just need one release this year—it’s the mobile governance team that needs to set enterprise expectations for competitive innovation and the development velocity to support it
• User expectations.  Much has been made of the “consumerization” of IT—and this applies particularly to mobile.  Product owners need direction on how to build the right experiences for different user groups.

Momentum

When it comes to building mobile capabilities for the enterprise and integrating mobile into overall digital strategy, companies often struggle to make progress—especially if they experience one or more the unfortunate scenarios described earlier.  

The mobile governance team must be well-positioned to drive enterprise visibility to and awareness of mobile initiatives.  By reaching the organization as a whole the mobile governance team can help drive collaboration among the many constituents required to design, build and maintain a successful mobile program.

Measurement and Reporting

The high percentage of mobile initiatives that have no or ill-defined success criteria would likely surprise you.  Or success criteria is defined but there’s no way to actually collect the supporting data.  At a higher level, mobile programs also need established measures of success and periodic reporting of results.

The mobile governance team must drive common measures of success for individual products.  Clear, regular and relevant communication of results by product teams will strengthen program momentum.  In addition, the mobile governance team should establish and report measurement of the mobile program as a whole.  

Finally, mobile governance should set standards for the use of mobile analytics and integration of mobile data into enterprise business intelligence to catalyze cross-channel insights.

Brand Protection

Design, quality and innovation signal brand vitality to employees, partners and customers.  One of the mobile governance team’s core tasks is to closely align with marketing to ensure:

• Product fit in overall brand strategy
• Brand guidelines are appropriately implemented
• User experience supports and enhances brand personality

Moreover, the mobile governance team must be a beacon that guides product teams in designing products that support brand cohesion.

Leverage and Scalability

Product teams tend to work in silos, especially if they are in separate business units or functional organizations.  This organizational fragmentation is difficult to oversee and often leads to inconsistent implementation of standards even when they exist.

One of the most important roles the mobile governance team can play is to enable organizational and technology leverage and scalability.  For example, coach product teams on best use of:

• Existing infrastructure services
• Common, reusable components and code
• Abstraction and configuration over custom or single-use code
• Skilled resources across products
• Agile methodology to achieve velocity

Equally valuable, the mobile governance team should foster cross-team sharing of experiences, lessons learned and how they implemented enterprise best practices.

Supportability

With product teams rightly focused on velocity, without oversight supportability is a frequent casualty.  And, as a result, products go into production that the organization is ill-equipped or prepared to support.

Consequently, the mobile governance team must establish application architecture standards for supportability, a clear process for support transition for various release types (major, minor, break/fix), and guidance for prioritization of common issues (new OS version support, device support, etc.).

In addition, the mobile governance team should set the enterprise standard for support tools such as EMM (enterprise mobile management, formerly mobile device management (MDM), MAM, and so on, to ensure operational support is effectively using tool capabilities to support the business.

Closing Thoughts

Clearly there are many persuasive reasons for organizations to consider implementing mobile governance.  However, mobile governance doesn’t have to start with a full Mobile Center of Excellence to be effective.  Start with a mobile "community of practice", grow toward a steering committee approach, and then, when your mobile product portfolio can support it, create a center of excellence.