Ningún viento es favorable para quien no sabe donde va. — Séneca
Llegan peticiones de 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 revolucionará el mercado 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 como un CEO de producto: es el responsable de escuchar todas las peticiones y marcar el rumbo del producto equilibrando 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 frente a malas prácticas
| Buenas prácticas | Malas prácticas |
|---|---|
| Conoce los contextos del producto (empresa, ingresos, competidores), toma la responsabilidad para diseñar y ejecutar un plan ganador del producto sin excusas. | Muchas excusas: nos falta dinero, nos falta equipo, los programadores no son buenos. Oracle es mucho más fuerte que nosotros y tiene más recursos. Tenemos mucho trabajo. |
| No programa, no se mete en cosas que no le corresponden, no es parte del equipo de desarrollo. | Se pone a programar, a proteger al equipo de desarrollo, es asistente de los programadores. |
| Es el departamento de marketing del equipo de desarrollo. | Considera peyorativo el término "Marketing" y "Ventas". |
| Define el "Qué" se va a hacer y no el "Cómo". | Se siente mejor cuando define el "Cómo" 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, le 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 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. 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 mide 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 hablar técnicamente. |
| Vuelve a explicar lo que ya está claro. | Nunca explican lo obvio. |
| Define su trabajo y su éxito. | Espera que le digan lo que tiene que hacer. |
| Siempre envía los informes antes de la fecha, son disciplinados y ordenados. | Siempre está muy liado y no acaba sus tareas. |
| Ejerce de CEO de producto. | Ejerce de CEO de empresa, arquitecto, director técnico, programador, etc. |