¿Es normal que un gerente de producto no tenga una función para administrar durante cada sprint?

Vamos a descomprimir esto un poco:

  • Si no tiene funciones para administrar durante un LANZAMIENTO completo, entonces algo parece estar muy mal. Tal vez estás EOL’ing / Sunseting tu producto, y todo lo que queda por hacer es la corrección de errores. De lo contrario, los lanzamientos completos dedicados a la reducción de la deuda tecnológica y el trabajo de calidad son raros, y una invitación a competidores o nuevos participantes para robar participación de mercado. El análisis de Kano (modelo de Kano) nos dice que deberíamos tener al menos una función interesante en cada lanzamiento, aunque solo sea para darles a nuestros equipos de ventas / marketing algo de qué hablar.
  • Cada sprint debe tener algunas historias de usuario para completar, incluso si no completan una característica completa (épica). Idealmente, todavía hay progreso demostrable en historias que puede ver / tocar / apreciar / alabar a su equipo. Entonces, si bien a menudo es cierto que algunos sprints no completan una función completa del cliente, debe participar en un trabajo real y una aceptación real de cada sprint a medida que avanza hacia características completas.
  • Puede estar pensando en “características” de manera muy limitada. Deberíamos incluir todo lo que los clientes finales (o compradores) consideren realmente valioso. Eso podría incluir mejoras de rendimiento, mejor UX / flujo de trabajo, correcciones para errores visibles de P1, importación de datos más simple, etc. La mayoría del trabajo en cada sprint debe estar en cosas que los clientes finales se preocuparán y notarán y valorarán directamente.
    En productos muy grandes o en compañías muy grandes, los gerentes de producto pueden “poseer” secciones mucho más pequeñas de productos o servicios. Por ejemplo, si usted es el gerente de producto para la incorporación de nuevos clientes para un sitio de comercio electrónico, sus “características” podrían ser principalmente un mejor flujo de inicio de sesión, un número reducido de elementos de datos requeridos, errores más claros y textos de advertencia, o la traducción a 4 idiomas nuevos .
  • Estaría muy preocupado si varios sprints completos se dedicaran por completo a la reducción de la deuda tecnológica, la refactorización, la corrección de errores, las mejoras en el script de prueba y otros trabajos “meta” que son de valor a largo plazo para la capacidad del equipo de hacer más trabajo, pero sin valor directo para los usuarios finales o compradores / selectores. Es como un equipo de desarrollo que está anulando las decisiones de un gerente de producto, a menos que su producto tenga una reputación de tan baja calidad entre los clientes que esté perdiendo un gran número de ellos frente a sus competidores, específicamente debido a una mala calidad. (Y me gustaría validar eso DIRECTAMENTE CON ANTIGUOS CLIENTES en lugar de, por ejemplo, escucharlo solo de los ingenieros de soporte o ventas).

Finalmente, desempaquetemos “administrar” por un momento. Si tiene una gran confianza y comunicación con su equipo, ellos entienden profundamente el contexto de las características, y ha estado compartiendo incansablemente los comentarios del mercado / cliente … entonces es posible que no tenga que “administrar” mucho las historias de los usuarios o las características más pequeñas. Quizás tu equipo pueda llegar allí solo con una ligera dirección tuya. O escribir muchos de sus propias historias. Siéntase libre de revisar su ego en la puerta (su necesidad de ser deseado o de manejar las cosas) y deje que hagan un gran trabajo. Es posible que deba “administrar” solo un poco, ocasionalmente.

La situación más feliz es si puede reunir a las personas más inteligentes de su equipo extendido (¿arquitecto, líder de prueba, comercializador de productos, SE inteligente?) Y hacer que todos lleguen de manera colaborativa a grandes soluciones o descripciones o respuestas de características, y entregarlas al equipo para construir. Si es así, no intervenga y sobregestione solo porque ese trabajo aparece en el título de un gerente de producto.

No diría que lo que está haciendo está cerca de cualquier práctica de gestión de productos. Por lo que puedo leer, no tiene sentido hacerlo de la forma en que su empresa construye el producto.

Un equipo de producto debe trabajar en un área específica. Todavía podría ser que todos ustedes estén trabajando en el mismo producto per se, pero en diferentes áreas del producto con su propia visión y objetivos.

Lo que quiero decir es que un equipo puede trabajar en el back-end de un producto y uno puede trabajar en el front-end de un producto, pero debe haber una diferencia para que cada equipo de producto no sea demasiado dependiente entre sí y pueda entregar de forma continua por sí mismos.

Tomemos Facebook como ejemplo, ya que lo más probable es que lo use. Podría haber un PM cada uno manejando la búsqueda, el suministro de noticias, las páginas de la compañía, la línea de tiempo, los mensajes, la plataforma central, etc. Estas son solo mis conjeturas de cómo se vería en FB.

Un equipo de producto generalmente consta de lo siguiente

  • Gerente de producto
  • 4-7 ingenieros
  • QA
  • UX (si es un producto frontal)

Este equipo debe tener una gran cantidad de autonomía para poder trabajar hacia la visión del equipo.

La visión del equipo proviene del primer ministro. Esta visión debe estar alineada con la visión y los objetivos de la compañía también. Cuando tenga una visión, será más fácil establecer objetivos para el equipo con lo que desea lograr, por ejemplo, seguir ciertos KPI como la satisfacción del cliente, los ingresos o lo que sea que usted, como PM, considere lo suficientemente importante como para medirse.

Espero que esto te ayude.

Diría que es muy anormal tener un equipo en el que el PM se centre en las cosas desde un nivel de característica, de modo que no puedan tener una característica para administrar cada sprint. Se supone que los PM deben administrar productos , no características. Nunca he visto un equipo con una proporción de 1: 1 entre los PM y los desarrolladores; eso parece terriblemente sobrecargado desde una perspectiva de PM.

La mayoría de las personas que responden a esta pregunta parecen haber llegado desde una perspectiva de un PM. Estoy pensando en esto, ya que se ajusta a tu papel en un equipo de PM.

¿Cuántos PM hay? algunos pueden estar más comprometidos con la creación de características, otros en otras actividades como apoyar a los clientes durante un programa beta para recopilar comentarios, trabajar en alguna asociación o buscar preguntas a más largo plazo con marketing de productos y arquitectos.

El trabajo tiene muchos aspectos: correr a toda velocidad y presentar la característica del mes no es todo el trabajo.

1-PM a 1-Engineer es una relación muy pobre. He encontrado que la proporción óptima es de 1: 7, donde siete incluye principalmente ingeniería y un diseñador. Los sprints mensuales también son demasiado largos: deberían ser dos semanas (o menos). Cada sprint debe tener un código de trabajo que sea liberable para los consumidores. Cuanto más espere para entregar a los consumidores, estará expuesto a un riesgo de uso cada vez mayor (su software es útil y valioso).