Product Management: ¿Cómo y cuándo agregar más features a tu producto?
Una guía sobre Product Backlog
Este artículo llega gracias a Hilos
Hilos es la plataforma en donde puedes automatizar el Whatsapp de tu empresa. Crea chatbots, campañas y automatizaciones en el mismo lugar. Acaban de participar en Y Combinator y tienen clientes como Agenda Pro y Listopro. Sin duda, si estás buscando ahorrar tiempo a tu equipo de ventas, Hilos es de las mejores opciones.
Para los nuevos Product Managers o profesionales con el rol de producto saber manejar el “Backlog“ (o las nuevas funcionalidades para un producto) es una habilidad clave a desarrollar.
Pequeño disclaimer: En producto, “más” no siempre es “mejor”. Es decir, muchas veces será más importante reducir fricciones en funcionalidades existentes, solucionar bugs y/o implementar mejoras que agregar nuevas funcionalidades.
Sin embargo, en este artículo nos centramos en el análisis para agregar nuevas funcionalidades. Además, probablemente le sirva más a profesionales de Tecnología trabajando en un Corporate o en una startup madura.
¿Qué es un backlog?
Un product backlog es una lista priorizada de características, funcionalidades, mejoras y correcciones que se planea desarrollar e implementar en un producto digital en un periodo de tiempo.
Esta lista actúa como fuente de información y guía para el equipo de desarrollo durante todo el proceso de creación del producto.
¿Quién maneja el backlog?
Para startups que recién comienzan suele ser el confundador responsable del desarrollo, en algunos casos termina siendo el CTO.
Por otro lado, cuando la empresa escala y tiene un producto más robusto, suele haber un responsable de producto por cada funcionalidad grande. Por ejemplo en el caso de las aplicaciones de Delivery existen product manager de la experiencia del usuario en la búsqueda de restaurantes, otros para la experiencia de pagos y otros para la prevención de fraude.
Responsable de producto: Product Owner vs Product Manager
Es un tema polémico dónde cada persona tiene su propia definición. Además, por lo menos en latinoamérica, algunas empresas han empleado mal los términos por miedo a que se malinterprete el “Manager“.
Algunos puntos importantes:
Tanto el Product Owner como el Product Manager suelen ser Individual Contributors. Es decir, no suelen tener reportes directos. Sin embargo, trabajan en equipo (mayormente Diseño, Data y Desarrollo) para crear y mejorar productos.
En startups es más común ver Product Managers que Product Owners.
La principal diferencia radica en que el Product Manager es dueño del producto (desde el diseño, implementación y resultados), mientras que el Product Owner es dueño de la implementación (Gestión del backlog).
Que el Product Manager (PM) sea dueño del diseño implica que sea dueño de entender el problema de los usuarios, entender las oportunidades del mercado y marcar una guía sobre lo que se debe construir (no el cómo). Que sea dueño de la implementación y resultados significa que debe ser accountable de lograr los objetivos de negocios y de tener muy claro su impacto en el P&L: Es decir, cuánto le cuesta producir el producto y cuánto valor está aportando.
Por otro lado, un Product Owner es medido en función de lograr cumplir el backlog, es decir la correcta (y perfecta) implementación del producto. El product owner es una parte más del equipo junto a Data, Diseño y Desarrollo para que el producto salga adelante, más no necesariamente es accountable por los resultados del producto.
Finalmente, son definiciones. Hoy en día existen Product Managers que ejecutan un backlog que pidió el CEO y Product Owners que ven P&L. Lo importante siempre debe ser traer los resultados a la compañia.
¿Qué variables tomar en cuenta para elaborar el Product Backlog?
En mi opinión existen 4:
Nota: Los ejemplos serán desarrollados para un marketplace.
Necesidades del negocio
Es importante que todo lo que se vaya a desarrollar esté alineado, en alguna medida, con los objetivos de la empresa. Una técnica para lograrlo es saber si lo que se va a desarrollar impacta directamente en algún objetivo (u OKR) de la compañia.
Por ejemplo, si uno de los objetivos de la empresa es crecer 15% en usuarios de determinadas ciudades, lo más probable es que se deba priorizar un descuento exclusivo por cliente según su localidad, eso implicaría desarrollar la detección de la localidad del cliente además de la plataforma de descuentos personalizados.
Beneficio para el usuario e impacto esperado
Todo feature visible para el usuario (porque también existen features técnicos que el usuario no ve o “Requerimientos no funcionales“) debería responder a mejorar la experiencia del usuario o hacerla más sencilla, de esta manera el beneficio es tangible y se relaciona directamente con la conversión.
Por ejemplo, si en encuestas con usuarios sale que su proceso de búsqueda natural para los productos que tu marketplace vende es buscando la marca, es muy probable que tengas que desarrollar un navegados o buscador en tu experiencia principal y que este pueda funcionar con keywords relacionadas a la marca.
Factibilidad técnica
En gestión de producto no me gusta totalizar o generalizar; sin embargo, siempre y en cualquier escenario el equipo técnico debería estar involucrado en la gestión del backlog.
Si tienes una idea magnífica que se justifica en decenas de análisis y entrevistas con usuarios pero su desarrollo no es viable técnicamente porque no existe la tecnología suficiente, la arquitectura no lo soporta o no está el talento para lograrlo, no podrás desarrollarlo en el tiempo prometido y puedes comprometer resultados.
(Lo más probable es que puedas hacer un MVP No Code o solo prototiparlo para hacer test con usuarios).
Orden o Priorización
Como responsables de producto es de vital importancia saber priorizar features, hace poco armamos una guía:
Ayúdanos a seguir creciendo compartiendo el artículo con amigos y colegas!
Ya estamos cerca de los 5,000 suscriptores!
¡Buen inicio de semana!