Esta semana pasada me contactaron de un fondo de venture capital para que les diese mi opinión breve personal sobre el producto de una start-up que estaban valorando.

Tras analizarla, recordé y les trasladé un aprendizaje muy valioso que los equipos de Microsoft nos mostraron a todos hace una década y que quiero aprovechar a compartir aquí también para que no caiga en el olvido.

Windows Phone

Allá por el año 2011, la gran tarta del pastel de sistemas operativos móviles estaba dominada por Apple y Android tras la gran caída de Symbian. En aquel momento ya se vislumbraba que la tecnología móvil iba a ser the next big thing, así que Microsoft se atrevió a dar batalla al duopolio.

La idea tenía sentido, Microsoft era una empresa experta en crear sistemas operativos y con la adquisición del vertical de móviles de Nokia, Microsoft poseía también la empresa que mejor hardware producía en el sector de los dispositivos móviles del momento.

Todos conocemos el final de esta historia y se pueden sacar muchos aprendizajes de ella. Sin embargo, yo quiero centrarme en un momento muy concreto de esta historia, el momento en el que los equipos de Microsoft lanzaron una iniciativa para portar las aplicaciones existentes en Android a Windows Phone.

El círculo vicioso

Una de las razones por las que Windows Phone no crecía era porque no había una comunidad de desarrolladores que creasen aplicaciones para Windows Phone. Todos los desarrolladores creaban apps para Android y para iOS.

Esto era una pescadilla que se mordía la cola, los usuarios no compraban Windows Phone porque éste no tenía muchas apps en su store y los desarrolladores no creaban aplicaciones para Windows Phone porque no había una masa crítica de usuarios que utilizasen éste sistema oeprativo.

[Imagen] -

¿Solución? En las oficinas centrales de Microsoft se les ocurrió la idea de crear herramientas que portasen automáticamente aplicaciones creadas para Android, el OS que más apps tenía, a Windows Phone.

De esta manera los desarrolladores podrían seguir creando aplicaciones para Android y a golpe de “click” publicarlas directamente en la store de Windows Phone. Así, el círculo vicioso se invertiría y Windows Phone comenzaría a ampliar su penetración en el mercado. Al menos en la teoría.

Sin embargo, de la teoría a la práctica hay un trecho. Lo que en teoría suena maravilloso, luego tuvo una práctica bastante problemática.

Los tres problemas

Android y Windows Phone eran sistemas operativos totalmente diferentes, con arquitecturas totalmente distintas y por lo tanto capacidades que no siempre podían hacerse coincidir entre sí.

Aunque estas herramientas portadoras de aplicaciones producían una traducción de interfaz de usuario que a golpe de vista pudiese parecer muy similar, poseían tres grandes problemas.

Por un lado, la performance de la app traducida a Windows Phone no era la misma. La aplicación en Android, corriendo bajo su arquitectura nativa ofrecía un rendimiento mucho más alto, los tiempos de refresco eran muchísimo mejores y no daban sensación de ir lentas como si ocurría en Windows Phone.

Por otro lado, los equipos de Microsoft estaban siempre por detrás. Android iba sacando nuevas funcionalidades de las que podían hacer uso las aplicaciones y Microsoft perseguía.

Los equipos de Microsoft andaban siempre 6 meses detrás en lo que a funcionalidad se refiere. Su roadmap se dedicaba a traducir estas funcionalidades una vez salían al mercado. Una estrategia de perseguidor.

Finalmente, los equipos de Windows Phone, que creaban nuevas funcionalidades para su sistema operativo y que podían ser muy novedosas, veían cómo éstas funcionalidades no se utilizaban y su capacidad de diferenciación era inexistente. Las aplicaciones portadas desde Android nunca las utilizaban al no tener un par adecuado en Android.

El aprendizaje

La experiencia demuestra que intentar crear tu propio ecosistema que tiene su propia arquitectura, basándote en la traducción de otro ecosistema ya existente que a su vez posee una arquitectura tecnológica diferente no funciona.

Crear software que traduzca otras arquitecturas a la tuya implica que los ecosistemas traducidos nunca funcionarán igual de bien que bajo su arquitectura nativa y además nunca ayudarán a poner en valor la diferenciación de tu ecosistema al no hacer uso tus propias soluciones nativas.

Desarrollar software que deba funcionar sobre dos arquitecturas totalmente diferentes hace que el software creado se quede con el mínimo común múltiplo de ambas arquitecturas subyacentes, creando una solución que no se queda con lo mejor ni lo diferencial de ninguna.

No juguemos a ser Android sin serlo, el original siempre será mejor. Busquemos otras estrategias si queremos romper monopolios.