El otro día me preguntaron qué significa ser “Product Manager (PM)”.
Supongo que es un cargo que existe en varias industrias porque si googleas “Product Manager Chile“. Te salen resultados para trabajar en retail (tipo venta de zapatos), como también en empresas tecnológicas.
En fin, conozco el PM que se encarga de productos digitales. Es alguien con background técnico, enfocado en el usuario. Que trabaja codo a codo con ingenieros y diseñadores para guiar productos.
Los Product Managers entienden las métricas, planean el roadmap, conocen las debilidades y fortalezas de su producto. Y tienen una visión de lo que entregaría un producto 10x.
Entender al usuario
El arma secreta de un PM es entender muy bien los problemas de los usuarios. Onda tiene que sufrir con ellos, transpirar, oler la frustración y enojo. Y detectar por qué el usuario está dispuesto a sufrir tanto para tratar de lograr algo con el producto (o la falta del mismo).
La clave está en no enamorarse de la solución. A cualquiera le pasa, empiezas a engendrar un cariño por tu creación. Pero es un error grave para un PM, porque limita su forma de pensar en cómo conseguir la mejor solución al problema que se está resolviendo.
Priorizar qué hacer primero
También tiene que entender qué es más importante y priorizar los problemas a resolver. Tampoco es tan obvio. Seguro tiene amigos usando el producto y lo llaman por teléfono: “… sería bacán que le pongai eso compadre, onda le serviría a todo el mundo…”.
Tiene que decirles que no. Creo que es más fácil sacarse la culpa al usar frameworks (como el RICE) para priorizar. Así no sale tan difícil decir que “no”.
Agregar más cosas expande el alcance del producto, normalmente con un tremendo marketing splash y algo de prensa. La conmoción atrae nuevos clientes y nuevos casos-de-uso para el producto.
Ojo, nuevas funcionalidades son riesgosas. Osea el PM tiene que estar muy confiado de que serán valiosas para el usuario, porque éstas son como niños: tienes que mantenerlas sin importar lo que pase.
Darle forma a la solución
Después viene “shapear” una solución -como decimos en Chipax-. El ideal es que la solución se pruebe con usuarios reales antes de construirla, porque ahí salen un montón de detalles que normalmente no te das cuenta con el plumón en la mano (haciendo fat-marker sketches). Además sale mucho más barato borrar en el pizarrón que cambiar el producto una vez que fue publicado.
Por eso es tan importante que un PM sepa trabajar con diseñadores, porque tiene la capacidad de transmitir ideas abstractas en soluciones físicas en un papel. Luego el diseñador le ayuda a pulir y construir un prototipo.
Medir el impacto
Por supuesto que habrá iteraciones posteriores, el PM no puede esperar hacer puros home run con las publicaciones de producto que haga con su equipo. Seguro hay más de un error (o bug), un mensaje mal redactado o un botón que no hace nada…
Pero pienso que las iteraciones se dan más por querer mejorar la solución. Es común que luego de publicar nadie la usó, pero no necesariamente porque no sea valiosa, sino porque no se pensó bien la forma en que el usuario la descubre.
La clave está en medir lo que importa.
Es por eso que el PM debe tener un fuerte vínculo con el negocio, porque es clave que haga proyectos alineados con los objetivos principales y que pueda medir el impacto en ellos. Sino, ¿cómo sabe que lo está haciendo bien?
Lo que no es un Product Manager
Piensan que ser Product Manager es como lo que sale en A Beautiful Mind, donde están sentados en un parque escribiendo sus innovaciones en una ventana. O que poseen una intuición de producto tipo Steve Jobs, donde las decisiones son fáciles y la influencia es gratis. Nada de esto es verdad 🙄
Si miras cómo trabajan Product Managers en cualquier empresa, hay un montón de nitty gritty work. Mucho planillas, wireframes, Google docs, emails y oh so many Slack channels. Todo esto existe para analizar, colaborar, influenciar y documentar el consenso de la dirección que lleva el producto. Casi que se debería llamar “Direction and Consensus Manager” (pero no llegarían tantos postulantes).
Por eso para PM nos encantan las personas analíticas, detallistas, amistosas, empáticas y capaces de manejar muchos temas al mismo tiempo. Entregan resultados y cumplen objetivos.
Es ideal que vengan de un background técnico (saben programar y entienden el tiempo que cuesta hacer un software bacán sin errores). Si no sabe cómo programar, sería bueno que aprenda.
También suma mucho si ya ha shipped something out the door -como dicen los gringos-.Supondría que está literal “conectado” al mundo tech y le gusta probar cada cosa nueva que sale. Le gusta usar el nuevo 🎁 de Slack, le gustan los productos bien hechos y bonitos y lee Product Hunt.