Usted es un gerente de producto a cargo del desarrollo de un nuevo producto y ha realizado meses de investigación para determinar una dirección y una visión para el producto. El desarrollo del producto va bien y ahora ha involucrado a otros departamentos, como marketing, diseño gráfico, ventas y operaciones, para crear una cadena de soporte para el producto.
A medida que se involucren más gerentes de estas áreas, muchos de ellos tendrán sus propios puntos de vista sobre cómo deberían funcionar las cosas. Por ejemplo, usted, como persona técnica, puede imaginarse al equipo de desarrollo implementando una nueva arquitectura que utiliza servicios web para brindar API personalizadas a sus clientes y desarrolladores internos, lo que ayudará a los otros desarrolladores a ampliar su producto mediante el uso de los servicios que brinda. Sin embargo, el personal de marketing y operaciones puede considerar que el cambio de arquitectura no es importante, ya que no tienen el conocimiento técnico para comprender cómo la nueva arquitectura podría impulsar otros productos creados con esa tecnología.
Lo que quiere es similar a lo que quiere marketing y operaciones, pero dado que no entienden la ingeniería de software, es posible que no entiendan en qué están trabajando los desarrolladores. Luego usan su influencia para convencer a otros en la organización de que se salten el desarrollo de la arquitectura.
Si bien puede ser beneficioso incluir a los gerentes de departamento en las reuniones, en lugar de solo los recursos que han asignado a su equipo, a veces es más difícil controlar la dirección de su producto en estos casos.
¿Qué consejos o sugerencias existen para obtener el apoyo de otros gerentes sin que necesariamente se hagan cargo del proyecto con su influencia?
Respondería a su pregunta como si se tratara de "tratar con otros gerentes" porque "prevenir a otros" significaría que no quiere escuchar las opiniones de los demás y tal vez perdió algo de flexibilidad.
Una gran parte del rol de un gerente de producto es exactamente lo que usted describe. A veces, las nuevas sugerencias o ideas son geniales, pero a veces es necesario conservar la idea inicial tanto para evitar retrasos como para garantizar que el producto final tenga sentido.
Dependiendo de dónde estén las sugerencias o los nuevos requisitos, uso diferentes tácticas, pero aquí hay algunas (cada una con sus propias ventajas y desventajas):
Si bien no son exhaustivas, las ideas anteriores son las principales tácticas que encontré útiles en el pasado para defenderme de las sugerencias inviables. En general, encuentro que tengo mucho mejores resultados con la "venta suave" y trato de ser agradable y accesible explicando mi razonamiento y aplazando en lugar de rechazar ideas.
Se me ocurrió una respuesta más estricta a tu pregunta. Lo trataría como una respuesta de "qué no hacer", pero si desea deshacerse de los disputantes, puede intentar:
Este es el desafío cuando estás ejecutando tus propios proyectos. Debido a que tiene una visión y conoce su producto de adentro hacia afuera, es más difícil traducir la visión que tiene en términos que otras personas puedan entender. Mi sugerencia es tomarse el tiempo para traducir lo que los desarrolladores están creando en términos que describan el resultado final. De esa forma, Marketing y Operaciones pueden alinear sus esfuerzos con lo que se hará realidad.
La clave es separar los requisitos del usuario de la entrega técnica. Usted afirma que lo que quiere es similar a lo que quieren marketing y operaciones, por lo que parece que el lado de los requisitos del usuario no es un problema para usted: todos quieren lo mismo, más o menos.
Entonces, el verdadero desafío es mantener a los gerentes de marketing y operaciones enfocados en el "qué", en lugar del "cómo". Tienes la propiedad técnica: tienen cierta influencia comercial. Un enfoque que he usado con éxito en el pasado es algo así como: "No entremos en los tecnicismos de cómo se desarrollará esto. Ofreceré la capacidad de hacer lo que desee, y también le daré cierta flexibilidad para agregar o cambiar la funcionalidad en el futuro. Seguramente no querrás que comprometa la capacidad futura solo para ahorrar unos días ahora, ¿verdad? Es posible que deba pensar en un par de áreas en las que pueden querer cambios futuros, solo para poner esto en contexto, pero funciona.
Personalmente, en primer lugar, priorizaría cuáles son las necesidades reales que permiten al cliente tener éxito frente a cuál es la visión del producto encerrada en la estrategia de la empresa.
Tal vez, de hecho, una API ayudaría y es un excelente avance tecnológico, pero ¿realmente proporciona valor hoy en día?
Hay muchos "marcos" de priorización o filtrado, como WSJF propuesto en SAFe. Moscú es otro.
Si desea obtener la "aprobación" para realizar las funcionalidades técnicas, insértelas en el "funcional". Asegúrese de que lo funcional sea el objetivo, mientras que lo técnico sea el medio para lograrlo.
jmort253
Bartosz Rakowski