Header Ads Widget

Ticker

6/recent/ticker-posts

Las grandes API son como ladrillos de Lego


 Hemos escrito mucho sobre diferentes modelos de monetización de API monetización de su API utilizando un modelo freemium en el pasado, pero es igualmente importante imaginar cómo su API podría encajar en su modelo de negocio en su conjunto.

Obviamente, esto es algo que diferirá enormemente de una empresa a otra; en el caso de una empresa como Twilio, la API es el producto principal. En la mayoría de las empresas, sin embargo, es probable que una API se considere una oferta secundaria , es decir, un producto auxiliar que existe en los márgenes de la empresa. Las API a menudo se consideran algo solo para los técnicos que no tienen mucho que desempeñar en el contexto más amplio del negocio.

Es esta visión la que Matthias Biehl , consultor de API en API University , cree que está totalmente desactualizada. Un enfoque que priorice las API puede ser un impulsor comercial clave, con un enorme potencial financiero, pero solo si está diseñado para satisfacer las necesidades de los desarrolladores que lo usarán.

Esta publicación sigue a la presentación de Matthias Biehl de la Cumbre de la Plataforma Nórdica de APIs 2016. Míralo aquí:

Vea las diapositivas aquí .

¿Qué tienen en común las API y los ladrillos Lego?

La mayoría de nosotros tenemos buenos recuerdos de jugar con Lego cuando éramos niños. El verdadero atractivo de Lego es que, aunque la mayoría de los juegos venían en cajas con imágenes en el frente, realmente no importaba si lo que construiste terminara luciendo igual que esa imagen.

Para citar un artículo anterior presentado en este blog, “Muchas charlas sobre API comienzan explicando que las API son como estos ladrillos [Lego]. Se pueden combinar de formas innovadoras y creativas más allá de su propósito original ".

Cuanto más mires, más similitudes entre Lego y las API encontrarás:

  • Estandarizado : componentes universales estandarizados que funcionan como bloques de construcción;
  • Utilizable : fuerte énfasis en la usabilidad, con documentación / instrucciones;
  • Personalizable : opciones para usar diferentes ladrillos / API para diferentes funcionalidades;
  • Innovador : capacidad para mezclar y combinar diferentes conjuntos de construcción / API para crear resultados híbridos.

"Lego y las API tienen una interfaz súper simple y, debido a esta interfaz fácil, es muy intuitivo y muy simple construir cosas rápidamente".

Con Lego, el cielo es el límite, y lo mismo ocurre cuando se considera el potencial creativo infinito que pueden ofrecer las API. Si bien los legos y las API pueden venir con una imagen en la caja o documentación que describe sus usos recomendados, algunos de los resultados más interesantes pueden no parecerse en nada a lo que espera el proveedor de API .

Pensemos más en esa declaración, porque tiene algunas implicaciones bastante importantes. Sugiere que, en los muchos casos en los que los consumidores de API crean servicios que los creadores de API no esperan, existe una desconexión entre lo que quieren los consumidores de API y lo que los proveedores de API creen que quieren. De hecho, hemos escrito anteriormente sobre algunos usos inesperados de las API en el contexto de IoT.

Una de las cosas que más nos gustan de las API aquí en las API nórdicas es el potencial que ofrecen para conectar productos / servicios que de otro modo no podrían comunicarse entre sí. En este sentido, las API en realidad tienen incluso más potencial que los ladrillos de Lego: sabrá que si alguna vez ha intentado usar este último junto con Duplo o Playmobil ...

API y la cadena de valor

Matthias sugiere que la forma más fácil de ganar dinero con una API es observar dónde encaja, o podría encajar, en la cadena de valor , es decir, ¿dónde tiene la API en cuestión un impacto en el contexto más amplio del negocio ?

Como dice Matthias, "la historia no termina con los consumidores de API". Con toda probabilidad, el objetivo de los consumidores de API es crear una aplicación o servicio, uno que pueda empaquetar varias API, y ofrecerlo a los usuarios finales .

Proporciona el ejemplo de Uber que, como hemos cubierto en una publicación anterior, se basa en múltiples API para sobrevivir:

  • Mapas / GPS - Google Maps
  • Notificaciones VOIP y SMS - Twilio
  • Procesamiento de pagos - Braintree
  • Identificación: API de Microsoft Face

Entonces, vemos que los propietarios de API no solo deben pensar en lo que hará su API, sino en cuáles podrían ser algunos de sus posibles casos de uso . Solo entonces podrán determinar cómo la API puede facilitar las cosas y aliviar el estrés no solo para los consumidores de API, en este caso los desarrolladores de aplicaciones, sino también para los usuarios finales que utilizarán estas aplicaciones.

Lea también: 4 ajustes de diseño para mejorar las operaciones de la API

API y Design Thinking

Matthias plantea dos preguntas frecuentes con las que los desarrolladores de API lo golpean todo el tiempo.

  1. ¿Cómo puedo ganar dinero con mi API?
  2. ¿Cómo puedo hacer que mi API sea fácil de usar ?

También plantea un tercio que nunca consigue.

  1. ¿Estoy creando una API que los desarrolladores necesitan?

De inmediato, podemos ver que 2 y 3 son las preguntas clave que deben responderse antes de poder abordar 1. A menos que una API tenga un propósito real y sea fácil de usar , es muy poco probable que nadie más que los fanáticos más apasionados de su producto quiera usarla, y mucho menos pagar por ella.

Para identificar las funciones de API que las personas realmente necesitan, Matthias sugiere el siguiente ciclo:

Un ciclo de vida empresarial de API, según lo definido por Matthias

El proceso puede ser lento y arduo, sin mencionar menos emocionante que hackear una API en una noche llena de cafeína. Pero probablemente no sea una coincidencia que muchos productos fabricados de esta última forma no encuentren tracción. De hecho, como dice un artículo de The Atlantic, "Nunca se crea nada útil en un hackathon".

Eso puede ser una exageración (muchas funciones populares de Facebook nacieron en hackatones internos) y, aunque adoptar un enfoque de "pensamiento de diseño" no garantiza el éxito, es mucho más probable que ayude a salvar esa desconexión entre los desarrolladores de API y los consumidores que seguir adelante. con desarrollo sin ningún aporte de usuarios potenciales.

Relacionado:  6 pasos para convertir una API en una plataforma lucrativa

API y el lienzo del modelo de negocio

Esquema de modelo de negocios

Haga clic para expandir / descargar el lienzo del modelo de negocio

Una vez que se han identificado las necesidades de los consumidores de API, es mucho más fácil ver dónde encaja una API en un modelo de negocio. Matthias sugiere usar Business Model Canvas (BMC) para hacer esto en términos visuales y fácilmente iterativos.

Si no está familiarizado con el BMC , es una metodología que a menudo se asocia con startups ajustadas que implica trazar su modelo de negocio en sus términos más básicos utilizando una plantilla estandarizada.

Utiliza el formato para proporcionar un ejemplo de cómo una empresa de telecomunicaciones podría cambiar su enfoque clave para proporcionar API:

 

Tomado de las diapositivas de Matthias Biehl

Incluso si una API es solo una pequeña parte de su negocio, puede ser útil ver cómo encaja dentro de la estructura de su negocio. Eso incluso podría significar usar Business Model Canvas para trazar cómo se vería su negocio si decidiera hacer de su API su producto principal mañana. ¡Ahora hay un pensamiento que es emocionante y aterrador a partes iguales!

También vale la pena señalar, como lo hace Matthias, que la cadena de valor asociada con cualquier API se construye efectivamente a partir de dos modelos comerciales diferentes: el modelo comercial de un proveedor de API y un consumidor de API. Estos dos modelos están mucho más estrechamente vinculados de lo que muchas personas creen; identificar dónde una API agrega valor en el modelo comercial de un consumidor permite a los proveedores determinar dónde / cómo / si cobrar por ciertas funcionalidades.

Consulte también:  7 lecciones aprendidas sobre la creación de un inicio de API

Pensamientos finales

Un gran problema con el enfoque actual de las API, y en particular cómo se relacionan con los modelos comerciales, es que muchas empresas crean sus API junto con sus productos antes de pensar en cómo pueden encajar en su modelo comercial.

Como todo empresario sabe, iniciar un proyecto sin realizar la investigación de mercado adecuada o planificar cómo encajará con el modelo general del negocio nunca es una decisión inteligente.

Las grandes preguntas en las que debe centrarse al planificar una nueva API son las siguientes:

  • ¿Estoy creando una API que los desarrolladores necesitan?
  • ¿Cómo puedo crear una API que haga que abordar esas necesidades sea lo más fácil posible?

Si ya tiene una API, puede que sea demasiado tarde para hacer esas preguntas. Aunque ciertamente no hay nada que le impida, como lo ha hecho WorkflowMax , invitar a los usuarios a recibir comentarios a través de su documentación o centro de desarrollo.

Nunca es demasiado tarde para ver cómo los clientes usan su API y si puede comenzar a cobrar por algunos de sus elementos. O, si le preocupa la reacción que podría generar, incorpore servicios adicionales que estén relacionados con los aspectos más populares de lo que ofrece actualmente, pero que van más allá.

Las grandes API son como los ladrillos de Lego: fáciles de usar y la gente quiere jugar con ellas. Si está creando una nueva API o reiterando una API existente, es posible que desee pensar en mantener un bloque de Lego en su escritorio durante todo el proceso. Ya sabes, solo como un recordatorio de lo que debes aspirar.

Publicar un comentario

0 Comentarios