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!