Pivot

TL;DR

By January of 2012 we already had a working prototype of something that could be used to open doors with a smartphone. Curiously enough, we were convinced that it was not possible to monetize and build a sustainable business out of such service.

Therefore we set out to build what we believed it was a “more valuable” service leveraging our technology, but at the end, we failed to understand what problem we were ultimately trying to solve.

Fortunately, the sole experience of developing and pushing the service forward, taught us what problem our customers really had. We shifted our approach to a more product driven company, where we focused on the core technology to open doors and manage accesses, instead of the services that could be potentially built on top.

The First Business Model

Without even planning for it, our early prototype was redefining the way access system technologies worked. Our access system had a feature that no other access system had at the time: it was software based, and it was running on a mobile app. This subtle change made all the difference because it enabled some key capabilities that were, literally, not possible for incumbents to match.

From a simple app the user could open the door from a smartphone. The software replaced the physical keys and added a layer of security and convenience.

Old systems like keys, remotes and all the stuff you used to access most places, were hardware based. That meant mainly three things:

  1. They cost money: to create an additional copy of that key you incurred a production cost. That didn’t happen with iomando, since the cost for production and distribution of additional units was virtually zero.
  2. They could not be updated: once a key was produced, you could not change nor upgrade their capabilities. A mobile based system like iomando could be updated at anytime to add new functionalities, improve the experience or leverage any new technology.
  3. They were static: once you gave away a key, you were granting a 24/7 permission to a place and the administrator lost control over its property. Instead, when you granted a permission with iomando, you did it from a web based tool where you controlled the access parameters, that could be changed at any given moment, in real time.

The combination of these three features gave us the ability to manage the private property in an flexible way. The old paradigm was constrained by the static nature of keys and remotes. That meant it was not possible (or at least much more difficult) to grant access to a private property to other people for small periods of time, while you were not actually using it.

iomando app v1

Our goal was to design a simple interface everyone could relate to. We tested a few designs and found out that a big button was a metaphor from the real world that everybody understood. Back then skeuomorphism was at its prime.

At the same time new trends were just starting to flourish in this direction. The so called shared economy was getting traction in a context of crisis, where technology enabled people to put their assets to work in a smart way.

The timing could not be better because Spain was still digesting the consequences of a big financial crisis that lead an unnecessary overspending. People just bought cars, houses and a lot of fancy stuff. But when the party was over, they realized they didn’t even need all of that. Even worse, they couldn’t pay for it. So the logic thing to do was to put those assets to work to get some money out of them. It turned out that technology could make that happen.

The combination of these three features inevitably led to the change of a fundamental assumption: the access to private property was no longer tied to static ownership, instead with iomando we could now grant discrete permissions to anybody. A mobile app controlled from the cloud was now your key, so we could safely unlock an asset, just for small periods of time, when it was not being used by its owner.

Both the opportunity in the sharing economy space and the nature of our technology guide us towards parking spaces. More precisely, private communal parkings inside buildings [1], where each owner had a spot, but the property of the entire parking didn’t belong to anybody in particular.

Due to the mobility of cars and people during the day, parking spots spent most of the time empty, unused. But the curious thing was that those empty spots were located in the most precious zones of the city, where parking was the most difficult.

Paradoxically, we had high value assets with great demand, precisely located in the right place, but unused because they could not be accessed by third parties.

We realized that iomando could unlock and set free this supply of empty spaces in key areas of the city. The nature of our technology could potentially allow the users to give discrete permissions to people in order to use their empty spaces for a limited amount of time. By doing this, owners of an empty parking spot could monetize their asset by the hour with micro rents in a way it wasn’t possible before.

The service could potentially become an alternative to traditional parking at a fraction of the price, because the operational cost of running the service was dramatically low. All the assets belonged to the owners, so we could add capacity to the market without actually buying parking spots. And on top of that, spot owners could offer lower prices because their micro economies allowed to turn almost all revenue into net profit.

With iomando it was possible to surface this hidden supply of empty spaces. This way, on one hand, the owner could monetize their asset while he was not using it. And on the other hand, we could create a marketplace of high value spots in the most critical areas of the city at a fraction of the price.

So, the game was on.

We detected a problem: finding a parking spot in some areas of the city was hard and expensive.

Then we saw an opportunity: there were a lot of empty spaces in those areas, but they could not be accessed because of the static nature of access control systems.

Finally we proposed a solution: we could use our technology to surface this supply of empty spaces by creating an elastic access system that could securely grant permissions on demand.

Made sense, right?

The Roll Out

Over these assumptions we set out to build a park sharing platform: a service that enabled people to rent their parkings spots while they were not using it. From our mobile app, the renter would select a parking nearby, introduce the time frame, and access and pay with the touch of a button.

We would use our technology to power the platform and enable people to rent their space for discrete periods of time. In addition, almost as a courtesy service, we’d also provide an access system from the smartphone to the owners. That wasn’t a strategic decision, it was simply something we thought it was cool and didn’t cost us more, so why not?

There were still a lot of raw edges and minor technological details such as what happened when a renter didn't leave the space in time? How to guide the user indoors to find his spot?

Despite our biggest challenge was not a technical problem: we just discovered what a two sided market place meant.

That kind of platform would massively attract the demand in the first place, because they were the ones looking for parking, and the sign up friction was non existing. But amass enough supply of parking spots from the get-go was the hard part. In order to keep the ball rolling, the initial supply of spaces had to be, at least, at par with the demand.

At that point it was obvious that the supply side of the market didn’t exist and it couldn’t grow organically, therefore, it had to be artificially created. From that point signing up a critical mass of communities became our main goal.

But in our attempts to convince spot owners to enroll, we faced several problems that kept conversions really low.

  1. Security: despite old systems were not secure at all and bad security practices were common among the owners, they were deeply concerned about the security involved in letting someone into the private property.
  2. I don’t want to be first: the fear of being first at something is usually a problem when you push a new idea into the market. But in this case it was a deeper problem because there was value compromised — as seen in point one.
  3. Communal spaces: that was by far the most difficult to solve. In a communal space there’s no clear decision maker and the default answer in front of a risky decision was always no.

The Workaround

In order to convince owners and argue against these reasonable points we designed a strategy that worked in two steps.

We realized what we really needed were communities in the more critical areas of the city. It was obvious that we weren’t going to get them right off the bat, so we designed a dual-step approach, in where first we offered the mobile door opener service for free, and a premium feature that could turn the space in a park-sharing platform in the near future.

This way we could easily capture the most valuable communities without going through the hassle of confronting the park-sharing model. During this process we would set up all the communities[2] with the hardware required to activate the park-sharing business, but with the “excuse” of the door opener system.

Deploying all these “seeds” around the city was great, but ultimately we wanted the communities to put their empty spots in the marketplace, so we could make some money out of it. But we still faced brutal rejection because owners were not sold to the idea of letting someone in in their communities.

In other words, the plan was working, but the conversion to the “premium” plan was way lower than we expected, and we were running out of money.

The Pivot

The takeaway of more than a hundred meetings with building managers and parking administrators was clear: they were far more interested in the system to open doors, rather than the possibility to share their spots while they were away.

It was astonishing for us, it brought us back to earth. We realized that we were trying to solve a problem no one had. Yes, there was a market opportunity. Yes, there was something inefficient that could be optimized. And yes, any city could benefit from such service.

But (and that’s a big but) we were not solving their problem. They didn’t even knew that was a problem to begin with. Yes, their spots were always empty “but that’s how it is, right? It has always been this way. Why change it?”, that’s the kind of skepticism we were surrounded by. Of course they understood the idea. Of course they understood the upside. But our enthusiasm was not enough to bend the power of “it has always been this way and we’ve been fine so far”.

We dived so deep into the problem that it became a fixation. The journey had become all about solving inefficiencies, not listening to the customers. We were obsessed on those inefficiencies because that was the problem we wanted to see, that was our problem.

We fooled ourselves with a problem that nobody had. We were trying to solve for a problem, but we never asked before. Sometimes when you are so immersed you become blindsided and the reality bends at your will. It was brutal for us to admit we were wrong. Now I see it as one of the most valuable lessons I always bring with me, but then I saw it as the most silly failure.

Dealing with failure (even more the first time) is a topic for another post, but there’s a bright side to the story. Despite we were wrong about our first assumption, our customers showed us the right path. They were clearly interested in a system to manage access and permissions in real time, a software based service to replace keys and remotes.

We were so focused on our idea that we couldn’t realize it until they told us a hundred times. The real problem our service solved was right there, waiting for us to pick it up. At that point, we shifted our business strategy and iomando became what is today, an access control system based on mobile technologies, which in plain English means opening doors and stuff with your phone.

You can check out the complete iomando series, where I documented the story of the company, or look for other iomando articles, mostly about technology and product design.


[1] In Europe, particularly in crowded cities like Barcelona, people live in buildings, not houses. More often than not, the lower floor is a communal parking space for the neighbors of that building. Each neighbor owns a spot, but the whole parking is a communal space. This leads to an interesting conjecture because all of the owners of a spot are owners of the parking, but no one owns it entirely.

[2] The basic hardware requirements to enable the the park-sharing business was the same as the mobile door opener, an “always connected” electronic attached to the door. Of course, in order to set up an “enhanced” park-sharing platform it was necessary to install sensors in each spot and more sophisticated equipment, but to kickstart the platform, the door opener was all we needed.