From Mobile to Web app

 When all the industry seems to be shifting towards a mobile-first environment, we just made the opposite movement.

When all the industry seems to be shifting towards a mobile-first environment, we just made the opposite movement.

Last week we introduced the iomando Dashboard v1. It was a huge leap forward from our mobile app regarding management features, that our customers were demanding. Since then we've received a ton of feedback, but for the most part, it was directed to the decision of departing from mobile.

Curious, right? When all the industry seems to be shifting towards a mobile-first environment, we just made the opposite movement. So yes, it is a delivered strategy, and let me explain why we think it is for the best.

Context

iomando was released back in 2012. Before that, we explored other ways to build a business out of the technology we had already developed. Despite we shifted to a more product focused company, our main target remained in houses and small communities, where we saw a path with less friction and faster growth.

After a year of healthy sales, but without much traction, we struggled finding our place in the market. So we rethought our strategy from the ground up. We asked ourselves what was the unfair advantage that set us a part from our competitors.

We understood that the key laid on scale, adding units of capacity for free was something only our product could deliver. This was the spot where our competitors couldn’t reach us. And yet, we were serving a market where we couldn’t reap the benefits of it. We had a super power, but we weren’t using it at all.

So we looked for the places where we could make the most out of our scalability. This way we started to focus on large organizations, where access control was critical. We were putting our technology to work where it could really make an impact in order to solve a real problem. Since then, we’ve been growing faster than ever and all our efforts have been placed to build an amazing service that has rethought access systems for the mobile era.

 
 When iomando first came out it was aimed to small householders. This customer valued comfort over features.

When iomando first came out it was aimed to small householders. This customer valued comfort over features.

 

Well, after this almost too long (but necessary) historical context, we can start to glimpse why certain decisions had to be made in order to meet the expectations of our new customers. Following these lines there are three main reasons we shifted from a mobile environment to a web app.

Professional Management

As we mentioned before, when iomando first came out it was aimed to small householders. This customer valued comfort over features and, moreover, the management load wasn’t huge. Instead it might only had to activate their family once at the beginning, and use it again occasionally when it had some friends over dinner.

This use case was a perfect environment to roll out a mobile first management tool, because it reduced complexity and it encapsulated all the experience in a single app.

But as our priorities as a company shifted towards large spaces with thousands of users and a heavy usage of the permission assignment features, our customers, now professionals dedicated to access management, demanded something more powerful than a mobile app.

Access managers wanted data visualization, further customization, integration with their CRMs, bulk edits, import/export tools… Despite we really thought of unbundling the mobile app and developing a brand new mobile app focused only on management from the ground up, we finally went with a web app (more on that later).

Our company evolved and our customers did, too. So the tools we had in place at the beginning were not getting the job done for our new customers. They valued features over convenience, and we thought the web app approach was the way to go.

Mobile App Focus

At the beginning the number of users that were also customers (and therefore used the management abilities of the mobile app) were on a 1:10 ratio, but nowadays, the ratio is closer to 1:100 and growing fast. Therefore it didn’t make any sense to have all this burden in the app if only less than 1% of the user base were using it.

So the second point is all about clarity for the mobile users. As more and more users were activated on the service, customer support started to get more calls. Even though the theory says that a great service will run smoothly and your customer will be happy ever after, the reality was far from that.

 We felt more like a web service than an end client.

We felt more like a web service than an end client.

People emailed and called us with doubts and questions and we were beyond the capacity to attend everybody. That was also, yet another reason to bring the app to its basics, to do one thing, but to do it really well. We were aiming for clarity, and having the management capabilities unbundled from the app gave us the best opportunity to do just that.

Building a separate experience for the management tool, brought the ability to independently optimize for both experiences (managing and accessing) that had really different needs by its nature.

Flexibility and Fast Deployment

Finally the third reason we went with web app was the ability to further customize and iterate faster on the solution.

Our new customers for the management tool wanted to personalize their solution, adding corporate imagery and easily integrating with third party software they were already using. Our new horizontal approach required full control over the solution and sometimes we felt more like a web service than an end client, because we fully integrated with other apps that were behaving as a front end for our customers.

This a clear example of the tensions I discussed in a previous article, where the shift from a vertically integrated solution to an horizontal service provider resulted in suboptimal design choices and weakened the overall value proposition.

At the end though, we can summarize that the transition from mobile to web app had three plus one reasons.

  • Customers demanded more professional tools
  • It allowed for further independent optimization of both experiences
  • The modular approach and full customization required by the customer was better served by a web app
  • And of course, they wanted a bigger screen…

To keep on with the story you can check out the iomando series, or you can also look for other blog publications about iomando, mostly about product design, business strategy or company culture.