Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo tratar su API como un producto


 

¿Qué significa "API como producto"?

Aunque tendemos a pensar en las API de una manera muy técnica, se combinan cada vez más en el contexto de las ofertas y los valores comerciales . En consecuencia, muchos están recontextualizando las cosas para tratar las API más como productos .

Una API es esencialmente un servicio tradicional, que brinda capacidad al usuario final sin compartir los riesgos y costos asociados con el servicio. Apropiadamente, incluso si el proveedor de API no funciona como una empresa per se, deberíamos tratar la API como un activo comercial en lugar de una base de código amorfa. Cuando el proveedor de API es de hecho una empresa, solo hay una razón más importante para hacerlo.

Para ayudar a comprender por qué esto es valioso y aprovechar los resultados de tal cambio en el pensamiento para mejorar los sistemas y la tecnología, definamos algunos términos comerciales dentro del contexto de la industria API.

Consumidor

Cuando alguien dice consumidor, lo primero que viene a la mente de la mayoría de la gente es una persona que compra un producto, intercambia moneda o servicios por ese producto. En el mundo de las API, un consumidor es simplemente cualquier persona que utiliza un servicio, independientemente de si se paga o no.

Hay dos tipos de consumidores: externos e internos . El consumidor externo es exactamente lo que parece, un tercero que existe fuera del negocio. Este puede ser el usuario final que utiliza el punto final público gratuito u otra empresa que utiliza un punto final privado pagado. Un consumidor interno , sin embargo, es alguien que existe dentro de la unidad de negocio. Esto puede parecer extraño para las personas que no son empresarios; después de todo, ¿cómo puede una empresa comprar sus propios productos?

Desde una perspectiva comercial, hay un valor detrás de cada transacción, independientemente de si la transferencia de valor es simplemente para generar datos, integrarse con soluciones de terceros o generar ingresos directamente. Por lo tanto, al tratar la API como un generador de valor empresarial central que se integra con ambos tipos de consumidores, puede aprovechar las fuentes de ingresos que tiene y mejorar la experiencia del consumidor.

Más sobre la producción de API: 7 pasos para crear productos API exitosos

Inversión

La gente tiende a pensar en la codificación como crear algo de la nada, pero el hecho es que el desarrollo no es un proceso de costo cero . Por cada hora que se pasa trabajando en la base de código, desarrollando nuevas integraciones, creando nuevos puntos finales, hay un costo. Este costo puede ser en horas de trabajo o en el costo muy real de poner en marcha servidores virtuales o físicos adicionales para admitir las funciones de la API.

Este costo es algo que debe gestionarse para obtener un mejor rendimiento del valor. Quedarse sin dinero cuando se ha creado la mitad del código base significa que no tiene nada que ofrecer al consumidor, pero quedarse atascado en la creación perpetua de puntos finales que generan ingresos mientras se ignora el valor central para el usuario puede ser tan dañino e inútil.

Los procesos de gestión de la inversión y la financiación pueden orientar mejor el desarrollo y la producción para garantizar al menos un producto mínimo viable. La iteración y la expansión de esta demanda asegura que el producto pueda evolucionar para adaptarse a las necesidades comerciales cambiantes, siempre que se construya en torno a los comentarios de los usuarios y los análisis del mundo real .

La clave aquí es garantizar el retorno de la inversión no solo por el valor agregado para las diversas partes interesadas y propietarios de la API, sino por la cantidad muy real de activos y recursos aumentados que se pueden invertir directamente en el desarrollo. Esto, a su vez, puede resultar en el desarrollo de características a largo plazo que faciliten la financiación a largo plazo.

Hojas de ruta y ciclos de vida

Si vamos a tratar la API como un producto, entonces tiene sentido utilizar hojas de ruta y ciclos de vida del producto . Definir cuál es el producto mínimamente viable y luego desarrollar hojas de ruta e implementar otras herramientas de gestión del ciclo de vida (como API Model Canvas ) para gobernar la iteración tiene varios beneficios masivos.

En primer lugar, este proceso evita el deslizamiento de funciones . Al limitar el desarrollo a un curso establecido de funciones, valores o adiciones conocidas, el alcance progresivo puede ser limitado, haciendo un mejor uso de los recursos limitados y asegurando que los consumidores obtengan lo que necesitan antes que nada. Esta prevención de la fluencia también suele dar como resultado una base de código más reducida, que es más fácil de iterar, documentar y corregir.

Además, al limitar el desarrollo a lo que está en la hoja de ruta, evita puntos finales adicionales no utilizados, funciones que nunca se completan, etc. Básicamente, está evitando la hinchazón, que a su vez evita la fatiga de las funciones y reduce la huella de amenazas de seguridad.

Además, implementar un proceso de gestión del ciclo de vida que refleje procesos como los que se encuentran en ITIL u otras pautas de gestión puede garantizar que se cree valor a largo plazo y que los recursos limitados se gestionen de forma óptima. Esto tendrá un impacto a largo plazo en su organización y puede garantizar que la API se mantenga durante mucho tiempo.

Muy relacionado: 5 consejos para comenzar su viaje de API pública

Revertir la relación entre desarrollador y consumidor

La relación clásica entre el desarrollador y el consumidor podría verse así: "creamos esta cosa increíble, ahora, ¿cómo podemos hacer que la gente lo desee?" Desafortunadamente, eso no siempre es efectivo cuando se trata de API. Una API, por su propia naturaleza, generalmente se crea para hacer algo muy específico. Al tratar la API como un producto, básicamente está invirtiendo este enfoque. En cambio, se convierte en "la gente realmente quiere esta función y base de código, ¿cómo podemos construir esta cosa increíble?"

La iteración y el desarrollo deben basarse completamente en el concepto fundamental de hacer lo que el consumidor necesita . La repetición de los comentarios y los casos de uso del mundo real siempre proporcionará bases de código mejores y más adoptadas, y dará como resultado un proyecto con mejor soporte. El consumidor en este enfoque es lo primero y luego la tecnología sigue.

Por supuesto, este no es siempre el caso, como ocurre con las API especializadas o las API que implementan sistemas experimentales, pero en esos casos, la API no se enmarca realmente como un producto; en otras palabras, es una excepción muy particular a lo que debería ser visto como una regla fundamental general.

Consulte también: Consejos sobre cómo monetizar las API

Amigable para el consumidor

Cualquier negocio le dirá que el éxito va de la mano con ser amigable con el consumidor . A menos que sea la única opción para un caso de uso muy específico, si su producto es menos fácil de usar, no será ampliamente adoptado frente a la competencia. Dicho esto, hay ciertos factores que deben considerarse verdaderamente “fáciles de usar”.

  • La API debe tener una gran experiencia de desarrollador : esto significa que la API debe ser fácil de incorporar (configurar una cuenta y administrar datos personales), describir (la API debe tener una competencia y función central que se pueda explicar) y consumir (documentación debe ser adecuado y los sistemas de comprensión en su lugar). No garantizar que se pueda consumir la API significa que tendrá un producto demasiado complejo que los usuarios evitarán frente a alternativas más sencillas.
  • La API debe comercializarse adecuadamente y evangelizarse dentro del contexto correcto : una API bancaria segura que utiliza sistemas y tecnologías existentes de una mejor manera no es " disruptiva ", y comercializarla como tal haría que muchos consumidores que desean un sistema estable y probado busque en otra parte. Lo mismo ocurre con los usuarios que desean algo nuevo: si su API tiene la marca "lo mismo de siempre" y, sin embargo, se comercializa para los primeros usuarios, verá una baja adopción y un escaso éxito.
  • La API debe ser única : el mercado es enorme y, por cada implementación, hay una alternativa que compite por el primer puesto. En pocas palabras, para ser un producto API viable, debe ser único en alguna parte de su implementación. Ya sea que esto signifique que la interfaz de usuario está diseñada para un flujo de trabajo en particular o que la solución sea verdaderamente novedosa, la API debe tener un elemento único que la haga intrínsecamente valiosa para los consumidores internos y externos.
  • La API debe ser segura : ningún usuario considerará una solución amigable si sus datos no están protegidos, se intercambian de forma clara y no están cifrados. Asegure su API , y el valor será evidente para el usuario promedio.

Definir y adoptar roles comerciales

Si bien esto probablemente hará que algunos tipos anti-negocios se quejen, quizás la mejor manera de integrar este concepto de “negocios como una API” es adoptar algunos roles comerciales comunes dentro del equipo de desarrollo de productos. Una API que integre estos roles debe tener algunos roles básicos para ayudar a guiar la forma, función, desarrollo y marketing.

  • Un gerente de producto de API puede ayudar a guiar al gerente de producto de API puede ayudar a guiar a la API para que se adhiera a las pautas comerciales y las hojas de ruta establecidas.
  • Los gerentes de ventas de API pueden ayudar a definir la evangelización y el marketing que se deben realizar para respaldar al usuario externo e impulsar la visibilidad.
  • Los administradores de procesos de API y los propietarios de procesos pueden ayudar a guiar las funciones de la propia API, así como los recursos que gobiernan.

Si bien hay muchos roles, como evangelista , defensor, etc., estos tres son un muy buen comienzo, y adoptarlos puede ayudar a reformular una API en un producto.

Sobre la gestión del equipo de API: ¿Qué cualidades hacen a un gran propietario de producto de API?

Suponga que su API se convertirá en una API pública

Si bien muchos desarrolladores de API se desarrollan dentro de su estado comercial actual y dado, esto puede ser perjudicial. Asumir que su API siempre será privada, o que siempre se limitará a las interacciones comerciales, solo limita el potencial de crecimiento y nuevas fuentes de ingresos.

Suponiendo desde el principio que eventualmente todos usarán su API, puede comenzar a desarrollar sistemas de tal manera que respalde esta posibilidad.

En pocas palabras, suponga que al final del día, no estará allí para guiar al futuro usuario público a través de su API, independientemente de si tiene la intención de convertirla en una API abierta. Desarrolle de tal manera que este pivote se pueda realizar fácilmente, con un costo mínimo y con una aplicación eficiente; al menos, está permitiendo el éxito, en lugar de prevenirlo.

Pensamientos finales

Para adoptar completamente una mentalidad de "API como producto", asuma que su API se hará pública. Esto resultará en puntos finales mejor definidos, enrutamiento más eficiente, mejores sistemas de escalabilidad e interfaces que están bien documentadas y definidas, incluso si es posible que nunca se abran al público.

No todas las API encajarán en la idea tradicional de lo que es un "negocio"; algunas API son solo para uso interno o para audiencias personalizadas muy limitadas. En muchos casos, es posible que ni siquiera haya una fuente de ingresos directa. No obstante, cada API tiene sus propios consumidores y, como tal, tratar la API como si fuera un sistema empresarial vital puede tener enormes beneficios para sus usuarios.

Suponga, independientemente del producto final, que su API algún día será un producto público. En el mejor de los casos, estará pensando en el futuro y, en el peor, simplemente participará en un desarrollo más eficiente, valioso e impactante para crear un mejor producto.

Publicar un comentario

0 Comentarios