Header Ads Widget

Ticker

6/recent/ticker-posts

Estrategia de producto para API: un enfoque de hoja de ruta

Aprender a volar de un libro ... no funciona

Cuando comencé a trabajar en productos, era un gerente de desarrollo de productos (PDM) junior que trabajaba en un sitio web público. Mi jefe era un gerente de producto experimentado y un mentor excelente, y me sugirió muchos libros y blogs excelentes para leer sobre productos y marketing. A medida que aprendí los conceptos básicos de la gestión de productos, pude aplicarlos en lo que trabajaba todos los días.
Con el tiempo, pasé a una nueva función en la que tenía mi propio producto: una colección de API que utilizan todos los productos orientados al cliente de la empresa. ¡Fue grandioso! Y un poco desconcertante. No sabía mucho sobre las API en ese momento, pero confiaba en que podría resolverlo con la práctica. Había leído muchos libros y había hecho algunos trabajos antes, ¿por qué no?
Fue un poco como cuando Hermione Granger se entera de que no puede aprender a volar una escoba con solo leer sobre ella. Para aquellos que no conocen bien la serie de Harry Potter , Hermione es conocida por leer sus libros de texto con anticipación y luego entrar y sobresalir en la clase con facilidad. Sin embargo, cuando los niños van a su primera lección de vuelo, ella se da cuenta de que su inteligencia con los libros no es suficiente. Y ese era yo tratando de aplicar los trucos habituales del producto a mi trabajo con API.
No es que los consejos de estrategia de producto normales no se aplicaran en absoluto , pero me tomó un tiempo descubrir cómo hacerlo práctico en el mundo de las API. Debido a que el producto no era tan tangible como un sitio web o una aplicación, no estaba claro de inmediato en qué se diferenciaban mis usuarios y que necesitaba ajustar mi enfoque. Mi solución me parece instintiva ahora, pero luché por adaptarme a esto cuando comencé. Entonces, aquí están algunas de mis ideas sobre cómo abordar la estrategia de producto cuando eres el gerente de producto de una API.

Dos conjuntos de usuarios ...

En la gestión de productos, los usuarios son siempre su estrella del norte . A medida que les hace preguntas sobre lo que deben hacer y recopila datos sobre cómo están usando realmente su producto, aprende cuáles son sus problemas y los resuelve. No es tan simple como parece, pero es sencillo: centra tus esfuerzos en tus usuarios y sus problemas, y es difícil equivocarse.
Dicho esto, las API suelen tener dos grupos distintos de usuarios: usuarios desarrolladores y usuarios finales . Y si no está pensando en ambos, correrá en círculos y se preguntará por qué no está progresando como le gustaría.
Los usuarios desarrolladores van a interactuar directamente con su API, llamándola desde su código. Los usuarios desarrolladores se preocupan por si su API es fácil de usar o está bien documentada ; les importará que sea RESTful , que tenga calidad DX , que no sea innecesariamente complicado y que funcione bien siempre que llamen. Los desarrolladores quieren que su documentación sea lo último en autoservicio, porque así no tienen que hacerle preguntas todo el tiempo. En realidad, quieren que la API sea algo que ellos mismos habrían construido. Dependiendo de su modelo de negocio , estos desarrolladores pueden ser desarrolladores internos o externos en una empresa que va a utilizar su API.
Los usuarios finales se beneficiarán de su API a través de algún tipo de interfaz: a veces, es un producto que ha creado su empresa y, a veces, es una interfaz que su cliente creó y se conectará a su API. Incluso si estos usuarios son técnicamente competentes, es probable que no sepan (ni se preocupen) por su API cuando utilicen el producto final. Solo quieren que lo que puede hacer por ellos suceda de la manera más rápida e invisible posible.
Está claro que se trata de dos grupos de usuarios con necesidades y objetivos distintos, cuyos trabajos se sienten muy diferentes y cuyos problemas de usuario no se parecen en realidad. ¿Cómo les sirve a ambos de manera significativa?
Si dedica su tiempo a concentrarse en los problemas de los usuarios desarrolladores, dedicará mucho tiempo a las mejoras técnicas y operativas. Será una API con la que es muy fácil hacer negocios, pero no necesariamente ofrecerá la experiencia del usuario final que realmente moverá la aguja, o incluso obtendrá una mención en las notas de la versión. Alternativamente, si no dedica su tiempo a ofrecer nada más que las funciones que entusiasmarán tanto a los usuarios finales como a los líderes de productos, pronto se creará una pila de deuda tecnológica que nunca se resolverá. Sus propios desarrolladores empezarán a hacerle saber lo descontentos que están con la API que están construyendo y manteniendo, y sus quejas reflejarán la insatisfacción que sienten los desarrolladores externos.

… Dos hojas de ruta.

La solución que encontré para este desafío es aceptar que necesita tener dos hojas de ruta. Esto significa identificar los problemas de los usuarios para ambos grupos de usuarios, brindarles a sus desarrolladores los detalles que necesitan para crear buenas soluciones para esos problemas y trazar dos corrientes de trabajo.
El siguiente paso es el favorito de toda persona productora: priorizar. Es probable que tenga muchas partes interesadas que le dirán cuáles son las prioridades correctas, y su trabajo es, en parte, defender sus elecciones en función de lo que sabe sobre sus usuarios y su mercado. Con dos grupos distintos de usuarios, su trabajo es un poco más complejo. Idealmente, desea lograr un equilibrio entre los usuarios desarrolladores y los usuarios finales de la manera más uniforme posible.
Siempre habrá mucho trabajo en ambas pilas y, cuando el tiempo o los recursos sean cortos, inevitablemente enfrentará una situación en la que no podrá equilibrarlos por igual. En ese momento, tendrás que favorecer a un grupo sobre el otro. No son conflictivos per se, pero guiarán a su equipo de desarrollo en diferentes direcciones cuando se trata del trabajo que están haciendo. Cuando deba elegir uno sobre el otro, siempre dé prioridad al usuario final, pero nunca a expensas de sus desarrolladores-usuarios.Siempre debe escuchar atentamente a sus tecnólogos y, especialmente en estos momentos de priorización, prestar mucha atención a sus sugerencias sobre la forma correcta de pasar por las soluciones de funciones. Como persona de producto que gestiona las API y presta servicios a los desarrolladores-usuarios, sus tecnólogos son uno de sus mejores recursos para entablar conversaciones francas sobre qué (no) hacer.
Una forma de visualizar múltiples hojas de ruta de productos
El diagrama anterior muestra un método para visualizar las hojas de ruta de sus productos. En él, cada carril de natación es un proyecto, que se toma de una lista de problemas definidos por el usuario. Estos pueden ser problemas de usuario final o problemas de desarrollador-usuario. La columna "Categoría" me permite marcar el tipo / impacto principal del proyecto: ¿es UX? ¿Es una mejora de tecnología / operaciones? ¿Está generando ingresos? Utilizo cuatro categorías en general, pero se pueden usar tantas como tenga sentido. La columna "Impacto del usuario principal" es un binario claro: ¿afecta principalmente a los usuarios finales o los usuarios desarrolladores? Algunos proyectos afectarán a ambos, pero siempre hay un primario. Por último, la codificación por colores de estos elementos me permite ver rápidamente cómo estoy equilibrando las dos pilas de trabajo diferentes.
Finalmente, agregaré una nota sobre el formato: puede mantener todo en un archivo de mega-hoja de ruta con múltiples carriles de natación si lo desea, o dividirlo en dos hojas de ruta de producto separadas o cualquier estructura que funcione para usted. Como alguien que mantiene tres formatos de la misma hoja de ruta, no estoy aquí para decirle el formato único verdadero que debería tener su hoja de ruta. Deje que las opciones estéticas sean lo que usted (o su equipo de liderazgo ejecutivo) desee. La parte importante es comprender en qué se diferencian estos usuarios, describir claramente sus problemas de usuario y crear dos flujos de trabajo paralelos para que pueda crear conscientemente soluciones para apoyar a ambos grupos de usuarios sin que ninguno de los grupos pierda su atención.

Publicar un comentario

0 Comentarios