Why Mobile is So Hard in SaaS: There are (at least) Four Mobiles

echojason@gmail.com'

Jason Lemkin

Ok everyone gets how important mobile is.  It’s not lost on anyone, even if their roots are 100% desktop browser.  Some folks are 100% mobile.  Some are further ahead because of market pull (e.g., Box, DropBox, etc.).  Some are behind because so much data entry is involved in their apps.

But the one constant is that it’s hard.

Why?  One reason I think is that there really are four different mobiles in SaaS:

In consumer apps, broadly, there seems to be one main path:

  • Develop an iPhone iOS app (the largest market),
  • Copy it for Android
  • Then, make the iOS app better for large screens for the iPad via Universal App.

There are many exceptions in consumer of course but I’d suggest this is the primary path.

With business/enterprise SaaS, it’s more complicated, as the 2×2 above suggests:

  • The ‘boss’ or consumer of data will often have an elective experience — they’ll use the mobile iPad and phone versions to check on dashboards and progress.  Data entry is often secondary or irrelevant here.
  • The end user (e.g., a sales rep) may have both an elective experience — grabbing some data on the go — and also a mandatory experience — you must use e.g. EchoSign on an iPad to sign a contract with your customer face-to-face in the field.  For the latter, rich, but easy-to-input, data entry is critical here.
  • Services can be collaborative and interactive, which means you’ll want fast native apps for the rich and mandatory experiences — but generally HTML, app-free experiences for collaboration with 3d parties who you don’t want to force to download an app just to collaborate.

Everything can seem like a mess if you don’t have user experiences for each of these scenarios, and you probably will end up with 3-6 mini-platforms in the end.  Way, way more complex than just getting a web app to work in Chrome and Firefox 😉

For example, at EchoSign, the use case where Groupon and LivingSocial and Yelp all generate dynamic, web-based contracts and get them signed in the field on a iPad, has absolutely nothing to do with how a VP might counter-sign a contract on her Android phone.

If you talk only about one or two of these mobile use cases, you’ll probably never all get on the same page.  If you try and short circuit it with just one or two user experiences, you’ll probably end up with a very suboptimal user experience.

Published on September 25, 2012
  • This is why it is key to test and validate the use-cases BEFORE developing the App and the service. Asking WHY and WHO helps focus the efforts and deliver a better service and experience to the true audience.

Share This