Capítulo 05 – La jugada y la decisión de actuar

Tiempo estimado de lectura ( 35 minutos)

En los capítulos uno a cuatro, he cubierto los conceptos básicos de mapeo , patrones económicos comunes y doctrina . Sin embargo, estos mapas de negocios de Wardley no le dicen qué hacer más de lo que un mapa geográfico le dice a un Almirante cómo ganar una batalla. Los mapas son simplemente una guía y usted debe decidir qué movimiento va a hacer, dónde va a atacar y cómo navegar su barco a través de las aguas agitadas de la competencia comercial. En otras palabras, debes aplicar el pensamiento, decidir actuar y luego actuar. En este capítulo vamos a cubrir mi viaje a través de esta parte del ciclo de la estrategia, ver figura 46.

Figura 46. El juego y la decisión

Identificando la oportunidad

Existen dos formas diferentes de por qué en los negocios: el por qué del propósito (es decir, ganar el juego) y el por qué del movimiento (es decir, mover esta pieza sobre eso). El motivo del movimiento es en lo que me voy a concentrar aquí, pero para examinar esto, primero debemos entender el contexto, orientarnos en torno a esto y luego podemos determinar dónde atacar.

Antes de 2005, había asistido a muchas reuniones donde se me presentaron opciones a mí y a mi equipo ejecutivo y luego tomamos una decisión basada en argumentos financieros, intuición y conceptos básicos. Nunca habíamos usado un contexto para ayudar a determinar dónde podríamos atacar. Esta fue la primera vez para nosotros y en gran medida un ejercicio de aprendizaje. Tomé el primer mapa de 2005 y destaqué las cuatro áreas que consideramos que tenían potencial. Hubo muchos otros, pero en aras de la introducción, pensé que sería simple. Estas cuatro esferas se muestran en la figura 47.

Figura 47. Cuatro diferentes lugares

Donde 1– Teníamos un servicio de fotografía online que estaba en declive pero en el que podíamos concentrarnos. Existían muchos otros competidores en este espacio, muchos de los cuales estaban bien financiados (por ejemplo, Ofoto) o por delante de nosotros en términos de oferta (por ejemplo, Flickr). También había necesidades no satisfechas que habíamos encontrado. Como empresa, habíamos adquirido muchas capacidades y habilidades, no necesariamente en el negocio de la fotografía online, ya que el grupo desarrolló muchos tipos diferentes de sistemas. También tuvimos un conflicto interno con el servicio de fotografía online de nuestra empresa matriz que creamos y operamos. Si bien nuestro servicio de fotografía estaba abierto al público, el servicio de la empresa matriz se centró en los propietarios de sus cámaras y tuvimos que jugar con cuidado aquí, ya que nuestro propio servicio a veces se consideraba un competidor. Teníamos dos usuarios externos (nuestros clientes públicos y nuestra empresa matriz) y, aunque no se exploraron en el mapa anterior, tenían necesidades conflictivas. Al satisfacer las necesidades de nuestros consumidores públicos en el sitio público, podríamos disminuir el valor visto por nuestra empresa matriz en su propia versión. Por ejemplo, hacer que sea más fácil para los consumidores públicos cargar imágenes desde teléfonos móviles no le sentaba bien a una empresa matriz que intentaba vender cámaras.

Donde 2 : habíamos anticipado que una plataforma de ejecución de código se convertiría en una utilidad (lo que hoy se llama sin servidor (serverless) ). Recuerde, esto fue en 2005 y mucho antes de que aparecieran sistemas como AWS Lambda. Teníamos amplias habilidades en el desarrollo de plataformas de codificación, pero lo más importante, también habíamos aprendido a no hacer macro proyectos tipo «estrellas de la muerte» que resultan dolorosas tratando de abarcarlo todo. Habría inercia a este cambio entre los vendedores de productos que nos beneficiarían en nuestra apropiación de tierras. Para complicar las cosas, muchos clientes de productos existentes también tendrían inercia y, por lo tanto, tendríamos que centrarnos en las nuevas empresas, aunque esto requería marketing para llegar a ellas. También hubo una posible compensación aquí ya que cualquier plataforma se construiría en última instancia sobre alguna forma de infraestructura de servicios básicos similar a nuestro propio sistema Borg (un entorno de cómputo de servicios privados que operamos proporcionando máquinas virtuales a demanda, basadas en Xen) y esto reduciría nuestra inversión de capital. Nuestra empresa tenía mandatos de la matriz para seguir siendo rentables todos los meses y mantener el personal fijo, por lo tanto, no tenía espacio para expandirme y cualquier inversión realizada tendría que salir de las ganancias mensuales existentes a pesar de las reservas acumuladas en el banco.

Donde 3 : habíamos previsto que aparecería una infraestructura de servicios básicos. Teníamos experiencia en hacer esto, pero no teníamos ninguna capacidad de inversión significativa. También tuve en cuenta que en algunos círculos de la empresa matriz se nos consideraba una tienda de desarrollo al final de un proceso de demanda y la empresa matriz estaba muy comprometida con una empresa de alojamiento externo. En este caso, las necesidades de la empresa matriz (muchas de las cuales podrían describirse como políticas) estaban potencialmente en conflicto con nuestras necesidades comerciales. Desafortunadamente, me había pintado en este rincón con mis esfuerzos anteriores para simplemente «sobrevivir». Si hicimos este movimiento, en esencia muchos de estos problemas no eran diferentes del espacio de la plataforma, excepto que los beneficios de agilidad de la plataforma se consideraban más altos. El mayor desafío potencial para nosotros no sería de productos existentes (por ejemplo, fabricantes de servidores) o vendedores de alquiler (por ejemplo, empresas de alojamiento), sino de empresas como Google entrando en el espacio. Esperábamos que esto ocurriera en el futuro próximo y, desde luego, carecía de la fuerza financiera para competir si así fuera. Parecía más prudente prepararse para explotar cualquier movimiento futuro que ellos hicieran. Sin embargo, eso decía que era una opción atractiva y que merecía la pena considerar. Una mosca en la pomada fue la preocupación que habían planteado varios miembros del equipo sobre cuestiones de seguridad y posible mal uso de nuestros sistemas por parte de otros. Parecía que tendríamos nuestra propia inercia a combatir debido a nuestro propio éxito pasado con el uso de productos (es decir, servidores) y a pesar de la existencia de Borg. También tendríamos que luchar contra múltiples formas de inercia: por un lado la empresa matriz y por el otro contra un posible servicio de Google; todo esto parecía un mal negocio.

Donde 4 : en su lugar, podríamos construir algo nuevo y novedoso basado en cualquier entorno de utilidad (infraestructura o plataforma) que apareciera. Entendimos que el uso de sistemas de servicios básicos reducirían nuestro coste de inversión, es decir, la apuesta en el espacio. Sin embargo, cualquier cosa nueva seguiría siendo una apuesta y nos enfrentaríamos a muchas otras compañías. Afortunadamente, éramos muy hábiles en el desarrollo agile y teníamos muchas ideas locas que podríamos perseguir generadas por los días normales de hackeo que llevábamos a cabo. Puede ser una apuesta en la oscuridad, pero no una que deberíamos descartar de mano. Tenía el beneficio de «solo esperar y ver» , podíamos continuar construyendo y esperar a que el mercado lanzara servicios que pudiéramos explotar. Por desgracia, no soy el tipo de persona que quiere sentarse y ver a otros crear el campo antes de explotarlo.

Mirando el mapa, teníamos cuatro «lugares» claros a los que podríamos atacar. Podríamos discutir el mapa, los pros y los contras de cada movimiento de una manera que no era solo «¿esto tiene un ROI y es esencial?» En cambio, estábamos usando el contexto para ayudarnos a anticipar oportunidades y puntos de ataque. De repente sentí que nuestra estrategia se estaba volviendo más significativa que simplemente sentir las sensaciones y copiar memes de otros. Estábamos pensando en la posición y el movimiento. Estaba empezando a sentirme un poco como ese sabio ejecutivo que había conocido en el ascensor del hotel Arts en Barcelona cuando estaba probando a ese joven (es decir, a mí) hace tantos años. Me sentía bien pero quería más. ¿Cómo decido?

Los peligros del éxito pasado

Un problema importante en torno a tomar una decisión generalmente proviene del éxito pasado y la comodidad que este brinda. Teníamos un servicio de fotografía existente junto con otras líneas de negocios que generaban ingresos decentes. Fuimos cómodamente rentables y la vida era bastante fácil. ¿No sería mejor para mí seguir haciendo lo que estábamos haciendo? ¿Por qué mecer el bote? Me arriesgaría a cambiar el curso en el que estábamos. Sin embargo, recientemente había visto a otra compañía errar en administrar el cambio y estaba muy consciente de los peligros de no correr riesgos. Esa compañía era Kodak.

Al ser un servicio de fotografía online, tuve un asiento en primera fila para el cambio fundamental que sucedió en el mercado de la imagen entre 2000 y 2005. La foto había sido vista como algo valioso para los clientes debido a sus costes en términos de tiempo y dinero para producir: visita al laboratorio fotográfico, el coste del procesamiento y la espera de que se entregue por correo. La película estaba en el centro de esto y lo único más molesto que esperar a que se procesara era no tener suficiente película para tomar la próxima toma de vacaciones. Muchas veces en el pasado, tuve que elegir qué foto tomar debido a la cantidad limitada de fotos que me quedaban. Sin embargo, la imagen y la película fueron realmente solo componentes para satisfacer mi necesidad general de compartir mis experiencias. La imagen también evolucionó de una película analógica a un nuevo mundo digital en el que podía tomar fotos y eliminar las que no me gustaban. Es posible que tenga un límite en términos de tarjeta de memoria, pero siempre podría descargar en una computadora y compartir con otros. No se requirió procesamiento de película.

Creé un mapa para ese contexto cambiante en la figura 48 y a medida que avance en mi experiencia con la historia de Kodak, haré referencias a ese mapa. El viejo mundo era uno de cine analógico ( punto 1 a continuación ). Compartir un momento consistía en sentarse en el sofá con amigos y familiares y pasar el álbum de fotos. La película en sí misma necesita algún mecanismo de realización, como el laboratorio fotográfico. Sin embargo, la industria de las cámaras se estaba convirtiendo rápidamente en un producto básico con cámaras desechables lo suficientemente buenas. El mundo analógico de las imágenes también estaba cambiando a uno que era más digital ( punto 2 ). Las cámaras digitales se han desarrollado a partir de cámaras ( punto 3) y se estaban volviendo más comunes. Podría compartir una imagen simplemente enviándola por correo electrónico a otros. Kodak había liderado la carga en este nuevo mundo valiente con una investigación temprana a mediados de la década de 1970, pero de alguna manera también parecía estar perdiendo terreno frente a otros como Sony y Canon.

Figura 48. Como estaban cambiando las imágenes

El crecimiento de las imágenes digitales y la difusión de Internet han permitido la formación de servicios de fotografía online. Estos proporcionaron formas simples de imprimir sus imágenes junto con medios más fáciles para compartir con otros. Se produjo un cambio muy notable desde la impresión hasta el intercambio. Puede crear redes sociales para compartir imágenes sobre pasatiempos o, en cambio, compartirlas con un círculo cercano de amigos. Uno de los primeros pioneros en este espacio fue Ofoto, que había sido adquirido por Kodak en 2001. El mensaje de Kodak también había cambiado durante este tiempo, se convirtió más en compartir experiencias y momentos. Sin embargo, Kodak no era el único competidor en el mercado y, a diferencia de muchos otros, Kodak parecía tener un problema ya que generaba importantes ingresos por el procesamiento de películas. He mostrado este problema en la figura 49 con el aumento de los servicios de fotografía en línea (Punto 4 ) y la inercia creada por el cumplimiento ( Punto 5 ).

Figura 49. el auge de los servicios de fotografía en línea

Si bien tenía una posición sólida en cámaras fotográficas digitales y servicios de fotografía online, Kodak no parecía estar maximizando esto. Otros rápidamente se estaban poniendo al día y adelantando. Solo puedo suponer que la inercia creada por su éxito pasado con el cine fue significativa, sospecho que hubo oposición al cambio dentro de la organización. Supongo que el tipo habitual de líneas de «lo digital es solo un pequeño alevín» , «las fotos son el negocio real», «esto canibalizará nuestro negocio» fueron expulsadas .Para un observador externo, ciertamente parecía que Kodak estaba en conflicto consigo mismo. Los primeros signos de esto ya eran evidentes a finales de los 90 con el lanzamiento del sistema de cámara Advantix, una curiosa combinación de cámara digital que producía películas para su procesamiento. Un intento un tanto extraño de tener el mundo digital pero aún mantener el análogico: «¡Es nuevo pero igual que el viejo!»

También hubo mensajes contradictorios que salían de Kodak a pesar de sus mensajes, mientras que una parte de la organización parecía presionar digitalmente, otra parte parecía resistirse. Finalmente, en 2003, Kodak introdujo la base para impresora Easyshare 6000 que permitía a los consumidores producir impresiones fotográficas Kodak en casa a partir de imágenes digitales. Cuando escuché esto por primera vez, sentí que Kodak finalmente había superado su inercia a través de un compromiso entre el cumplimiento y el negocio digital ( punto 6 en la figura 50 a continuación). El futuro era uno de un sistema Kodak autónomo, desde cámaras digitales hasta servicios online e impresoras fotográficas. Pero hubo un problema aquí. «Los teléfonos con cámara» surgió combinando las dos cadenas de valor del teléfono móvil y la cámara digital. Ya en nuestro sitio web habíamos sido testigos del rápido crecimiento de las imágenes tomadas con teléfonos con cámara ( punto 7 ).

Figura 50. La solución y su destino

Estos «teléfonos con cámara» todavía eran poco comunes, pero parecían anunciar un futuro en el que las personas tomarían fotos con sus teléfonos y las compartirían en línea. Hoy, pocas personas los llaman teléfonos con cámara, nosotros los llamamos teléfonos móviles. Se supone que cada teléfono móvil es una cámara.

En aquel entonces, sin embargo, estaba claro que no había un futuro de mercado masivo para la impresión, solo un nicho en comparación con un enorme mercado de imágenes digitales compartidas. Parecía que Kodak había superado su inercia a través de un compromiso que significaba invertir exactamente donde no iba a estar el mercado futuro. A principios de 2005, desde nuestra perspectiva, el futuro de toda la industria, desde el cumplimiento hasta las impresoras fotográficas, las cámaras, las películas y las cámaras digitales ( punto 8 ), comenzaba a parecer sombrío.

Figura 51. El fin del mundo analógico

Para nosotros, el futuro de las imágenes se parecía más a la figura 52 y apenas valía la pena mencionar las fotos impresas a menos que tuvieras la intención de especializarte en un nicho rentable.

Figura 52. Una imagen futura

En cualquier elección que iba a hacer, tenía que tener cuidado con la inercia y el éxito pasado. Simplemente estar donde estábamos podría ser la opción cómoda, pero eso no significaba que tendríamos un futuro prometedor. Nuestros problemas en torno al servicio de fotografía de nuestros padres podrían crecer si adoptamos el futuro de un teléfono con cámara, ya que esto nos pondría en conflicto directo con su negocio principal de cámaras digitales. Sin embargo, Kodak fue un claro ejemplo de lo que podría salir mal si no te movías lo suficientemente rápido hacia el futuro, permitías que la inercia te frenara o te comprometías al colocar las apuestas en el lugar equivocado. Pero tal vez haya otro futuro que podamos encontrar, pero ¿cómo de lejos deberíamos mirar en el futuro ?

Lo cercano, lo lejano y lo loco

A finales de los 90, me había interesado mucho la impresión 3D. Fue la razón principal por la que originalmente me uní al servicio de fotografía online casi en quiebra a principios de 2000 porque imaginé un futuro en el que se compartirían imágenes de cosas físicas. Quería aprender sobre el espacio para compartir imágenes. El hecho de que fuimos adquiridos por uno de los fabricantes de impresoras más grandes del mundo, me llenó de alegría. Asumí que ellos también compartirían mi pasión. Realicé numerosas presentaciones sobre el tema tanto externa como internamente dentro de la empresa matriz sobre este tema y, para mi desilusión, siempre fue la multitud externa la que se entusiasmó más. En 2004, hice una presentación en Euro Foo sobre el futuro de las impresoras 3D. El tema era un tema bastante candente en ese momento y uno de los asistentes que tuve la suerte de conocer fue Bre Pettis, quien estaba demostrando su impresora de rotulador, el DrawBot. ¿Por qué afortunado? Bre fundó MakerBot y posteriormente sacudió el mundo de la impresión 3D.

Si bien la impresión 3D era una pasión, también me interesaba la electrónica impresa, especialmente el trabajo de Sirringhaus y Kate Stone. Comencé a usar estos conceptos para describir un mundo futuro de cómo cambiaría la fabricación. Los conceptos básicos se proporcionan en la figura 53, pero veremos cada paso de este mapa. Asumiré que te estás familiarizando con los mapas, por lo que nos sumergiremos en ellos.

Figura 53. Lo cercano, lo lejano, lo loco

Primero, comencemos con la necesidad del usuario de algún dispositivo ( Punto 1 ). Lo dejaré como genérico porque quiero cubrir la fabricación en sí y no el uso específico de un dispositivo sobre otro. Nuestro dispositivo tendría elementos físicos, incluida la electrónica, junto con cualquier software que interactuaría con él. Los elementos físicos y electrónicos se describen comúnmente a través de alguna forma de diagrama de diseño asistido por computadora (CAD) que proporciona instrucciones sobre qué construir y esto se combina con nuestro software, que es simplemente nuestro código ( Punto 2 ).

La forma física normalmente sería fabricada por una factoría que generalmente usa maquinaria común involucrada en procesos personalizados significativos. Sin embargo, esto estaba empezando a cambiar con conceptos como las fábricas digitales e incluso las impresoras 3D que se estaban volviendo menos mágicas y más comunes ( Punto 3 ). Esto prometía un mundo futuro de factorías altamente industrializadas sin una amplio cambio de maquinaria para cada producto ejecutado. Además, desde los primeros transistores impresos por inyección de tinta de Sirringhaus en 2001, un nuevo campo de plástico y electrónica impresa estaba creciendo rápidamente ( Punto 4) La fabricación de productos electrónicos estaba en camino de industrializarse y simplemente imprimía los productos electrónicos que necesitaba en lugar de combinar una combinación de componentes básicos y no básicos en mi propia placa de circuito creada en una línea de ensamblaje que cambiaba con cada ejecución de producto.

Para mí, el aspecto interesante de esto fue la combinación de formas físicas y electrónicas. En 2005, me di cuenta de varios esfuerzos dirigidos por la Universidad para crear objetos híbridos, incluidas cajas de conexiones donde se imprimieron tanto la forma física como los componentes eléctricos ( punto 5 ). Esto también se industrializaría en un mundo en el que imprimí todo mi dispositivo en lugar de usar fábricas que ensamblaban. Ahora, junto con el potencial para crear nuevos materiales y componentes, esto también tuvo la oportunidad de cambiar fundamentalmente el concepto de diseño.

La función de un dispositivo es una combinación de su forma física, su electrónica y cualquier software que interactúe con esto. A medida que las impresoras híbridas se industrializan, esta función se describe por medios puramente digitales: el CAD (un conjunto de instrucciones) que luego se imprime y el código (un conjunto de instrucciones) que se ejecuta. Cuando deseamos cambiar la función de un dispositivo, entonces necesitamos cambiar uno de esos dos conjuntos de instrucciones junto con considerar la interacción entre los dos. Normalmente, tratamos de hacer cambios en el software porque es menos costoso, pero a medida que el hardware se vuelve más maleable, la ecuación cambia. También significa que ahora estamos en condiciones de describir simplemente la función del dispositivo que queremos y permitir que un compilador determine cómo se debe instanciar en los conjuntos de instrucciones.

Mi deseo de agregar un reloj solar a mi teléfono podría lograrse a través de software o medios electrónicos o físicos o una combinación de todos: un compilador podría resolver ese árbol de decisiones para mí. Esto abre la posibilidad de una nueva forma de lenguaje de programación que se compila en formas físicas, electrónicas y de codificación y donde los diseñadores se concentran en describir la función de la cosa e incluso la herencia de objetos en el mundo físico. Llamé a este lenguaje de programación teórico SpimeScript ( punto 6 ) en honor al maravilloso libro de Bruce Sterling sobre Shaping Things. Este tema fue el tema central de una charla que di en Euro OSCON en 2006.

Sin embargo, anteriormente había planteado estas discusiones dentro de la empresa matriz y me había dado cuenta de que, si bien podríamos hacer previsiones de cambio en el futuro, cada vez más se basaban en capas de incertidumbre y eran cada vez más desconocidas e incómodas para los demás. A medida que avanzábamos, más locas sonaban las ideas y las personas más preocupadas se revolvían ante ellas. Esto en sí mismo crea un problema si tiene la intención de motivar a un equipo hacia un objetivo. Por lo tanto, si iba a elegir un curso de acción, tenía que empujar el límite pero no demasiado lejos para que pareciera ciencia ficción.

Estaba empezando a sentirme incómodo con: –

Donde 1 : concéntrese en el servicio de fotografía online, por razones de inercia y conflicto.

Donde 4 : construya algo nuevo y novedoso basado en futuros servicios industrializados, por ser demasiado amplio.

en este punto, las preguntas que nos hicimos fueron: Dadas nuestras elecciones, ¿podríamos influir en el mercado de alguna manera para beneficiarnos? ¿Podría eso ayudarnos a decidir por qué aquí?

Aprendizaje de jugabilidad específica del contexto

Juego específico del contexto: aceleradores, desaceleradores y limitaciones
Entendí que todo evolucionó debido a la competencia y tenía muchas pruebas para mostrar ejemplos pasados ​​de electricidad a tuercas y tornillos. La pregunta era ¿podría influir de alguna manera en esto? Por coincidencia, desde los primeros días de 2001 no solo habíamos sido usuarios de código abierto, sino también contribuyentes. Apoyamos el lenguaje Perl y muchos otros proyectos de código abierto.

Los utilicé a propósito como terrenos de caza fértiles para reclutar a mi increíble equipo durante 2002–2005. Pero también había observado cómo los esfuerzos de código abierto a través de la colaboración con otros habían producido una tecnología sorprendente que superó los esfuerzos de propiedad en muchos campos. En muchos casos, la tecnología de código abierto se estaba convirtiendo en el estándar de facto e incluso en la mercancía en un campo. Parecía que el mismo acto de abastecimiento abierto, si se pudiera crear una comunidad lo suficientemente fuerte, conduciría a una maravilla mágica a convertirse en una mercancía o servicio básico. El código abierto pareció acelerar la competencia por cualquier actividad a la que se aplicara.

También había sido testigo de cómo existían las fuerzas contrarias, como el miedo, la incertidumbre y la duda. Los vendedores a menudo aplicaban esto a proyectos de código abierto para disuadir a otros al reforzar cualquier inercia que tuvieran que cambiar. Los proyectos de código abierto siempre fueron acusados ​​de no ser seguros, abiertos a los piratas informáticos (como si fuera una forma de insulto), de dudoso pedigrí y de ser un riesgo. Sin embargo, para nosotros, y para los millones de usuarios que consumieron nuestros servicios, fueron una pieza esencial del rompecabezas. Por casualidad, las diversas batallas en torno al código abierto aumentaron mi conciencia sobre la propiedad intelectual. Me hice muy consciente de cómo las patentes se usaban regularmente para la protección de anillos para evitar que un competidor desarrollara un producto. Esta fue la antítesis de la competencia y fue sofocante. Comencé a formar una opinión de que ciertas acciones acelerarían la competencia e impulsarían un componente hacia una mercancía, mientras que otras podrían usarse para frenar su evolución. El contexto podría ser manipulado.

Al mismo tiempo, había notado que a medida que ciertas actividades se industrializaban más y, por lo tanto, se generalizaban, a menudo se hacía difícil encontrar personas con las habilidades adecuadas o había escasez de componentes subyacentes. Por lo tanto, la evolución de un componente podría verse limitada por un componente del que dependiera, como el conocimiento. He resumido estos puntos en la figura 54 aplicándolos a nuestro primer mapa.

Figura 54. Aceleradores, desaceleradores y restricciones

Punto 1 : la evolución de un componente puede acelerarse mediante un enfoque abierto, ya sea de código abierto o de datos abiertos.

Punto 2 : la evolución de un componente puede ralentizarse mediante el uso del miedo, la incertidumbre y la duda al cruzar una barrera de inercia o mediante el uso de patentes para cercar una tecnología.

Punto 3 : la evolución de un componente puede verse afectada por restricciones en los componentes subyacentes, por ejemplo, la conversión de la computadora en una utilidad (o servicio básico) podría causar un aumento rápido de la demanda (debido a los nuevos componentes no graficados que se basan en él o la larga cola de necesidades comerciales no satisfechas) pero esto requiere construir centros de datos. Si bien la provisión de máquinas virtuales podría ser rápida, la construcción de centros de datos no lo es.

Comencé a explorar más el mapa, buscando otras formas en que podríamos explotar.

Juego específico de contexto: Innovación, apalancamiento y comercialización

Con frecuencia me han dicho que es mejor ser un seguidor rápido que un primer jugador. ¿Pero es eso cierto? Al usar el mapa este me contó una historia un poco más compleja. Ciertamente, al explorar un espacio inexplorado, había mucha incertidumbre y enormes costes de investigación y desarrollo. Ciertamente parecía mejor dejar que otros incurrieran en ese riesgo y luego de alguna manera adquirir esa capacidad. Pero los investigadores y las empresas estaban creando constantemente cosas nuevas, por lo que también había un coste de descubrir esa nueva cosa exitosa en todo el ruido. No seríamos la única compañía que intenta jugar ese juego y cualquier coste de adquisición reflejaría esto. Si queríamos jugar ese juego, entonces de alguna manera debemos ser capaces de identificar el éxito futuro de manera más efectiva que otros.

En comparación, al llevar un producto a una empresa de servicios básicos, el componente ya era bastante conocido. Se definió, había un mercado existente pero sí habría inercia. Me di cuenta de que había una conexión entre los dos y estábamos sentados ante la respuesta. Nuestra estructura de planificador urbano-pionero-colono – nos permitió hacer frente a la evolución y conectar los dos extremos. El papel de los colonos era simplemente identificar patrones exitosos futuros y aprender sobre ellos al refinar un producto o componente de biblioteca. En 2005, en realidad nos referimos a nuestros colonos como el equipo marco y su éxito vino de comprender los patrones dentro de lo que los pioneros, nuestro equipo de desarrollo , habían construido. Los pioneros fueron nuestros jugadores.

Sin embargo, ¿qué pasaría si nuestros pioneros no fuéramos nosotros mismos sino otras compañías? ¿Podrían nuestros colonos descubrir patrones exitosos en todo ese ruido? El problema, por supuesto, era ¿dónde miraríamos? Al igual que cualquier proveedor de productos, podríamos realizar una encuesta de marketing para descubrir cómo las personas usaban nuestros componentes, pero esto parecía lento y engorroso. Afortunadamente, nuestro servicio de fotografía online nos dio la respuesta.

Entre 2003 y 2005, expusimos partes del servicio de fotografía a través de solicitudes de URL y API a otros. No fue un gran salto darnos cuenta de que si monitoreábamos el consumo de nuestras API, podríamos usar esto para identificar en tiempo real qué otras compañías estaban teniendo éxito sin recurrir a encuestas de marketing lentas y costosas. Esto condujo al modelo innovación – apalancamiento – mercantilización (ILC: innovation – leverage – commoditise). Originalmente, llamé a esto innovación – transición – servicio básico y le debo un agradecimiento a Mark Thompson por persuadirme de cambiar la transición a algo más significativo. El modelo ILC se describe en la figura 55 y realizaremos su operación.

Figura 55. ILC (innovar, apalancar y mercantilizar)

Tome un producto existente que esté relativamente bien definido y sea un lugar común y conviértalo en una utilidad industrializada ( puntos A1 a A2 ). Esta utilidad debe exponerse como una API fácil de usar. Luego, aliente y permita a otras compañías innovar construyendo sobre su utilidad ( Punto B1 ). Puede hacer esto aumentando su agilidad y reduciendo su coste de falla, que proporcionará una utilidad. Estas empresas que se basan en su utilidad son sus pioneros «externos» o lo que comúnmente llamamos un «ecosistema».

Cuantas más empresas construyan sobre su utilidad (es decir, cuanto más grande sea su ecosistema), más cosas construirán sus pioneros «externos» y más amplio será el alcance de las nuevas innovaciones. Su ecosistema «exterior» es, de hecho, su motor de detección futura. Al monitorear metadatos como el consumo de sus servicios públicos, puede determinar qué se está convirtiendo en exitoso. Es importante tener en cuenta que no necesita examinar los datos de esas empresas «externas», sino solo los metadatos, por lo tanto, puede equilibrar las preocupaciones de seguridad con la detección futura. Debe usar estos metadatos para identificar nuevos patrones que sean adecuados para su provisión como componentes industrializados ( B1 a B2) Una vez que haya identificado un patrón futuro, debe industrializarlo a un servicio de componentes discretos ( B3 ) proporcionado como utilidad y expuesto a través de una API. Ahora está proporcionando múltiples componentes ( A2 , B3 ) en una plataforma cada vez mayor de servicios de componentes para que otros construyan sobre ( C1 ). Luego repites este círculo virtuoso.

Obviamente, las empresas en cualquier espacio que acabe de industrializar ( B2 a B3 ) pueden quejarse: «se han comido nuestro modelo de negocio» , por lo que tendrá que equilibrar cuidadosamente la adquisición con la implementación. Por el lado positivo, cuantos más servicios de componentes proporcione en su plataforma, más atractivo será para los demás. Tendrá que administrar este ecosistema como jardinero, alentando el crecimiento de nuevos cultivos (“compañías externas”) y teniendo cuidado de no cosechar demasiado. Tenga en cuenta que esto crea una plataforma en constante expansión en el sentido de una recopilación flexible de servicios de componentes discretos (por ejemplo, almacenamiento, cómputo, base de datos) que es distinta de una plataforma de ejecución de código (es decir, un marco en el que escribe código).

Hay una belleza sutil en el modelo ILC. Si consideramos que nuestro ecosistema son las empresas que se están sumando a nuestros servicios de componentes discretos, entonces el ecosistema más grande es: –

• Cuanto mayores son las economías de escala en nuestros componentes subyacentes.
• Cuantos más metadatos existan para identificar patrones futuros.
• Cuanto más amplio sea el alcance de los componentes innovadores construidos en la parte superior y, por lo tanto, más amplio será el entorno futuro que podemos escanear.

Esto se traduce en una apariencia cada vez mayor de ser altamente eficientes a medida que industrializamos componentes a formas de productos básicos con economías de escala, pero también muy centrados en el cliente debido al apalancamiento de metadatos para encontrar patrones que otros desean. Finalmente, otros vendrán a vernos como altamente innovadores a través de la innovación de otros. Todas estas cualidades deseables aumentarán con el tamaño del ecosistema siempre que extraigamos los metadatos y actuemos como un jardinero efectivo.

Ser constantemente el primero en industrializar un componente proporciona un gran beneficio al permitirnos ser efectivamente un seguidor rápido del éxito futuro y la generación de riqueza. Cuanto más grande es el ecosistema que construimos, más poderosos se vuelven los beneficios. Aquí hay un efecto de red y este modelo contrastaba con lo que me habían dicho: que debe ser un seguidor rápido y que puede ser altamente innovador, eficiente o centrado en el cliente. Al mirar el mapa, supe que con un poco de truco de mano podría generar la impresión de que estaba logrando los tres al ser el primero en industrializar y un rápido seguidor de lo desconocido. Normalmente represento esta forma particular de modelo de ecosistema (hay muchas formas diferentes) con un conjunto de círculos concéntricos.

Figura 56 – Vista circular de ILC

Uso de jugabilidad específica de contexto: el juego

Fue en este punto, con una jugabilidad específica del contexto de la mano cuando comencé a pasar por algunos escenarios con James, mi XO y mi científico principal en nuestra sala de juntas. Nuestro plan comenzó a fusionarse y fue mejorado por varios experimentos que la compañía había realizado. Uno de los cuales fue el jefe de mi equipo de frameworks para decirme que acababan de demostrar que podíamos desarrollar aplicaciones completas (front-end y back-end) en Javascript.

Al mismo tiempo que refinamos nuestro juego, alenté al grupo a desarrollar servicios de componentes bajo el apodo de «LibApi» como en API de liberación, es decir, nuestra libertad de las tareas repetidas sin fin y nuestro modelo de negocio existente. Decir que fui entusiasta por este experimento sería subestimar mi puro deleite. Este evento fortuito ayudó a cimentar el plan que se resume en la figura 57. Lo desglosaré y analizaré cada punto en detalle.

Figura 57. El plan

Punto 1 : el enfoque de la compañía sería proporcionar una plataforma de ejecución de código como un servicio de utilidad junto con una gama cada vez mayor de servicios de componentes industrializados para tareas comunes como facturación, mensajería, un almacén de objetos (una API de almacén de objetos clave, correo electrónico…). Todos los componentes estarían expuestos a través de API públicas y el servicio proporcionaría la capacidad de desarrollar aplicaciones completas en un solo idioma: JavaScript. La elección de JavaScript se debió a su uso común, la seguridad del motor JS y la eliminación de errores de traducción con el código de front-end y back-end construidos en el mismo idioma. Todo el entorno se cobraría en función de las operaciones de JavaScript, el uso de la red y el almacenamiento. No habría concepto de una máquina física o virtual.

Punto 2 : para acelerar el desarrollo de la plataforma, todo el servicio sería de código abierto. Esto también permitiría a otras compañías establecer servicios competitivos, pero esto fue planeado y deseable.

Punto 3 : el objetivo no era crear un servicio Zimki (el nombre dado a nuestra plataforma) sino un mercado competitivo de proveedores. Nuestro objetivo era obtener un pedazo pequeño pero lucrativo de un pastel muy grande al sembrar el mercado con nuestro propio servicio básico y luego abrir la fuente de tecnología. Para evitar que las empresas crearan diferentes versiones de productos, todo el sistema debía abrirse bajo una licencia que permitiera la competencia a nivel operativo pero minimizara la diferenciación de características de un conjunto de productos: GPL parecía cumplir con los requisitos.

Todavía teníamos el problema de que los proveedores de servicios podían diferenciar y socavar el mercado. Sin embargo, también teníamos una solución ya que nuestro proceso de desarrollo utilizaba un desarrollo basado en pruebas y toda la plataforma estaba expuesta a través de API. En el proceso de desarrollo, creamos un extenso conjunto de pruebas. Este conjunto de pruebas se usaría para distinguir entre los proveedores de plataformas comunitarias (aquellos que tomaron el código pero lo modificaron de manera significativa) y los proveedores certificados de Zimki (aquellos que cumplieron con el conjunto de pruebas). Mediante el uso de una imagen de marca registrada para los proveedores de Zimki, podríamos imponer cierto nivel de portabilidad entre los proveedores.

Al crear este mercado, respaldado por una Fundación Open Zimki, podríamos superar una fuente de inercia (depender de un solo proveedor) mientras permitimos que las empresas prueben primero su propia plataforma internamente y desarrollen nuevas oportunidades para nosotros desde una tienda de aplicaciones, mercado de informes, servicios de conmutación, capacidad de corretaje, capacitación, soporte y clústeres Zimki independientes y preconstruidos. Tal enfoque también reduciría nuestra exposición al capital dadas las limitaciones bajo las cuales existíamos.

Punto 4 : necesitábamos construir un ecosistema que nos permitiera identificar los servicios futuros que deberíamos crear y, por lo tanto, tuvimos que construir un modelo ILC. Obviamente, solo pudimos observar directamente los datos de consumo de aquellos que desarrollaron nuestro servicio, pero ¿qué pasa con otros proveedores de Zimki?

Al proporcionar servicios comunes como GUBE (motor genérico de facturación de servicios básicos) junto con una tienda de aplicaciones, una biblioteca de componentes (un equivalente de CPAN) y, en última instancia, alguna forma de capacidad de corretaje, teníamos la intención de crear múltiples fuentes de metadatos. Discutimos mucho sobre si podíamos hacerlo solos, pero sentí que no teníamos la marca. Necesitábamos crear ese mercado y el potencial era enorme. Había estimado que todo el mercado de la informática de servicios básicos (es decir, la computación en la nube) valdría $ 200 mil millones una década más tarde en 2016 y tomaríamos una pequeña parte.

Nuestro premio a más largo plazo era ser el facilitador del mercado y, en última instancia, crear algún tipo de intercambio financiero. Necesitaríamos ayuda externa para que esto sucediera, dadas nuestras limitaciones, pero decidimos no promover ese mensaje ya que era «demasiado lejos en el futuro, demasiado loco» para la mayoría.

Punto 5 : necesitábamos que fuera fácil, rápido y económico para las personas crear aplicaciones completas en nuestra plataforma. Tuvimos que cortar despiadadamente todo el afeitado de yak (tareas inútiles, desagradables y repetidas) que estaban involucradas en el desarrollo. Cuando uno del equipo de desarrollo construyó una forma completamente nueva de wiki con vista previa del lado del cliente y pasó de la idea al lanzamiento en vivo en la web en menos de una hora, supe que teníamos algo con potencial. Los yaks pre afeitados se convirtieron en la frase clave para describir el servicio y algo que pusimos en nuestras camisetas en 2005 y 2006.

Punto 6 : anticipamos que alguien proporcionaría un servicio de infraestructura de servicios básicos. Necesitábamos explotar esto construyendo sobre ellos. Nos habíamos vuelto bastante capaces a la hora de construir servicios basados ​​en valor (es decir, aquellos que cobramos por un porcentaje del valor que crearon) a lo largo de los años y sabía que podíamos equilibrar nuestra carga de la plataforma con cualquier coste operativo variable causado por un proveedor de infraestructura de servicios públicos .

Al construir sobre cualquier servicio de infraestructura de servicios públicos, también tendríamos la ventaja de aislar a ese proveedor de cualquier metadato que no sea nuestra plataforma. Si jugué el juego lo suficientemente bien, entonces tal vez eso sería una jugada de salida para nosotros a través de la adquisición. Si realmente teníamos éxito, tendría que romper el ancla de la empresa matriz en algún momento en el futuro.

Punto 7 : sabíamos que construir centros de datos sería una restricción en la infraestructura de servicios públicos y que la demanda de computadoras era elástica. Esto dio opciones para el juego contrario, como la creación de una guerra de precios para forzar la demanda más allá de la capacidad que un proveedor podía proporcionar. Pero para enfrentar a un proveedor contra otro, necesitábamos ofrecer a los competidores una ruta hacia el mercado. Afortunadamente, teníamos nuestro sistema Borg y, aunque habíamos hablado con un gran proveedor de hardware conocido (que se había resistido a la idea de la computadora como utilidad), pudimos abrir el código fuente ( punto 8), siendo este el espacio para alentar la formación de ese mercado. Tenía contrajuegos que podía usar si los necesitábamos y era una ventaja para nosotros si existía un mercado fragmentado de proveedores de infraestructura de servicios básicos. Deberíamos apuntar a que ninguna compañía obtenga el control total de este espacio.

La opción se veía bien según nuestras capacidades. Estaba dentro del ámbito de las posibilidades y éramos conscientes de las limitaciones que teníamos. Esto parecía proporcionar el mejor camino a seguir. Significaría reenfocar la empresa, eliminar servicios como nuestro sitio de fotos online y poner otros servicios de ingresos en alguna forma de estado mínimo hasta que el negocio de la plataforma creciera lo suficiente como para poder disponer de ellos. Estaba listo para apretar el gatillo, pero había una última cosa que necesitaba.

Impactos a propósito

La decisión de actuar puede afectar el propósito mismo de su empresa: el ciclo de la estrategia no solo es iterativo, es un ciclo. En este caso, nuestro propósito era pasar de un «grupo de soluciones creativas», una yuxtaposición de palabras sin sentido a un «proveedor de plataformas de servicios» . Solo decir que ese propósito no fue suficiente, nunca lo es. Si quería ganar esta batalla, necesitaba reunir a todos y hacer que el propósito fuera significativo. Tenía que crear un imperativo moral, una razón para hacerlo, una visión del futuro, un grito de guerra, una bandera que pudiéramos agitar y nuestra propia cruzada.

Para nosotros, esto se encarnó en las palabras «yaks pre afeitados» . Pretendíamos librar al mundo de las tareas interminables que se interponían en el camino de la codificación. Construiríamos ese mundo donde simplemente encendiste tu computadora, abriste un navegador y comenzaste a codificar. Todo, desde preocuparse por la planificación de la capacidad, la configuración de paquetes hasta la instalación de máquinas, podría desaparer. Cada función que escribiste podría estar expuesta como un servicio web. Las bibliotecas de rutinas escritas por otros podrían agregarse fácilmente a través de un común compartido y usted podría escribir la aplicación completa en horas, no días, semanas o meses. Este fue nuestro propósito. Fue mi proposito. Y encajó bien.

¿Qué pasó después?

Lo construimos.

Reorienté la empresa, cortamos lo que no importaba y desarrollamos nuestra plataforma. Para el 18 de febrero de 2006 teníamos la plataforma, los servicios básicos de API, el sistema de facturación, el portal y tres aplicaciones básicas para que otros las copiaran. Lanzamos beta oficialmente en marzo de 2006 (nuestro alfa había sido muchos meses antes), esto fue dos años completos antes de que Google apareciera en la escena con AppEngine. El lanzamiento público se realizó en dConstruct en septiembre de 2006.

Para el 18 de abril de 2006, teníamos 30 clientes, 7 aplicaciones básicas y una tarifa mensual de 600,000 llamadas en la API. Para el 19 de junio de 2006, estábamos registrando una tasa de ejecución de 2.8 millones de llamadas API. Estábamos creciendo a un ritmo fenomenal y para el primer trimestre de 2007 habíamos superado la marca de 1.000 desarrolladores, es decir, otros sistemas de construcción para sus propios usuarios. Después de un comienzo lento, nuestro crecimiento ahora excedía incluso mis pronósticos optimistas dadas las enormes barreras educativas que esperábamos – ver figura 58.

Figura 58. Crecimiento en usuarios de Zimki (desarrolladores)

Pero durante ese tiempo también sucedió algo excepcional. El 25 de agosto de 2006, no fue Google sino Amazon el que se lanzó con EC2. Yo estaba entusiasmado de nuevo. Amazon era un gran jugador, habían brindado credibilidad instantánea a la idea de la informática de servicios públicos y, en respuesta, decidimos inmediatamente mover nuestra plataforma a EC2. Cada vez que nos presentamos en eventos, nuestros stands tendían a estar inundados de interés con multitudes de personas a menudo de cuatro, cinco o seis capas de profundidad. La compañía había adoptado la nueva dirección (todavía había algunos rezagados) y había mucha expectatica. Todavía éramos muy pequeños y teníamos que escalar una montaña enorme, pero habíamos dado nuestros primeros pasos, anunciado el abastecimiento abierto, aseguramos una facturación superior en OSCON en 2007 y las bombas estaban preparadas. Pero Houston, tuvimos un problema.

¿Qué salió mal?

El problema fui yo. Había subestimado masivamente las intenciones de la empresa matriz. Debería haberlo sabido mejor dado que había pasado más de tres años (2002-2005) tratando de persuadir a la empresa matriz de que la impresión 3D tendría un gran futuro o mis intentos más recientes de que los teléfonos móviles dominarían el mercado de las cámaras. La empresa matriz se preocupó por los televisores SED (surface-conduction electron-emitter display) y se centró en su mercado principal (cámaras e impresoras). A pesar del potencial que vi, nos estábamos volviendo menos importantes para ellos y ya habían comenzado a eliminar inversión en I + D volcándolo hacia un enfoque para obtener más eficiencia. Habían traído una consultora externa para analizar nuestra plataforma y concluyeron que la informática de servicios públicos no era el futuro y el potencial para la computación en la nube (como se supo) no era realista. Recuerde, esto fue 2006. Amazon apenas se había lanzado. Incluso en 2009.

El futuro de la empresa matriz implicaba externalizar nuestras líneas de negocios a un integrador de sistemas (SI) y, como me dijeron, «toda la visión de Zimki estaba mucho más allá de su alcance» .

Tuve varios problemas aquí. Primero, no invertirían en nuestro servicio porque aparentemente se había tomado una decisión más alta dentro de la empresa matriz sobre lo que era central. Lo que les preocupaba era el movimiento suave de nuestras líneas de negocios a la IS. Eso apoyó sus objetivos centrales y sus necesidades. Cuando planteé la idea de la inversión externa, el problema se convirtió en que no podían mantener una participación en algo que, según ellos, no era esencial.

Cuando planteé la idea de una compra por parte de la gerencia, siempre irían a lo que describieron como una cifra de mercado «poco realista» de $200 mil millones para 2016. Seguramente, estaría dispuesto a pagar una suma considerable basada en este mercado futuro como ¿Es un hecho para una startup incipiente en un mercado incipiente? Ninguna empresa de capital de riesgo tomaría una apuesta unilateral tan escandalosa. En cualquier caso, me dijeron que la conversación siempre se podía dejar hasta después de que los servicios básicos de ingresos se transfirieran al SI. Esto fue simplemente una abreviatura de «vete».

La gota que colmó el vaso ocurrió cuando uno de los miembros de la junta me dijo que los miembros habían decidido posponer el abastecimiento abierto de nuestra plataforma y que querían que firmara inmediatamente contratos que cancelen nuestros servicios de generación de ingresos en una fecha no especificada para completarla luego. Como la persona que normalmente presidía la reunión de la junta, me molestaba ir a ciegas, la elección y yo mismo. De alguna manera, en mi afán por crear un futuro centrado en las necesidades de los usuarios y una dirección significativa, me había olvidado de obtener el capital político que necesitaba para lograrlo. Podría haber creado un fuerte propósito y haber construido una empresa capaz de lograrlo, pero me había equivocado mucho con la junta. No fue su culpa; se estaban centrando en lo que era esencial para la empresa matriz y sus necesidades.

Todos los miembros eran altos ejecutivos de la empresa matriz y debería haber sido obvio que estaban obligados a tomar esta posición. Me di cuenta de que nunca los había involucrado realmente en nuestro viaje y me había preocupado por construir un futuro para los demás. Ni siquiera les había explicado completamente nuestros mapas basándose en historias, pero esto se debía a que todavía no me había dado cuenta de lo útiles que eran realmente los mapas. En mi opinión, los mapas no eran más que mi forma de explicar la estrategia porque todavía no había encontrado ese libro mágico que todos los demás ejecutivos aprendieron en la escuela de negocios. Este era un poderoso grupo de usuarios, mi junta y la empresa matriz, que tenía necesidades que no había considerado. Fue un error de novato. Finalmente había sido redoblado como ese CEO impostor.

No hubo vuelta atrás, se mantuvieron firmes en su posición y tenían todo el poder para hacerla cumplir. Estaba a punto de subir al escenario en OSCON (conferencia de código abierto O’Reilly) en 2007 y, en lugar de mi mensaje cuidadosamente elaborado, tuve que anunciar de alguna manera el abastecimiento no abierto de nuestra plataforma y la no creación de una futura utilidad competitiva mercado. Se esperaba que rompiera una promesa que había hecho a nuestros clientes y estaba bastante claro que posponer era una forma pintoresca de decir «nunca» . No podía estar de acuerdo con la dirección que habían elegido y estábamos en desacuerdo. Mi posición era insostenible y renuncié.

Los servicios de la compañía se colocaron rápidamente en el camino de ser subcontratados a la IS y los empleados pasaron por un programa de despido que comenzó unos días después de que yo renuncié. La plataforma se disolvió y cerró a finales de año. Sin embargo, los conceptos no se perdieron, ya que algunos de estos tipos de ideas se abrieron paso a través de James Duncan en ReasonablySmart (adquirido por Joyent) y otro buen amigo mío, James Watters, en Cloud Foundry. Observo que Pivotal y su plataforma de juego ahora está valorada en más de $ 2.5 mil millones y sin servidor es un concepto de rápido crecimiento en 2016. ¿En cuanto a televisores SED? Bueno, algunas veces ganas, y otras pierdes.

En cuanto a la consultoría, cualquier frustración que pueda tener está mal dirigida porque fui yo quien falló aquí. Mi trabajo era dirigir la empresa y eso no solo significaba aquellos que trabajaban para mí, sino para la junta.

En estos primeros capítulos, espero haberte enseñado cómo entender el contexto en el que estás compitiendo, anticipar el futuro, aprender a aplicar la doctrina, desarrollar un juego específico para el contexto, construir el futuro y finalmente explotar ignorando a un conjunto de usuarios . ¿Zimki se habría dado cuenta de su potencial y se convertiría en un gran éxito? Nunca lo sabremos pero tuvo una oportunidad. Esta fue mi primera carrera en el ciclo de la estrategia y al menos sentí que tenía una vaga idea de lo que estaba haciendo en lugar de que esa ingenua juventud de «me parece bien» . Todavía estaba lejos de la posición exaltada de ese ejecutivo confiado que había conocido y estaba decidido a mejorar la próxima vez. Afortunadamente para mí, hubo una próxima vez, pero esa es otra parte de la historia.

Categorización del juego

La jugabilidad es específica del contexto. Debe comprender el paisaje antes de usarlo. El propósito de la jugabilidad es que una vez que se determinan los posibles «lugares» a los que podría atacar (lo que requiere que comprenda el contexto y se anticipe al cambio de los patrones económicos comunes), se analizan las acciones que puede tomar para crear la situación más ventajosa. A medida que avancemos en este libro, cubriremos todo tipo de jugabilidad y refinaremos los conceptos discutidos anteriormente. Para darle una idea de lo que necesitamos cubrir, he puesto algunas formas básicas en la figura 59, marcando en naranja algunas que ya hemos mencionado.

Figura 59. Jugadas o formas de juego

He categorizado las formas de juego anteriores según su impacto principal:

• Alteración de la percepción del usuario
• Aceleradores de evolución
• De-aceleradores a la evolución
• Medios de hacer frente a la toxicidad (es decir, herencia)
• Jugadas del Mercado 
• Jugadas defensivas
• Jugadas de ataque
• Modelos de Ecosistema
• Jugadas posicionales
• Mecanismos venenosos

Tengo que reiterar que cada vez que he dado la vuelta al ciclo, he mejorado en el juego. A medida que avanzamos por el mismo camino, iré agregando más patrones económicos, más doctrina y una forma de jugar más específica del contexto, junto con una inmersión profunda en algunas de las partes que he pasado por alto o que fueron simplemente conceptos generales en esos primeros días. Pero como con todos los viajes, sigamos el camino ya que no hay atajos. Cada paso es valioso; Cada contexto es una oportunidad para aprender.