Pivoting iomando

By January 2012 we already had a working prototype of a product 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 around such product.

We then set out to build what we believed was a “more valuable service” leveraging our product. But failed to understand what problem we were ultimately trying to solve.

Fortunately, the sole experience of developing and pushing the product forward, revealed the true problems our customers had. We shifted our focus to 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 systems worked. Our access technology had a simple feature that no one else had at the time: it was software based, running on a mobile app. This subtle twist enabled some key capabilities that our competitors couldn’t match.

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

Old systems like keys, remotes and all the stuff 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.

Redefining Access

The combination of these three features gave us the ability to manage the private property in a 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.

New trends were emerging 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: 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 at least some money out of them. It turned out that our 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 in combination with the nature of our technology, inevitably led us towards the parking industry. More precisely, private communal parkings inside buildings¹, where each owner had a spot, but the property of the entire parking didn’t belong to anybody in particular.

Exploiting Underused Assets

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, high value parking assets coexisted alongside huge demand, precisely located in the right place, but unmatched because these assets could not be accessed by third parties.

We realized that iomando could unlock and set free this hidden supply of empty spaces in key areas of the city. The nature of our technology could allow owners to give time-constrained permissions to potential users in order to use their unused spaces for limited amounts of time.

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 marketplace without (us) actually buying parking spots. On top of that, 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. On one hand, the owner could monetize their asset while he was not using it. On the other, we could create a marketplace of high value parking spots in the most critical areas of the city at a fraction of the price.

So, the game was on — we thought.

Our pitch went something like this…

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.

And here’s our solution:

…we could use our technology to surface this supply of empty spaces by creating a flexible access system that could securely grant permissions on demand.

Made sense, huh?

The Roll Out

Over these assumptions we set out to build a park-sharing platform: a service powered by our technology that enabled people to rent their parkings spaces for discrete periods of time. 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.

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 anything because the access system had to be installed anyway, so why not?

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

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

The kind of platform we were shooting for would naturally attract demand in the first place. They were the ones looking for parking and the sign up friction was non existing.

But amassing enough supply of parking spots from the get-go was critical to keep demand engaged. This 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 persuade spot owners to enroll, we faced several problems that kept the process really slow.

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 stages.

We realized what we really needed were parking spots 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 two-step approach, in where first we offered the mobile door opener service for free, and then a premium feature that could turn the space into a park-sharing platform.

This way we could easily capture the most valuable communities without going through the hassle of selling the park-sharing model upfront. During this process we would set up all the communities² with necessary hardware 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 them.

But we faced brutal rejection because owners were not sold to the idea of letting someone in.

In other words, the plan was working, but the conversion to the second stage was way lower than we expected, almost non-existing, 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, 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. 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.

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 convinced ourselves of a problem that nobody had. The journey had become all about solving inefficiencies in our heads, not listening to real customers. We were obsessed on those inefficiencies because that was the problem we wanted to see, that was our problem.

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 accesses and permissions in real time, a software based service to replace their keys and remotes.

We were so focused on our idea that we didn’t realize it until they told us the hundredth time. 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 it is today, an access control system based on mobile technologies, which in plain English means opening doors and stuff with your phone.

---