Seis esquemas para ayudar a explicar los conceptos de gestión de productos.

Algunas imágenes útiles para comprender y explicar ideas clave en la gestión de productos.

Dicen que una imagen vale más que mil palabras, pero para ser honesto, creo que esto es incluso un eufemismo: la visualización ayuda a garantizar una comprensión común de la idea, simplifica la comunicación y elimina la mayoría de los matices inherentes al lenguaje escrito y hablado.

Me gustaría mostrarle seis esquemas que uso a menudo cuando discuto ideas relacionadas con la gestión de productos. Son bien recibidos por el público y transmiten perfectamente la esencia. Estos esquemas son:

• "Gerente de producto como un cuello de botella".
  
• "Embudo de entrega del producto".
  
• "El clásico enfrentamiento Cascada - Ágil".
  
• "Tamaño de la iniciativa, riesgo y participación de liderazgo".
  
• "Bunkers de conocimiento".
  
• La importancia de la segmentación.
  

Puede usarlos en su trabajo de la forma que desee.

Traducido a Alconost

"Gerente de producto como un cuello de botella"

Uno de los errores más comunes que noto con los gerentes de producto es el deseo de participar en todas las discusiones. Sí, esta es la intención correcta: debe comprender todo para poder responder cualquier pregunta sobre el producto.

Desafortunadamente, este enfoque tiene muchos inconvenientes. En primer lugar, esto no es práctico: se sobrecargará rápidamente con información, lo que afectará negativamente no solo la efectividad del equipo, sino también su bienestar. Créeme, experimenté esto en mí mismo. En segundo lugar, estás destruyendo así la autonomía del equipo.

Un buen gerente de producto sabe cuándo intervenir y cuándo es mejor apartarse: hablarán y lo resolverán por sí mismos. El objetivo de crear un equipo autónomo es eliminar tantas dependencias como sea posible.

Considere el ejemplo en la imagen de abajo. Imagine la situación a la izquierda cuando un desarrollador web pregunta qué algoritmo de seguimiento implementar, y el gerente de producto recurre a analistas que dicen que debe seguir con la implementación de iOS. Luego, el administrador acude al desarrollador de iOS, recibe la información necesaria y luego regresa al desarrollador web y le explica todo. Este enfoque no solo agrega trabajo adicional al gerente de producto, sino que también retrasa la resolución del problema.

Compare esto con el ejemplo de la derecha: el desarrollador web se dirige directamente al analista primero (que explica lo que se requiere), y luego al especialista de iOS (que proporciona la información necesaria). Observe cómo hay menos interacciones en este caso (flechas rojas).



Si ampliamos nuestro ejemplo y agregamos algunas flechas más (verde y azul), esto estará mucho más cerca del número real de problemas resueltos simultáneamente en el equipo. El número de interacciones está creciendo rápidamente, y todas están vinculadas al gerente.



Cómo aplicar el esquema. Si está constantemente sobrecargado de trabajo, piense si la interacción en el equipo se ajusta de manera óptima: ¿realmente necesita estar en cada reunión? ¿Continúa el trabajo normal mientras está de vacaciones, o todo se detiene? Si esto último es cierto, entonces debe hacer esfuerzos conscientes que simplificarán la interacción en su ausencia.

"Embudo de entrega del producto"

Este es uno de mis patrones favoritos: me permite explicar el concepto de un embudo de productividad del equipo con respecto al tamaño de los proyectos en los que se está trabajando. A menudo tengo que enfrentar la decepción de los socios comerciales y los desarrolladores sobre el tiempo que tarda el producto en ingresar al mercado: les parece que el trabajo va demasiado lento.



Por lo general, este problema se debe al hecho de que el trabajo se lleva a cabo solo en tareas grandes (embudo a la izquierda). Como resultado, un equipo solo puede hacer una cosa a la vez. Este enfoque puede ser correcto si estamos seguros de que se requerirá una determinada función, y esto es raro. Si algo sale de la línea de ensamblaje (en nuestro caso, desde el embudo) y resulta innecesario, al final usted dedica más esfuerzo para comprender esto de lo que se requería.

La razón por la cual en un enfoque flexible del desarrollo tienden a dividir el trabajo en fragmentos más pequeños es que le permite obtener rápidamente un resultado tangible y valioso para el negocio, y con menos riesgo. El embudo de la derecha da mucho más margen de maniobra: las tareas más pequeñas (puntos azules) pueden pasar a través del embudo más rápido, lo que significa que se probarán más rápidamente en la práctica. Si el resultado es exitoso, puede invertir más esfuerzo (círculo rosa). Si el resultado no es satisfactorio, cambiamos a otra cosa, pero limitamos los recursos asignados. Cada prueba en la práctica le permite aumentar los recursos invertidos. Como resultado, tenemos muchos proyectos pequeños, varios medianos y muy pocos grandes. Por lo tanto, se reduce el riesgo y se aumenta el retorno de la inversión.

Cómo aplicar el esquema. Recuerde en qué tuvo que trabajar en los últimos meses (incluido lo que se descartó). ¿Todas las tareas eran grandes en escala y complejidad, o era una combinación de varias tareas actuales (tanto en un tema como en diferentes)? Asigne un tamaño a cada tarea (por ejemplo, en la escala S, M, L) e imagine cómo se verá el embudo.

"El clásico enfrentamiento Cascada - Ágil"

Hay muchos ejemplos en Internet sobre este tema, pero me gustaría llamar la atención sobre los esfuerzos realizados. Muchas compañías de alimentos no dicen directamente que el tiempo en equipo también es una inversión. Si los gerentes de producto tuvieran los informes de pérdidas y ganancias de su creación, verían que los salarios son a menudo el mayor gasto. Por lo tanto, debe buscar todas las oportunidades para aumentar las ganancias (retorno de la inversión).

Cuando un equipo da trabajo en grandes fragmentos, esperamos obtener un efecto inmediato. Pero incluso si suponemos que lanzamos inmediatamente la solución perfecta sin problemas técnicos (le diré un secreto: esto es muy poco probable), resulta que nuestro equipo (si mira la línea de tiempo) realizó grandes inversiones que no funcionaron (gráfico a la izquierda).

Al lanzar el producto con más frecuencia, en partes más pequeñas, está perdiendo su trabajo gradualmente, y comienza a dar resultados de inmediato, porque puede aprender de los errores más rápidamente y comprender qué se necesita y qué no. En el segundo gráfico, el valor de un producto para una empresa es casi siempre mayor que el costo del esfuerzo realizado; esto es por lo que debe esforzarse.



Cómo aplicar el esquema. A menudo uso estos gráficos cuando necesito explicar por qué agregar algo más a las características del producto en la iteración actual no siempre es de nuestro interés. Además, con su ayuda, es conveniente recordarse a sí mismo y al equipo sobre el aspecto comercial del problema.

"Tamaño de la iniciativa, riesgo y participación del liderazgo"

Este cuadro refleja dos aspectos. A la izquierda está la pirámide de iniciativas. Su amplitud muestra cuántas iniciativas se pueden trabajar simultáneamente: una base amplia, mucho, estrecha, un poco. Al mismo tiempo, las tareas con mayor riesgo están en la parte superior (hay pocas) y con un riesgo pequeño en la parte inferior (hay más).



A la derecha hay un indicador de participación de la gerencia. Cuanto más amplio es, mayor se requiere o se espera la participación de la gerencia en el trabajo; es decir, con un mayor número de gerentes de un rango más alto es necesario consultar. Cuanto más estrecho sea el indicador, menos será necesario referirse a los "más altos".

Probablemente tenga muchas tareas pequeñas, como revisar textos escritos o dibujos dibujados: tienen un riesgo muy bajo, los resultados pueden optimizarse constantemente. Aquí el liderazgo no estará muy interesado en participar, y no tiene sentido. Pero las tareas en la parte superior de la pirámide tendrán un mayor riesgo (por ejemplo, podría ser el lanzamiento de un producto completamente nuevo); aquí es donde se necesitará la participación y el apoyo del liderazgo.

Cómo aplicar el esquema. En mi experiencia, este esquema es una herramienta excelente tanto para los líderes como para los propios equipos: explica por qué el liderazgo debería estar involucrado en algunos casos y por qué esto no debería hacerse en otros.

El tema de la participación de los gerentes en el trabajo es bastante complicado. Lo revisé con más detalle en el artículo Por qué el "Modelo de Spotify" no resuelve todos los problemas .

"Bunkers de conocimiento"

Este cuadro es el resultado de una verificación trimestral de la situación en el equipo donde trabajaba mi colega. Esta es una excelente manera de visualizar el impacto del aislamiento de departamentos y equipos en relación con el intercambio de conocimientos. Es imposible tener el 100% de conocimiento en todas las áreas afectadas por el producto, pero si se da cuenta de la falta de conocimiento, esto ayudará a centrarse en la comunicación entre los departamentos.

Un empleado individual generalmente está bien versado en lo que está trabajando. Pero cuanto más lejos esté de los demás, menos conscientes estarán de "su" tema.



Cómo aplicar el esquema. Recuerde a usted y a otros que el trabajo en la organización necesariamente se ralentizará debido al hecho de que nadie puede saberlo todo y, lo que es más importante, si hay un conflicto, entonces una de las razones más probables será la falta de información y no la intención maliciosa ( ver artículo Malentendido, no intención maliciosa ).

La importancia de la segmentación

Uno de los errores comunes que encuentro cuando una empresa considera iniciativas y experimentos es la optimización por valores promedio, y no por segmentos. Mi ejemplo favorito está distorsionado con la percepción promedio: "En promedio, una persona tiene menos de dos piernas".

Si las hipótesis y las áreas de cobertura se vuelven demasiado extensas, naturalmente limitan el impacto potencial de la prueba. De hecho, está tratando de satisfacer a muchas personas al mismo tiempo, y es poco probable que esto funcione. En el diagrama a continuación, el más común es el tercer caso (a la derecha), en el que no hay cambios significativos.

Los siguientes son tres experimentos hipotéticos. En el primero tuvimos un aumento, en el segundo, una caída, en el tercero no hubo cambios. Sin embargo, a menudo, si profundiza en los resultados, puede encontrar nuevas oportunidades potenciales o algún tipo de limitaciones. En el primer caso, aunque el experimento en su conjunto fue exitoso, en el segmento B puede ver una disminución en los indicadores; aquí sería necesario comprender cuál fue la razón del deterioro y, posiblemente, excluirlo cuando se lanzó el producto.

Veamos ahora el tercer caso. En general, no hubo cambios significativos, sin embargo, hay resultados positivos en los segmentos B y C, y se compensan con una caída en los segmentos A y D. Por lo tanto, aquí también recibimos una dirección que puede estudiarse más a fondo.

Cómo aplicar el esquema. Trate de formular hipótesis más específicas y estudie los resultados para obtener posibilidades y limitaciones adicionales. Sobre el tema de las hipótesis y los experimentos, le recomiendo leer algo de Rick Hyam : visite su Centro Experimental . Cree arquetipos a través de la investigación de usuarios y los datos demográficos ( Nikki Anderson ): esto ayudará a comprender mejor a qué segmento de consumidores se dirige.

Conclusión

Eso es todo ¡Espero que los diagramas y diagramas anteriores ayuden a visualizar algunos conceptos y explicarlos a otros!

Sobre el traductor

El artículo fue traducido por Alconost.

Alconost localiza juegos , aplicaciones y sitios en 70 idiomas. Traductores en lengua nativa, pruebas lingüísticas, plataforma en la nube con API, localización continua, gestores de proyectos 24/7, cualquier formato de recursos de cadena.

También hacemos videos publicitarios y de capacitación , para sitios que venden, imágenes, publicidad, capacitación, teasers, expliner, trailers de Google Play y App Store.

→ Leer más