Header Ads Widget

Ticker

6/recent/ticker-posts

8 desafíos inesperados de ejecutar una API como producto

 

Muchos emprendedores de software están interesados ​​en crear un negocio que funcione en torno a una API. Como tal, la tendencia API-as-a-Product ha florecido en los últimos años, con más y más startups comenzando a adoptar una API como una oferta comercial central de SaaS. Esto es emocionante, ya que una API de autoservicio podría generar ingresos pasivos para el proveedor.

Sin embargo, puede que no sea tan "pasivo" como cree. Mantener una excelente API como producto requiere una gran cantidad de soporte continuo. También hay muchas preguntas abiertas para responder al crear su modelo de negocio. Por ejemplo, ¿Cómo se deberían fijar los precios de las llamadas a la API? ¿Cómo deberíamos diseñar el servicio para una experiencia de desarrollador de calidad? ¿Cómo podemos hacer evolucionar la API sin introducir cambios importantes? ¿Qué desafíos debemos anticipar a medida que aumenta el uso?

Para nuestro LiveCast de API como producto , contratamos a Alan Glickenhouse , IBM y Ed Freyfogle , cofundador de OpenCage, para que profundizaran en la tendencia de API como producto. En el evento, exploramos cómo hacer un negocio funcional en torno a una API y nos dimos cuenta de algunas realidades inesperadas de poseer una API como producto en producción.

A continuación, revisaremos estos desafíos inesperados que surgen con API como producto. Por supuesto, no todos los productos de API se encontrarán con todos estos problemas, pero todos deben ser conscientes. Por lo tanto, considere estos consejos para superarlos y crear un negocio moderno, rentable y amigable para los desarrolladores.


1. Es más que un desafío técnico
“Un producto API es una oferta de API que se pone a disposición de un mercado objetivo para satisfacer las necesidades de un cliente desarrollador”, describe Glickenhouse. Tener un mecanismo de entrega estandarizado basado en máquinas permite el aumento de la automatización y la digitalización general. Pero crear un modelo de API de autoservicio que funcione es más difícil de lo que parece.

"Es un trabajo muy duro", dijo Freyfogle. Los proveedores de API suelen ser ingenuos al creer que proporcionar una API es simplemente un desafío técnico. “Si puede hacer que funcione, es suficiente”, puede pensar. En realidad, los desafíos de su negocio pueden superar significativamente el esfuerzo técnico.

Esto se debe, en parte, a una brecha de conocimiento general. Si bien existen muchos estándares compartidos en torno a los formatos, el diseño y los protocolos de API, existen menos prácticas comerciales compartidas dentro de esta nueva economía. "Hay muchos consejos técnicos muy buenos, hay muy buenas discusiones sobre la tecnología más nueva, pero no tanto sobre el lado comercial de las cosas", dijo Freyfogle.

2. Darse cuenta de que necesita un administrador de productos API
Debido a esta condición, muchos productos API ingresan al mercado sin un gerente de producto o una mentalidad de producto lúcida. Esto puede deberse a que el producto es una empresa en solitario o está respaldado por un equipo ajustado.

Un gerente de producto tradicional identifica un mercado objetivo, comprende las necesidades del cliente y genera un paquete que se adapta a esas necesidades. Aunque los equipos de API podrían beneficiarse enormemente de un Gerente de Producto de API , Glickenhouse descubre que a menudo no lo hacen. “Este es un rol del que muchas empresas intentan prescindir”, describe Glickenhouse.

Adoptar un punto de vista de la administración de productos puede ayudarlo a considerar el ciclo de vida de la API y estimar los costos continuos. En el proceso, puede descubrir herramientas de puerta de enlace o administración de API complementarias que podrían ayudar a alojar y asegurar la oferta de API, descargando el trabajo de mantenimiento potencial.

3. Los desarrolladores enviarán spam a su prueba gratuita
Ed Freyfogle ha pasado más de cinco años ejecutando OpenCage, una API REST de geolocalización sencilla impulsada por datos abiertos. A lo largo de su negocio de SaaS basado en API, ha notado un fenómeno extraño: "la gente hará todo lo posible para no convertirse en clientes".

Los desarrolladores de software quieren probar antes de comprar. Por lo tanto, tener una cuenta freemium o una prueba gratuita es estándar para los modelos de suscripción SaaS. Sin embargo, Freyfogle ha descubierto que los usuarios abusan habitualmente de estas pruebas gratuitas. En lugar de actualizar a un nivel de pago, algunos usuarios crearán cientos de cuentas de prueba gratuitas. Para el propietario de la API, vigilar todo esto puede pasar factura. "Es frustrante y lleva mucho tiempo", dijo Freyfogle.

4. Los desarrolladores se resisten a pagar
Los desarrolladores quieren pagar solo por lo que usan. Sin embargo, Freyfogle ha notado una cruda contradicción: los desarrolladores quieren una previsibilidad completa de los precios, pero son terribles para estimar el uso. Dentro de la cultura de los desarrolladores de software, la gente "se resiste profundamente a pagar por cualquier cosa", dice Freyfogle.

Curiosamente, en la práctica, Glickenhouse encuentra que la mayor parte del potencial comercial de API ni siquiera reside en la carga directa, sino en modelos indirectos . "Esta es la verdadera monetización de la API", describe. Por ejemplo, en algunos modelos de afiliados, un desarrollador recibe un pago y actúa como agente del proveedor. Por lo tanto, puede ser conveniente que los proveedores de API consideren qué métodos alternativos o asociaciones podrían aprovechar fuera de la monetización directa.

Los proveedores de API deben considerar los límites de uso, los planes de suscripción de precios en consecuencia y considerar cómo agrupan el acceso al punto final por cuenta de desarrollador. Con todo esto en mente, averiguar los términos financieros en torno a un producto API y demostrar su éxito en la producción puede llevar algún tiempo.

5. Brindar apoyo continuo es desafiante
La carga de brindar apoyo puede ser una sorpresa. Especialmente para equipos pequeños, puede ser un desafío proporcionar comentarios continuos para respaldar una integración funcional. Esto se ve agravado por el hecho de que muchas personas no leen los documentos. "Constrúyalo y no lo leerán", bromeó Freyfogle.

O, los desarrolladores pueden acercarse a su servicio que tienen poca experiencia en programación. "Definitivamente no asuma que todos los usuarios serán ingenieros con mucha experiencia", dijo Freyfogle.

Los servicios de API globales también pueden encontrar barreras de idioma. Aunque el inglés es la lengua franca del desarrollo de software, muchos usuarios no se sentirán cómodos haciendo preguntas en inglés y tendrán dificultades para comunicarse con usted. Para ayudar a resolver este problema, Freyfogle recomienda eliminar la jerga y el conocimiento cultural anglocéntrico de sus materiales de apoyo.

6. Reducir las barreras a la adopción
“Las API permiten que los desarrolladores consuman y utilicen de forma segura y sencilla los activos empresariales”, describe Glickenhouse. Sin embargo, con demasiada frecuencia, la experiencia del desarrollador no es el centro de los productos API. No debería haber “barreras para adoptar un producto API”, enfatiza Glickenhouse. La excelente experiencia de un desarrollador de autoservicio requiere previsión y mucha construcción.

Un elegante portal de API incluirá documentación de referencia, entornos de prueba, ejemplos de código, fragmentos de código en varios idiomas, una guía de introducción, una guía de autenticación y SDK para soporte multiplataforma. Al bajar la barra de entrada para reunirse con el desarrollador donde sea que se encuentre, puede aumentar la usabilidad y las tasas de adopción.

7. Tu competencia real puede sorprenderte...
Los gigantes de Amazon, Microsoft y Google del mundo podrían construir fácilmente una API y eliminar su producto en un instante, ¿verdad? Bueno, en la práctica, Freyfolge no ha encontrado ningún problema aquí. Es fácil para una startup diferenciarse. En cambio, el verdadero competidor suele ser el usuario desarrollador, que dice: "Oh, podría construir esto yo mismo".

Los desarrolladores pueden cuestionar el valor de su oferta y asumir que pueden construirla por su cuenta. Esto es especialmente común si su servicio es una capa alrededor de datos de código abierto, como es el caso de OpenCage.

"Una gran parte del argumento es convencerlos de por qué no deberían construirlo ellos mismos", dijo Freyfogle. Para llegar a los usuarios potenciales, recomienda enfatizar que el mantenimiento es mucho más difícil que el desarrollo. Haga que los ahorros de tiempo y costos sean claros y cree experiencias de desarrollador limpias para un uso rápido y conveniente. Una vez que los usuarios desarrolladores se den cuenta de la dificultad de construir su propia API, es más probable que vuelvan a su servicio.

8. Constrúyelo y ellos (puede que no) vengan
Muchos productos API incipientes adolecen de falta de promoción. “No asuma que solo debe hacer que [la API] esté disponible”, dijo Glickenhouse. "Es necesario fomentar el uso y realmente impulsar el consumo e iterar el producto", describió.

Las API como productos no solo deben promocionarse a sí mismas, sino luchar por la atención de los servicios de la competencia. Para destacar, existen muchos métodos para aumentar la exposición de su API . Por ejemplo, puede organizar un lanzamiento de Product Hunt y ofrecer ventajas a los nuevos usuarios. Puede perfilar su servicio en directorios y mercados de API . O bien, mejorar el SEO del centro de desarrolladores y publicar contenido para visitantes que no son de TI podría ayudar a atraer a nuevos públicos.

Reflexiones finales: el producto real es la confianza
Apenas hemos rayado el servicio de lo que se necesita para mantener un producto API funcional. A medida que más empresas confíen en dependencias de API de terceros, es probable que exista una mayor necesidad de cumplir con los SLA y las normativas . Además, a medida que se vulneran más y más API, la gestión de la seguridad y el acceso está cobrando mayor importancia. Por lo tanto, auditar su área de superficie en busca de vulnerabilidades de seguridad es vital para mantener un producto API estable.

Como puede ver, ejecutar una API pública como producto no es tan fácil como parece. No se trata solo de escribir una especificación de OpenAPI y generar algunos documentos. En la práctica, la mayor parte de su tiempo puede dedicarse a áreas completamente no técnicas para respaldar el producto.

Pensando desde la perspectiva del desarrollador, algunos requisitos comunes incluyen: ¿Resuelve mi problema? ¿Puedo depender de ello? ¿El precio es razonable? Con todo esto en mente, lo que realmente está vendiendo es el compromiso de mantener la API. "El verdadero producto es la confianza", dijo Freyfogle.

Publicar un comentario

0 Comentarios