3 cosas que debe evitar decir como Gerente de Producto

May 09 2022
¿Alguna vez te quedas despierto por la noche pensando en algo tonto que dijiste y deseando poder retractarte? He hecho esto mucho tiempo, a menudo en un contexto laboral y especialmente como gerente de producto junior. En este artículo, repasaremos tres escenarios en los que cometí errores de comunicación y luego revisaremos cómo podrían haber ido mejor para ayudarlo a evitar algunos errores comunes de PM.
Imagen de MemeCreator

¿Alguna vez te quedas despierto por la noche pensando en algo tonto que dijiste y deseando poder retractarte? He hecho esto mucho tiempo, a menudo en un contexto laboral y especialmente como gerente de producto junior.

En este artículo, repasaremos tres escenarios en los que cometí errores de comunicación y luego revisaremos cómo podrían haber ido mejor para ayudarlo a evitar algunos errores comunes de PM. ¡Hagámoslo!

1. Decir sí de inmediato

Aquí hay una conversación que recuerdo de mi primer mes como nuevo gerente de producto:

CEO: Hola, John, recientemente estuve pensando en nuestro embudo de incorporación y creo que todas nuestras nuevas suscripciones deberían ver un video para que entiendan cómo usar nuestro producto. ¿Puedes trabajar en esto por mí?

Yo: *oh, Dios mío, es el director ejecutivo* Sí, eso suena como una gran característica. Me pondré a trabajar en ello ahora mismo y, con suerte, tendré algo para que pruebes en 2 semanas.

Después de la conversación, le dije a mi equipo técnico que dejara todo en lo que estaban trabajando y comenzara a crear una solución de incorporación de video. Pasaron 2 semanas y mi equipo estaba frustrado porque no habíamos hecho ningún progreso, me di cuenta de que tomaría algunos meses más para que algo funcionara. Regresé al CEO para contarle esto, y él dijo: “Oh, no tenías que construirlo ahora. Solo quería contarte mi idea.

¿Qué debería haber dicho en su lugar? Así es como repetiría la conversación con un par de años más de experiencia:

CEO: Hola, John, recientemente estuve pensando en nuestro embudo de incorporación y creo que todas nuestras nuevas suscripciones deberían ver un video para que entiendan cómo usar nuestro producto. ¿Puedes trabajar en esto por mí?

Yo: ¡Esa es una gran idea! ¿Puedo verificar si tenemos alguna evidencia de que nuestra incorporación actual es un problema? Además, solo para informarle, nuestro equipo está trabajando actualmente en la Función X. ¿Le gustaría que la descartáramos y le diera prioridad a esta?

CEO: Bueno, en realidad no he escuchado ninguna queja, solo pensé que era una buena idea. La característica X es más importante, definitivamente termine eso primero.

Lo que he hecho aquí es a) reconocer la idea, b) profundizar en el contexto y el problema, yc) pedirle al CEO que establezca prioridades. Resulta que este no es realmente un problema importante para resolver en este momento y nuestro equipo puede seguir completando nuestro trabajo existente.

Conclusión: no diga que sí a nada de inmediato antes de haber tenido la oportunidad de validar si está resolviendo un problema real . Incluso si viene del CEO.

2. Decir No inmediatamente

Recordando mi error anterior, pasé los siguientes meses enfocándome muy intensamente en nuestra hoja de ruta, lo que llevó a esta conversación:

Miembro del equipo de operaciones: Oye, escribí este documento sobre una idea para mejorar la retención de usuarios, básicamente podemos enviar correos electrónicos a:

Yo: (interrumpiendo) Lo siento, tenemos demasiado en nuestra hoja de ruta en este momento y, además, los correos electrónicos no son realmente responsabilidad de mi equipo.

Ops: Oh, está bien. Perdón por molestarte.

Imagen de MemeGenerator

Unos meses más tarde, la retención de usuarios surgió como un problema importante en la empresa. Pasé un tiempo investigando el problema y esbozando una solución, y revisé el documento que me había enviado un miembro de mi equipo. Describió casi el sistema exacto que yo estaba proponiendo. En este caso, las consecuencias no fueron tan drásticas (el enfoque casi siempre es algo bueno), pero vino con un costo de relación y un costo de oportunidad.

En los dos ejemplos que he dado hasta ahora, notará que mi respuesta inicial terminó la conversación. Esto suele ser un error, ya que se pierden detalles e ideas valiosos. Hacer preguntas es una excelente manera de aclarar el significado y extender la conversación; veamos cómo podría funcionar en este escenario.

Miembro del equipo de operaciones: Escribí este documento sobre una idea para mejorar la retención de usuarios; básicamente, podemos enviar correos electrónicos a usuarios que no han estado activos durante cierto tiempo.

Yo: Esa es una idea muy interesante, ¿por qué crees que marcará la diferencia?

Ops: Ya probamos con este correo electrónico manualmente y descubrimos que condujo a un aumento del 5% en la retención de usuarios. Para implementarlo por completo, necesitaremos el apoyo del equipo del producto para enviarlos automáticamente.

Yo: Esos son resultados bastante buenos, y me aseguraré de revisar tu documento. Solo un aviso de que mi equipo está ocupado con varios otros proyectos en este momento, pero lo discutiré con los otros equipos de productos y se lo haré saber.

Tenga en cuenta que todavía no he dicho que sí a esta idea, pero lo he reconocido y ahora tengo la oportunidad de revisarlo en el tiempo libre. Al hacer preguntas y estar abierto a las ideas, construye una comprensión mucho más profunda de su campo y es más probable que encuentre soluciones efectivas. Esta también es una buena manera de construir relaciones en toda su organización, lo que siempre es útil: como PM, depende constantemente de otras personas para hacer las cosas.

3. Dar tareas, no contexto

Un error final es uno que todavía cometo a menudo, especialmente cuando me siento ocupado o apurado por el tiempo. En este caso, estaba tratando de averiguar de dónde venían nuestros nuevos registros:

Yo: Hola analista, ¿puede estimar qué porcentaje de los registros de nuestra aplicación encontraron nuestro sitio web en la Búsqueda de Google?

Analista: Mmm, es complicado porque son diferentes fuentes de datos. ¿Cuál es la cantidad máxima de tiempo desde que se ve el sitio web hasta que se instala la aplicación que contamos como una conversión válida?

Yo: No sé, ¿24 horas tal vez?

Analista: ¿Qué pasa si alguien usó diferentes dispositivos?

Yo: *Dios, esto se está poniendo complicado*...

Imagen de makeameme

Continuamos de un lado a otro durante varios minutos y llegamos a una definición torcida pero funcional. Al presentarle estos datos a mi gerente más tarde, dijo: “Pero, ¿por qué se te ocurrió esta estimación completamente nueva? Solo preguntamos a los nuevos usuarios de dónde vienen durante el registro”.

Esto es lo que se conoce como un problema XY , lo que significa que el usuario final solicita una solución al problema X, que en realidad es causado por el problema Y. En este caso, no compartí por qué necesitaba los datos o qué problema tenía. tratando de resolver, lo que significa que perdimos el tiempo en algo equivocado.

Brindar contexto por adelantado hace que sea más fácil para otros ayudarlo porque dedican menos esfuerzo a descubrir lo que realmente quiere. Incluyamos eso y veamos cómo va la conversación:

Yo: Hola analista, estoy tratando de averiguar de dónde provienen nuestros usuarios para que podamos ayudar a nuestro equipo de marketing a priorizar su presupuesto en diferentes canales. ¿Podría decirme qué información tenemos sobre las fuentes de registro de la aplicación y cómo podemos estimarla?

Analista: Claro, le pedimos a las personas esa información directamente durante el registro; aquí hay un tablero existente.

En este caso, obtuve lo que necesitaba más rápidamente porque compartí más sobre mi objetivo subyacente. Hacer la solicitud abierta y pedirle a la otra persona que piense en posibles soluciones también aprovecha su creatividad. Si solo eres un creador de tareas, tu equipo estará limitado por tu propia comprensión e imaginación.

Conclusión

Lo que une a muchos de estos ejemplos es que fueron causados ​​por una falta de consideración en la comunicación. Como personas normales, nos comunicamos de forma apresurada todo el tiempo y está bien. Sin embargo, el listón para los gerentes de producto es mucho más alto, porque la comunicación es literalmente el 90 % del trabajo. La buena comunicación requiere tomarse el tiempo para escribir (o decir) una respuesta reflexiva que tenga en cuenta a la otra persona y la situación en cuestión. Y puede convertir un conjunto confuso de personas que construyen características aleatorias en un equipo energizado que resuelve problemas reales.

Me ha resultado útil pensar en la comunicación como una habilidad difícil para los PM, lo que significa que a) se puede cuantificar yb) se puede enseñar. Al no decir que sí a nada de inmediato, hacer preguntas, estar abierto a las ideas y compartir el contexto, está bien encaminado para convertirse en un gerente de producto más efectivo.

Bono: lectura recomendada

Si está interesado en aprender cómo mejorar sus habilidades de comunicación, vea mis dos libros favoritos sobre el tema a continuación. Como ocurre con todos los grandes libros, sus lecciones se pueden aplicar en muchas áreas de su vida.

  1. Cómo ganar amigos e influir en las personas de Dale Carnegie
  2. Conversaciones difíciles de Douglas Stone y Sheila Heen

© Copyright 2021 - 2022 | unogogo.com | All Rights Reserved