Llevando al mercado nuestro producto de API (1)
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.]
























