Raro es el fabricante de software que actualmente no incorpora una estrategia de APIs o proporciona parte de su oferta bajo esa modalidad. Pero este tipo de producto -que no es sólo “algo para desarrolladores”- posee algunas características muy particulares a la hora de llevarlo al mercado.

Cada vez más productos digitales toman la forma de APIs, de modo que puedan ser incorporados y comercializados como componentes de soluciones de terceros. Ya se trate de una tecnología de AI o una solución de BaaS (Banking as a Service), cada vez más productos se exponen como APIs para que otras empresas (clientes finales, integradores, proveedores de producto) proporcionen servicios basados en ellas a sus clientes internos o externos.

Como explicábamos aquí, una API es la tecnología software que permite embeber o integrar un programa como parte de otro, de manera que este segundo utilice los servicios del primero sin necesidad de realizar todo el desarrollo del código. Este proceso de integración es un trabajo técnico realizado por desarrolladores de software.

Un modelo de negocio basado en productos API es sustancialmente diferente de uno basado en aplicaciones finales. Y no sólo por la propuesta de valor sino por el tipo de clientes a los que se dirige, los canales, las relaciones con dichos clientes o las corrientes de ingresos. Pero las APIs ofrecen enormes posibilidades para fomentar la innovación abierta y poder acceder indirectamente a mercados que de otro modo nos estarían vedados por falta de experiencia, recursos, credibilidad, etc.

En este post vamos a analizar algunas peculiaridades del go-to-market de productos API y diferencias con el caso de aplicaciones finales y herramientas software.

Las APIs no son “sólo para desarrolladores”

Una concepción simplista de este tipo de producto es que las APIs “son para desarrolladores” y únicamente ellos son relevantes desde el punto de vista de desarrollo y comercialización. Y, ciertamente, los desarrolladores son los usuarios directos de las APIs y por lo tanto debemos diseñar y comercializar para ellos.

Pero, al igual que ocurre con las aplicaciones finales, en mercados B2B los usuarios no son los únicos importantes (a pesar de que en los últimos tiempos, con el predominio del SaaS, su peso en las decisiones de compra ha aumentado). En realidad, en el caso de una aplicación B2B podemos distinguir dos grandes grupos de personas involucradas:

• Usuarios directos de la aplicación: utilizan el producto para ejecutar sus tareas y pueden tener autonomía para comprarlo. El foco en un usuario que es -además- comprador, es lo que dio carta de naturaleza al enfoque de Product-Led Growth (PLG) para el crecimiento.
• Compradores de la aplicación: dependiendo del producto y mercado puede haber compradores (no necesariamente usuarios del producto) que deciden sobre la compra de éste. Los compradores se deciden por un producto porque les permite alcanzar una serie de resultados de negocio. En estos casos el movimiento de crecimiento suele estar basado en Ventas Enterprise, que en muchas ocasiones complementa al crecimiento impulsado por el producto.

(Adicionalmente pueden existir personas que sean a la vez compradores y usuarios).

En el caso de productos tipo API para B2B la cosa se complica porque hay tres tipos de personas involucradas:

• Desarrolladores (usuarios directos de la API): son los que usan las APIs como componente para desarrollar su producto software (para sus clientes externos) en un uso tipo OEM o sus aplicaciones corporativas (para sus clientes internos). Las APIs les evitan tener que desarrollar esa funcionalidad por su cuenta, con los costes y riesgos que eso apareja.
• Compradores: son decisores (no usuarios) que requieren una cierta funcionalidad en su producto o aplicación para alcanzar unos objetivos de negocio y eligen entre alternativas de build/buy/partner y dentro de esta última alternativa el producto API a utilizar para dotarse de ella.
• Usuarios finales (usuarios indirectos de la API): son los usuarios del producto software o la aplicación corporativa donde se ha embebido la API, y que utilizan la funcionalidad de ésta que es expuesta por dicho producto o aplicación.

Por ello, un producto API no debe proporcionar una propuesta de valor única enfocada en los desarrolladores sino varias propuestas de valor diferentes, para cada grupo de personas.

Por ejemplo, consideremos un producto API de tipo BaaS (Banking as a Service). Éste es un producto que proporciona a empresas de diversos sectores la posibilidad de crear y gestionar servicios financieros (por ejemplo, cuentas bancarias, tarjetas de débito y crédito, préstamos) para proporcionarlos a su vez a sus clientes finales. Rigurosamente hablando, una API BaaS no sólo proporciona acceso a un software sino a un sistema de negocio que incluye funcionalidad de software de core bancario, licencias y cumplimiento normativo e interconexión con los rails de pagos necesarios.

Supongamos que queremos dirigir ese producto API a grandes empresas del sector retail, para que proporcionen servicios financieros como parte de la experiencia de sus clientes. Las diferentes personas y sus respectivas propuestas de valor son:

• Usuarios finales: para los clientes del retailer la API BaaS debe proporcionar servicios financieros que hagan más sencilla su experiencia con dicho proveedor, por ejemplo, cuentas bancarias multiuso, tarjetas de pago con descuentos y recompensas, crédito inmediato, BNPL (Buy Now, Pay Later), etc.
• Compradores: para los directivos de la empresa de retail, el producto BaaS debe proporcionar componentes financieros que les ayuden a obtener nuevas corrientes de ingresos por los nuevos servicios, fomentar una involucración continua de los clientes con su empresa para mejorar la retención y la fidelidad y optimizar sus flujos y operaciones financieros. Por eso, además de los servicios financieros requeridos por los clientes finales la API BaaS debe aportar funciones de despliegue rápido, gestión y monetización de dichos servicios.
• Desarrolladores: para los desarrolladores software de la empresa de retail, el producto BaaS debe proporcionar unas interfaces estándar que ofrezcan compatibilidad tecnológica con sus aplicaciones y las experiencias que éstas proporcionan a sus clientes, documentación completa, herramientas de prueba… en definitiva, todo lo que contribuya a un fácil desarrollo sobre esas APIs.

Como vemos, las propuestas de valor para los tres grupos son sustancialmente diferentes pero el producto BaaS no triunfará si no satisface simultáneamente a los tres. Por eso considerar a las APIs como un producto “únicamente para desarrolladores” produce una miopía estratégica muy peligrosa.

En el próximo post analizaremos cómo usar las diferentes palancas de crecimiento para nuestro producto de API.

El post “Llevando al mercado nuestro producto de API (1)” se publicó primero en “Marketing & Innovación”.

[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Marketing estratégico para empresas tecnológicas y Product Marketing de productos tecnológicos te pueden ayudar.]

Las APIs son la nueva estrategia y plataforma de marketing para muchas nuevas tecnologías que se pueden empaquetar como software. La posibilidad de que sean otros partners los que desarrollen y vendan soluciones finales basadas en nuestra tecnología, en un modelo escalable y de aparente baja inversión y riesgo, abre enormes posibilidades comerciales. Tanto es así que algunos lo han bautizado como Desarrollo de Negocio 2.0.

En un post anterior hablamos de cómo publicar las APIs (Interfaces de Programación de Aplicaciones) abre un nuevo modelo de negocio a muchas empresas que ofrecen software en áreas tan diversas como la inteligencia artificial, el tratamiento estadístico, la información cartográfica o las conexiones sociales. Publicar APIs no solo es negocio para los grandes de la Web 2.0. Muchas empresas innovadoras se pueden beneficiar de este modelo para comercializar datos o lógica de aplicación (aunque, por supuesto, la estrategia a emplear dependerá mucho de cuál sea esa “materia prima”).

Por dar un ejemplo, pensemos en una empresa que desea comercializar una nueva tecnología software de Inteligencia Artificial (IA) en principio aplicable en diversos campos, sectores y clientes (un caso que ya utilizamos en un post sobre segmentación). Nuestra empresa debería tener en cuenta estas consideraciones:

• Posiblemente nuestra empresa ya estaba vendiendo productos completos basados en su tecnología en uno o varios mercados finales (siguiendo una estrategia de segmentación o la toma de una “cabeza de playa” para “cruzar el abismo”). Por ejemplo, puede haberse enfocado en el mercado de asistentes virtuales para telcos. La pregunta ahora es si una estrategia basada en APIs no “canibalizaría” ese negocio, permitiendo que otros agentes entraran en él. Y la respuesta en general es que efectivamente ese riesgo existe (aunque se puede minimizar) pero siempre es mejor canibalizarnos nosotros y no que nos canibalicen otros.
• Ciertamente, aunque nuestra empresa lleve tiempo enfocándose -e invirtiendo- en un mercado específico, con sus necesidades, clientes y soluciones concretos, podemos abrir nuestras APIs para fomentar que otros partners aborden nuevos mercados no relacionados: no son estrategias necesariamente incompatibles. Ello nos permite beneficiarnos de acceder a nuevos clientes, sectores, geografías, aplicaciones, etc. que de otro modo nos resultarían inaccesibles. Nuestra empresa de IA puede entrar, por ejemplo, en áreas de aplicación relacionadas con la planificación y la percepción automáticas. Incluso, como veremos, un negocio basado en el foco y la comercialización directa puede ser un complemento que contribuya al éxito de otro modelo basado en APIs más generales.
• Esta nueva cadena de valor con partners desarrolladores y comercializadores nos evita tener que entrar en mercados donde no tenemos encaje, competencias ni recursos adecuados, nos evita distracciones y nos permite concentrarnos en nuestro negocio y tecnologías core.
• El modelo impulsa la innovación abierta y el desarrollo de relaciones con partners: ¿quién puede desarrollar y comercializar las mejores soluciones para nuevos clientes, sino los fabricantes / integradores que están en un contacto cercano –geográfico, sectorial– con  ellos? Además esta colaboración fomenta la aparición de aplicaciones de nuestra tecnología para la long tail de clientes y escenarios infrecuentes e inesperados.
• Resulta imprescindible aprovechar y gestionar las dinámicas propias de los productos plataforma y los ecosistemas de productos complementarios, fomentar los efectos de red y la estandarización alrededor de nuestra API. Aspectos como la anticipación, la generación de incentivos y el reclutamiento de aliados de todo tipo, la penetración rápida en el mercado y la creación de una base de usuarios, la gestión de las expectativas de todos los intervinientes … son determinantes.
• Un modo de despliegue de APIs flexible, ubicuo y escalable basado en la nube nos permite entrar en el negocio a bajo coste y reduciendo riesgos y posteriormente crecer si hay demanda. Además, la posibilidad de monitorizar la utilización que los usuarios hacen de la API nos aporta información muy valiosa para mejorarla y desarrollar nuevos productos.
• Mediante modelos fremium y SaaS podemos favorecer la prueba y la adopción de nuestra tecnología por parte de los partners desarrolladores de aplicaciones.

A cambio de estos beneficios, el modelo basado en APIs adolece de algunas desventajas (características de los enfoques fremium y SaaS):

• Ingresos más lentos, al estar basados en la conversión de clientes gratuitos y en cuotas mensuales
• Bajos costes de cambio para nuestros usuarios, que pueden abandonarnos por la competencia en cualquier momento o, en el mejor de los casos, al final del presente período de pago

Todas estas desventajas lo son, naturalmente, si comparamos con los enfoques más tradicionales de venta de licencias perpetuas (si es que este modelo va a seguir siendo sostenible durante mucho tiempo).

Adicionalmente, el de las APIs es un negocio tecnológico más donde la famosa frase de “en cuanto consiga que esto funcione me lo van a quitar de las manos” TAMPOCO funciona. Los ingenieros tenemos la tendencia a pensar que si publicamos nuestra API miles de colegas la van a empezar a usar al día siguiente, pero esto no suele ocurrir. No basta con desarrollar un conjunto de servicios web y publicarlos:

• Es necesario que la API solucione problemas reales y urgentes de los partners desarrolladores … y que el producto final de los partners solucione problemas reales y urgentes de los usuarios.
• Hay que hacer un marketing y una venta explícitos de la API a un público tan particular como los desarrolladores: es necesario trabajar con sus influenciadores, desarrollar comunidad …
• Para fomentar el uso por una mayor cantidad y variedad de partners puede resultar útil publicar versiones diferentes de la API para diversos escenarios, sectores o necesidades. Por ejemplo, nuestra empresa de IA puede publicar una versión de la API para aplicaciones de planificación y otra para análisis de redes sociales. La naturaleza del software nos permite hacer esto más fácilmente que si se tratara de un componente hardware.
• Especialmente si la tecnología es realmente nueva, siempre resulta difícil que una nueva plataforma arranque. Por eso, como decíamos en otro post, puede resultar inevitable que nosotros mismos tengamos que empezar a desarrollar y a comercializar aplicaciones de nuestras propias APIs en nichos seleccionados. Desde un punto de vista táctico, esto se puede llevar a cabo con una marca o desde otra empresa diferente. Así conseguiremos clientes, referencias, visibilidad, credibilidad…  (e ingresos, que nunca vienen mal)  para alcanzar una mínima masa crítica que dispare la difusión y adopción de la API.

Finalmente, para que la API tenga aceptación (y nuestro negocio tenga éxito) hay que envolverla dentro de un “producto completo” para organizaciones desarrolladoras, que incorpore elementos como: funcionalidad suficiente y probada, gestionabilidad (escalabilidad, seguridad, gestión de usuarios, gestión de tráfico), documentación, ejemplos de código, programas de partners, partners de referencia, soporte al desarrollo, recursos de marketing conjunto… y sobre el que se pueda definir una estrategia de monetización rentable.

Las APIs (Interfaces de Programación de Aplicaciones) no son sólo un concepto software, sino que permiten abrir nuestra tecnología -datos, funcionalidad- para que sea utilizada por terceros en el desarrollo de nuevos productos que lleguen a clientes finales. Este tipo de «innovación abierta»  nos permite entrar en mercados a los que por limitaciones de conocimiento, recursos o presencia nunca podríamos acceder directamente.

Lo bueno que tiene esto del high-tech marketing es que cambia a tal velocidad que siempre tienes algo interesante sobre lo que escribir. No hace muchos años hablábamos de cómo Internet había revolucionado el marketing de productos software y ya es tiempo de ampliar estas ideas con algunos conceptos realmente rompedores. Y sin duda uno de ellos es el de las APIs (Application Programming Interface, Interfaz de Programación de Aplicaciones) como plataforma de marketing.

Para los lectores no tecnólogos, en el mundo del software una API es la interfaz técnica mediante la cual un programa pide cosas (datos, operaciones) a otro. Del mismo modo que las personas disponemos de Interfaces de Usuario para manejar las aplicaciones, un software puede usar APIs para solicitar los servicios que proporcionan otros programas. Existen APIs que permiten consultar y entregar datos, procesar/elaborar información, ejecutar lógica de negocio, etc. y con una gran variedad en cuanto a lenguajes de programación, formatos, protocolos, etc. Últimamente, la Web 2.0 ha popularizado una nueva arquitectura de aplicaciones con APIs ligeras (tipo REST) que han fomentado la proliferación de nuevas aplicaciones -conocidas como mashups– que se construyen combinando diversos servicios web.

Para una empresa que desea desarrollar nuevas soluciones y aplicaciones para el mercado final, tener acceso a APIs que proporcionan valiosos servicios de datos, funcionalidad, etc. es primordial a la hora de no “reinventar la rueda”, de alcanzar una alta productividad de desarrollo y de concentrarse en aquellos aspectos que realmente añaden valor adicional (aunque todo esto no sea gratis, como veremos).

Imagino que los lectores con un bagaje de Marketing puro estaréis empezando a pensar: “Todo esto está muy bien. Las APIs son muy útiles para sus usuarios (desarrolladores de aplicaciones) pero ¿de qué me sirven a mí como marketer?”. Pues la realidad es que las APIs no son solo un habilitador tecnológico, son también un habilitador comercial de primer orden. Como veremos, las APIs son la nueva plataforma de marketing de productos y tecnologías software (y de algunos otros relacionados). Voy a intentar explicarlo sin resultar aburrido ni a la gente de Marketing ni a la de Tecnología.

Antes que nada, para hacernos una idea de la magnitud e importancia de este fenómeno, el sitio ProgrammableWeb registra más de 3.400 APIs en categorías que van desde la publicidad a la información meteorológica. Y todas las grandes empresas de la Web publican -y comercializan- sus APIs: desde Google (cuya API Google Maps fue una de las primeras en popularizarse) hasta Twitter (que ya obtiene más tráfico –e ingresos– desde su API que desde su sitio web).

Esencialmente -si disponemos de una cierta tecnología, funcionalidad, datos … que puedan ser publicados como software- comercializar nuestras APIs implica un modelo de negocio diferente en el que, en lugar (o además) de desarrollar aplicaciones finales para resolver las necesidades de un cierto segmento de usuarios, facilitamos y fomentamos que terceras personas (otras empresas de producto software, integradores, etc.) sean quienes identifiquen dichos problemas del mercado, los resuelvan aplicando nuestras APIs y comercialicen esas soluciones integradas.

Es decir, estamos pasando de vender productos completos para usuarios finales a vender componentes software que serán utilizados por “desarrolladores” para proporcionar una serie de soluciones.  En definitiva, estamos dedicándonos a otras necesidades de mercado, otros clientes, otras propuestas de valor, otros productos, otras actividades y recursos clave necesarios, otros ámbitos y escalas, otra fórmula de beneficio… otro modelo de negocio.

Todo esto tiene mucho que ver con otro post en el que veíamos cómo una nueva tecnología -entendida como conocimiento o know-how– posee en sí misma un valor susceptible de comercializarse y cómo una empresa que se enfrenta a la decisión de “qué vender” tiene ante sí un continuo de opciones de comercialización, que van desde licenciar el know-how hasta vender soluciones completas. Y para elegir entre estas opciones (no necesariamente excluyentes) debe tenerse en cuenta diversos factores estratégicos: encaje tecnología / empresa / mercado, ventajas de primer entrante, recursos necesarios, etc.

El éxito de un modelo de negocio basado en API depende por tanto de fomentar el desarrollo de un ecosistema de partners que -aplicando nuestra plataforma tecnológica- creen valor para sus clientes finales. A cambio de integrarnos en la nueva cadena de valor este modelo ofrece la promesa de llegar a más mercados, aplicaciones, clientes, geografías… a través de estos partners, todo ello sin necesidad de conocer en detalle ni invertir específicamente en ninguno de ellos.  ¿Suena bien, verdad?

La esencia de las APIs como estrategia de marketing de software se basa en algunos ejes habitualmente tratados en este blog: dinámicas de productos plataforma y complementarios, efectos de red, estandarización, innovación abierta y un modo de despliegue flexible, ubicuo y escalable basado en la nube que nos permite entrar a bajo coste y crear modelos fremium y SaaS que favorezcan la prueba y la adopción de nuestra plataforma.

Trataremos de detallarlos (junto con algunas desventajas de este modelo) en un próximo post. Mientras tanto, ¿tenéis alguna experiencia en marketing basado en APIs?