¿Qué es un product manager?

Ningún viento es favorable para quien no sabe donde va- Séneca

c

Llegan peticiones para tu producto, contradictorias y por distintos canales (llamadas, emails, foros, ideas, visitas). El departamento comercial sentencia que debemos tener una funcionalidad para vender, el departamento técnico descubre la idea que nos hará vender mucho y cada 15 días las prioridades cambian, es hora de pensar en un product manager full time.

En Visual MS, tenemos 2 divisiones que tienen un product manager full time, Visual Trans y Velneo, cuando superas los 100 clientes, 15 empleados y 1 Millón de ingresos es hora de pensar en un product manager full time.

Antes de tener product manager el director técnico y el CEO desempeñan sus funciones.

Un product manager es lo más parecido a un CEO de producto, es el responsable de escuchar todas las peticiones y marcar el rumbo del producto manteniendo el equilibrio entre la parte técnica, negocio y clientes.

Tras leer The Hard Thing About Hard Things me animé a preparar esta tabla sobre buenas y malas prácticas de un product manager que extraje del fabuloso libro de Ben Horowitz.

.

Buenas prácticas Malas prácticas
Conoce los contextos del producto ( empresa, ingresos, competidores) y toma la resposabilidad para diseñar y ejecutar un plan ganador del producto sin excusas. Muchas excusas, nos falta dinero, nos falta equipo, lo programadores no son buenos. Oracle es mucho más fuerte que nosotros y tiene más recursos. Tenemos mucho trabajo.
No programa, no se meten en cosas que no le corresponden, no es parte del equipo de desarrollo. Se pone a programar, a proteger al equipo de desarrollo, son asistentes de los programadores, se meten en partes de la empresa que son exclusivas del producto.
Son el departamento de marketing del equipo de desarrollo. Considera peyorativo el término “Marketing” y “Ventas”.
Defefine el “Que” se va hacer y no el “Como”. Se siente mejor cuando define el “Como” se hacen las cosas
Crea recursos para “ventas”, FAQ, presentaciones, demos, páginas de novedades, vídeos. Se queja del “poco” nivel de la gente de ventas, les parece un fastidio estar contestando a las dudas de “ventas” y se centra en crear recursos para el equipo de desarrollo.
Se anticipa a los problemas futuros del producto. Se anticipa a los defectos del software. Se pasa el día de incendio en incendio, en reuniones tensas con los clientes.
Toma posiciones y decisiones en aspectos claves por escrito. (Arquitectura, Decir NO, mercado al que nos dirigimos, ..) No se posiciona, se lamenta, mejor que no ocurra, por qué pasan estas cosas. Después de que se produzca un problema te dirá “esto ya lo avisé yo”.
Foco en el equipo, ingresos y clientes. Foco en nº de funcionalidades que tienen los competidores y peticiones de clientes.
Define buenos productos que pueden ser ejecutados con buen rendimiento, estabilidad y escalabilidad. Define buenos productos que después dan problemas en producción y deja al equipo de desarrollo hacer lo que quiera.
Piensa en términos de aportar valor para el mercado y miden los impactos reales en los ingresos. Confunde términos como valor, precios, cosas que molan y que se venden.
Descompone los problemas. Combina problemas.
Piensa en la noticia y el titular. Piensa en cubrir features y hablár técnicamente.
Vuelve a explicar lo que ya está claro. Nunca explican lo obvio.
Define su trabajo y su éxito. Espera que les digan lo que tiene que hacer.
Siempre envía los informes antes de la fecha, son disciplinados y ordenados. Siempre está muy liados y no acaba sus tareas.
Ejerce de CEO de producto Ejerce de CEO de empresa, arquitecto, director técnico.
This entry was posted in Uncategorized and tagged , , , . Bookmark the permalink.