Showing posts with label POC. Show all posts
Showing posts with label POC. Show all posts

Friday, July 29, 2016

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.

Thursday, July 28, 2016

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!

Why Your Mobile Initiative Isn’t Getting Funded

One of the biggest challenges in starting your company’s mobile journey is getting funding.  Potential financial sponsors are often positioned at one of two extremes.  

On one hand, some sponsors seriously underestimate the strategy, expertise, and overall effort that goes into building mobile apps and supporting a successful mobile program.  These sponsors tend to make a number of faulty assumptions, often including the following:
  • We don’t need a strategy—let’s just start with my pet project idea and see what happens
  • We have people internally who can develop applications, so they should be able to do mobile apps, too
  • It’s a small screen—how much effort can it take?
At the other end of the spectrum, potential sponsors will find every reason why now is not the right time to tackle mobile enablement.  They will typically bring up a variety of valid—but surmountable—concerns that, if not effectively addressed, will kill your mobile initiative.  Here are some common examples:
  • Fear of the fluid technology environment and potentially wasted investment
  • Security and compliance risks
  • Existing technical debt, question ability to integrate legacy back office systems
In addition to the challenges presented by both types of sponsors, you may be making your own missteps in presenting a case for mobile investment.
  • Lack of focus on producing ROI by impacting key KPIs 
  • Lack of an innovative, compelling story—you’re just “mobilizing” existing processes
  • Unrealistic perspective on mobile TCO
  • Selecting a set of mobile technologies before having a solid grip on business objectives
Clearly, there are many pitfalls to getting your mobile initiative off the ground and securing funding.

Here are several ways you can address your financial sponsors’ assumptions and fears—and look smart in the process:

Start with Strategy
Do an assessment of the organization’s needs as a whole.  Identify mobile opportunities in terms of mobile moments.  Then prioritize based on business value, feasibility, risk, differentiation, opportunity for innovation, and so on.  Make sure to identify KPIs that impact the business for each potential mobile product.

This is often a good time to invest in a few proofs of concept.  Target opportunities to translate a series of mobile moments into an app vignette, which can be as simple as a visual prototype (no code) or a skeleton app (coded)—both of which must run on a mobile device.  

The key in either case is to create an amazing user experience that you can socialize to enable stakeholders to envision success.  Alternately, if you have technology risks, you may wish to focus on proofs of concept that smooth the way forward by addressing technical barriers.

Create Product Roadmaps and a Supporting Technology Roadmap
Think of your mobile opportunities as products, not projects.  Each product needs to have a roadmap that maps out evolving business value.  Look for opportunities to innovate, differentiate, and positively disrupt existing inefficient processes.  Each product roadmap needs to support a clear, compelling story of how investment is strategically aligned with overall digital strategy and business objectives.

Create technology roadmaps that support product planning.  Don’t make the mistake of selecting a technology stack before business objectives are clear!  Also be cognizant of the reality that user experience design for each product may also influence technology selection.

Technology road mapping is also a perfect time to align needed infrastructure upgrades with creation of new mobile products that will deliver clear value—don’t miss this opportunity.

Plan for Delivery
Become familiar with the key workflows and expert resources required to operate an effective mobile delivery organization.  Understand probable release cadence, deployment and all the factors that drive it.  Don’t hesitate to bring in outside experts to provide guidance both for delivery process and technology selection.

Be realistic in estimating TCO.  Identify which resources and skill sets may be staffed internally versus relying on partners.  Determine if your delivery strategy will be reliant on partners long term or needs to include a knowledge transfer plan to bring key components or roles in house over time.

How will product maintenance and support be prioritized?  Who will users call for help?  Who will be responsible for training support resources?

Don’t Forget Governance
Once the mobile journey is begun users’ expectations—already high--will quickly rise.  Plan how you will approach maturing your organization’s ability to manage a portfolio of mobile products.  From best practices to standard architectures to ensuring leverage and alignment with business objectives, position your mobile governance model to enable mobile teams, not create barriers.

Closing Thoughts
The secret to getting your mobile initiative funded is to align with business objectives, demonstrate a value-driven plan based on product roadmaps, plan for operational success, and put in place an appropriate governance model to sustain success.