Cuándo decidí empezar a dar clases de Product Management en la Universidad de Palermo, una de las principales motivaciones era el placer que me da poder responder preguntas relacionadas a metodologías, equipos, técnicas, experiencias… en fin, me gusta hablar de producto y de cómo hacer productos.
Incluso cuando son charlas difíciles o preguntas de respuesta incierta.
Me acuerdo por ejemplo que una vez hace unos años me preguntaron por la diferencia entre empresas que tenían CPO (Chief Product Officer) y las que no. La cabeza se me disparó con cientos de ideas de por qué podía funcionar o no, pensando en empresas que conocía que operaban de una u otra manera y los éxitos o fracasos que habían tenido. Luego de dar mi primera impresión cómo respuesta, esperé ansioso el primer rato libre en el que pudiese poner los dedos en teclado y hacer algo de trabajo de investigación para mandar una respuesta más elaborada, con ejemplos y recomendaciones.
Cómo te conté, más tarde tuve la oportunidad de estar frente a Marty Cagan. Y le hice la misma pregunta. Y su respuesta, si bien parecida a lo que había investigado, termina de ampliar mi visión y formar mi conocimiento de este tema puntual.
En resumen: responder preguntas me divierte, me motiva y fundamentalmente me hace aprender más 🙂
Ahora por ejemplo pienso en el futuro cercano transformar esa pregunta en un post para el blog que pueda ayudar a todos los que están con dudas sobre este tema.
Así que se me ocurrió un pequeño desafío / propuesta:
Abajo de todo en esta página vas a encontrar la sección de comentarios de este post. Deja ahí cualquier pregunta relacionada con producto, y voy a hacer mi mejor esfuerzo por responder todas en menos de 1 día hábil.
Más allá de que es algo que me gusta, espero también me ayude a seguir entendiendo sobre los desafíos que tenés. Y desde ya, ¡espero que mi respuesta te pueda ayudar a vos!
Hola Nacho, ¿cómo estás?.
Van dos:
1 – Tiene que ver con priorización, que criterios/herramientas usas actualmente para ordenar y priorizar un backlog cuando estás arrancando un producto?.
Hablo específicamente de valor, como determinás las dimensiones a tener en cuenta y como las ponderás?. Lo veo más complejo aún cuando es un producto que no está todavía productivo.
2- Criterios para recortar alcance, lo veo muy artesanal y poco orientado en general a un proceso definido, ¿usas alguno que no sea sentido común?.
Abrazo,
Javi G.
Buenisimas las preguntas Javi, ¡gracias!
La verdad que las 2 están relacionadas, y la primera va de la mano de un post que estoy armando sobre seteo de objetivos.
Pero antes de mandarte ese post, voy a tratar de cumplir con el desafío y responder en 24hs!
1- Lo primero que hay que hacer para priorizar correctamente es tener claros los objetivos de la compañía, y traducirlos a KPIs del producto. Importante tener en cuenta que un mismo objetivo compañía se puede atacar con muchos KPIs de producto, así que en general lo mejor es elegir trimestralmente aquellos que nos vamos a focalizar en ese período. (Por ejemplo, si quiero alcanzar el objetivo “Aumentar ventas” puedo trabajar en el KPI de producto “mejorar conversión” o “reducir errores de checkout”).
Si eso no está claro podés hacer un hermoso ejercicio de priorización que va a ser simplemente para sentirte que lo estás manejando, cuando en realidad no tenés claro ni hacia dónde querés llevar el producto.
Ahora asumamos que tenés eso:
En el tiempo fui evolucionando la forma de determinar valor. En mis primeras épocas utilicé matrices de priorización. Básicamente consistía en un cuadro doble entrada, con las funcionalidades en las filas y cada columna tenía uno de los KPIs de producto, a los cuales asignaba un valor Alto/Medio/Bajo según la cantidad de usuarios que impactaba (ej 0-25% bajo, 25-75% medio, +75% alto). Según la prioridad del KPI cada letra se traduce en un número, en general utilizando la secuencia Fibonacci. Por ejemplo para un objetivo de alta prioridad, el valor bajo equivale a 5, el medio a 8, el alto a 13. A nivel herramientas lo hacía en excel 🙂
Luego pasé a ser un ferviente creyente en traducir todo a valor monetario. Encontramos formas de traducir todo lo que sea un nuevo proyecto a: incremento de ventas o ahorro de costos. Lo que hacíamos era utilizar (en general) historia previa para proyectar cómo iba a impactar el feature. Un ejemplo de Despegar: si estabamos agregando un medio de pago en un producto, evaluamos el impacto que tuvo agregar ese medio de pago en otro (en términos de incremento de ventas o conversión) y proyectamos el resultado.
El problema que tiene esta forma es que usamos estimaciones, que se basan fuertemente en nuestro conocimiento previo y supuestos, que por más buenos que sean, siempre van a tener un margen de error alto cuando salgamos al mercado. Simplemente porque en general no sabemos el nivel de adopción que va a tener la funcionalidad cuando la lancemos, dado que depende de muchos factores fuera de nuestro alcance.
Y ahí es donde entra en juego Product Discovery. Lo que Product Discovery propone es que armes una prueba en un día que te resultados tangibles que puedas proyectar con mucha mayor precisión. Volviendo a mi ejemplo: en lugar de agregar el medio de pago realmente (y pasar dos meses trabajando) para darte cuenta al lanzarlo que nadie lo usa, lo que hacemos es agregar una “puerta falsa”, un botón al nuevo medio de pago que lo hacemos en menos de 1 hora, y probamos cuanta gente lo clickea (con un mensaje de “disculpas aún no está listo). Con esta información, posiblemente tardaste exactamente lo mismo que hacer una proyección compleja basada en el pasado, pero tenés información muy muy precisa del resultado que va a tener cuando lo hagas de verdad, y tu priorización va a ser muy buena.
2- Me da miedo pensar hoy en recortar alcance. El criterio tiene que ser exactamente el opuesto: que es lo absolutamente mínimo que puedo lanzar “sin hacer el ridiculo”. Es el concepto de MVP que está muy en boga ahora (y también debo un post al respecto).
Con lo cual no deberías pensar en recortar scope sino cual es el mínimo y de ahí “agregar” scope en la medida que tu MVP tenga éxito o aprendas cómo lo usa el usuario y que otras cosas está necesitando.
Nuevamente gracias!
Update: acá está el link al post de priorización: http://www.productosdigitalesganadores.com/priorizacion-efectiva-del-backlog-con-experimentacion-rapida/
Soy de la generación que compro vinilos y disco y hoy en día no pago mas para música “física” si no para el servicio de uso online. Mi pregunta es: si ya los productos desaparezcan para transformarse en servicios no deberíamos cambiar nuestra orientación a “service design” y service design management? El termino “product owner” es todavía actual teniendo ese concepto en cuenta? y como se llamaría el PO si ya no son mas productos si no servicios?
En primer lugar creo que hay un problema respecto a la definición de producto y servicio.
Desde hace años en la industria de productos digitales tratamos a (por dar un ejemplo) un sitio e-commerce como un producto. Creo que podría decirse que en el sentido “tradicional” de la palabra no lo es. Sería como decir que una tienda de un retail (cómo Falabella) es un producto. Pero tampoco creo que le cuadre del todo la palabra servicio.
En resumen y para ir al grano con la respuesta: creo que es mucho más importante que pensemos en el usuario y en cómo le estamos resolviendo el problema. Si llamamos a eso servicio o producto no me importa tanto (aunque estoy de acuerdo que gran parte de “resolver un problema” es dar un servicio, aunque tu producto sea un lavarropas). Pensar en el “job to be done” punta a punta.
Lo que sí creo es que “la gente de producto” (product manager, UX designers, developers, marketers, etc etc) deben empezar a mirar un poco más con el “lente” de service oriented design, sin importar el nombre que le demos a lo que estamos construyendo 🙂 Y me incluyo, estoy muy en pañales en esa disciplina.