Lo que nadie te dice sobre ser Product Manager
Por Ramiro Castro
Ramiro Castro es uno de los referentes en Product Management y Product Growth en Latam.
Fue parte del equipo de Growth en MURAL, donde ayudó a escalar el negocio de ~$12M ARR a más de $115M ARR, multiplicando la base de usuarios 15x.
En este guestpost comparte algunos de sus aprendizajes.
Hay cosas que se repiten mucho entre las personas que trabajan en Producto.
Una agenda que no da más. El estrés por las nubes. Un roadmap de un año entero… y aun así no saben qué es lo más importante para mañana.
Todo el mundo pide cosas. Ventas. Marketing. El CEO. Operaciones. Ingeniería.
El Product Manager está en la intersección entre negocio, tecnología y usuarios.
Es una posición central que se convierte rápidamente en fricción: demasiadas prioridades, demasiadas expectativas y poco foco.
Tantos años trabajando en producto me han dejado claro algo: si no tienes criterio, te conviertes en el cuello de botella de la organización.
Tu meta: ser un puente estratégico que traiga resultados dinámicos.
En este artículo vas a encontrar, mis mejores consejos para Product Managers.
8 cosas que separan a un PM promedio de uno excelente
#1 Si solo entregas features, no estás haciendo producto
Muchos se enfocan en “qué tan rápido puedo mover tickets”.
La realidad es que puedes estar todo el día refinando backlog, priorizando en Jira, pasando tareas de “To Do” a “Done” y cumpliendo sprints…y aun así no mover ninguna métrica que importe.
Pero el punto no es cuántas cosas lanzas. Es si cada cosa que lanzas crea valor en al menos uno de estos tres frentes:
negocio (revenue, costos, eficiencia)
usuario (dolor resuelto, adopción, retención)
sostenibilidad (lo podemos mantener sin romper el sistema)
Si no mueve nada medible en alguno de esos vértices, no es prioridad.
Es ruido.
Y acá viene lo más incómodo:
Cada feature innecesaria agrega complejidad permanente. Es una carga que alguien va a pagar a futuro.
Ser PM no es producir más. Es elegir mejor. Tener criterio.
#2 Más capacidad no arregla una mala estrategia
Cuando un equipo está colapsado (lo que es muy común en producto), la reacción automática es: “Necesitamos más ingenieros.”
Casi nunca es verdad.
Más capacidad sin foco solo produce más cosas irrelevantes más rápido. El caos escala con el headcount.
El síntoma clásico es un roadmap lleno por 12 meses, pero cada semana todo cambia porque “todo es urgente”.
Eso no es falta de capacidad. Es falta de decisión.
El verdadero rol del PM es usar el “no” como herramienta estratégica.
Decir “no” no es fricción. Es cuidado.
Cuidas:
el foco del equipo
la energía
la claridad
y la métrica que realmente importa
Decir que sí a todo es una forma elegante de delegar responsabilidad.
Un PM sólido no vacía listas. Define qué iniciativa tiene el mayor potencial de mover la métrica principal y elimina el resto.
Si todo es prioridad, nada lo es.
Tu valor no está en cuánto construye tu equipo. Está en qué eliges que no construyan.
Si te sentiste identificado con esto de “roadmap lleno, cero foco”, no es falta de capacidad. Es falta de criterio.
En Product Rockstar trabajamos justo ese músculo: priorizar con intención y conectar lo que construyes con métricas que importan.
Tres semanas para dejar de empujar features y empezar a mover outcomes.
Si quieres formar parte de la siguiente edición de este programa, no dudes en aplicar (cupos limitados).
#3 Las métricas de vanidad son cómodas porque no te obligan a decidir
Puedes construir algo, y nunca sabrás si es brillante o no, a menos de que elijas la métrica correcta.
Las métricas de vanidad son peligrosas porque te dan dopamina sin decirte la verdad:
downloads
clics
adopción superficial de un feature
Se ven bien en slides, pero te dicen nada sobre el progreso del usuario.
No es:
“¿Cuánta gente usó esto?”
Es:
“¿Esto ayudó al usuario a resolver el problema por el cual vino?”
La gente no usa tu producto por curiosidad. Lo paga para avanzar en algo. Si no mides ese avance, estás optimizando el ruido.
Yo encontré que hay que evolucionar de métricas lentas a métricas accionables.
Revenue y Retención por sí solas son importantes… y lentas.
Un buen PM las descompone.
Si quieres mover revenue, ¿qué tiene que hacer el usuario primero para que eso suceda?
Si quieres mover retención, ¿qué acción temprana predice que alguien volverá?
Cuando conectas la métrica de negocio con una métrica de comportamiento específica, tu equipo deja de trabajar en features y empieza a trabajar en outcomes.
Y ahí cambia todo.
#4 No hay que hacerle caso al usuario
Tu producto no es una lista de features. Es el empleado de tu cliente.
El usuario lo “contrata” para progresar en algo específico. Si no cumple esa misión, lo despide.
Jobs to be Done cambia una cosa fundamental:
Confundir lo que el usuario pide con lo que realmente necesita.
Un usuario puede pedir: “Agreguen esta función.”
Pero esa función es solo una hipótesis.
Tu no tienes que cumplir el pedido. Tienes que entender qué progreso está intentando hacer esa persona.
Si no identificas el “job”, terminas optimizando botones, no resultados.
Esto cambia contra quién compites.
No compites contra el que tiene tu mismo feature set. Compites contra cualquier alternativa o sustituto que permita al usuario lograr el progreso por el que te pagan a ti.
Cuando mides progreso, la conversación empieza a ser sobre valor.
Y ahí sales de la feature factory.
#5 No definas estrategia sin leer el risk appetite
Un PM no opera en el vacío.
Puedes tener el mejor plan del mundo, pero si no está alineado con el apetito de riesgo de tu CEO, vas a generar fricción innecesaria.
Producto no es solo decidir qué construir. Es decidir cuánta incertidumbre está dispuesto a absorber el negocio.
Proponer el mismo tipo de roadmap en cualquier empresa. Grave error.
Hay compañías que quieren crecimiento agresivo, apuestas grandes, experimentar aunque algo falle.
Y hay otras quieren estabilidad, previsibilidad, proteger métricas críticas.
Si propones disrupción en una empresa conservadora, pareces imprudente.
Si propones incrementalismo en una empresa que necesita explotar, pareces lento.
No es un problema técnico. Es un problema de lectura del contexto.
Antes de definir el objetivo del trimestre, pregunta esto al líder estratégico:
“Cuál es el nivel de riesgo que estamos dispuestos a asumir?”
Un PM maduro no solo propone iniciativas. Diseña un portafolio coherente con la ambición real del negocio.
#6 Deja de buscar hacks o “best practices”
Producto no es una receta. No es una fábrica donde si repites el proceso obtienes el mismo resultado.
Es un sistema en el que dependes de comportamiento humano, contexto, timing, competencia, cultura.
Lo que funcionó en Instagram no es una “mejor práctica”. Es una historia única que ocurrió en un contexto específico.
Copiar tácticas sin entender tu negocio es una forma de procrastinar pensar en tu estrategia.
Entonces, ¿qué sí funciona? Experimentar con intención.
No experimentar por ansiedad. No lanzar ideas al aire. Sino diseñar hipótesis alrededor de un problema claro.
Y aquí está el punto que casi nadie gestiona bien: No todo experimento debe ser “innovación loca”.
Un PM fuerte construye un portafolio balanceado:
Iniciativas de bajo riesgo donde sabes que hay fricción evidente (optimización real).
Experimentos más inciertos donde el upside puede ser grande.
Si todo es incierto, quemas al equipo. Si todo es optimización, te estancas.
El balance entre las dos depende del apetito de riesgo de la compañía.
En producto no gana quien copia mejor. Gana quien aprende más rápido sobre su propio problema.
#7 La regla del 55/5
55 minutos en el problema, 5 en la solución.
Tu cerebro está mal entrenado. Desde el colegio nos premiaron por responder rápido.
En producto, eso es un vicio peligroso.
El valor del PM no está en tener la respuesta más veloz. Está en identificar el problema correcto.
Escucho mucho “Necesitamos el botón X”.
Eso no es un problema. Es una solución forzada.
Habitar el espacio del problema significa preguntar (aunque incomode)
¿Qué comportamiento está roto?
¿Qué métrica está cayendo?
¿Qué está intentando lograr el usuario y no puede?
Si no puedes describir el dolor sin mencionar una feature, aún no entiendes el problema.
Si inviertes el tiempo (5 minutos en problema, 55 en solución),
construyes más cosas.
Si inviertes bien el tiempo (55 en problema, 5 en solución),
construyes menos…y mueves más.
#8 Producto es un problema complejo, no complicado
Ingeniería resuelve lo complicado. Tú navegas lo complejo.
Ir a la luna es complicado. Requiere expertos, precisión, conocimiento técnico. Pero una vez entiendes la fórmula, puedes repetirla.
Producto no funciona así. Producto es complejo.
No depende solo de sistemas técnicos. Sino de comportamiento humano.
Y el comportamiento humano no es lineal.
Puedes lanzar algo que “tiene todo el sentido del mundo”… y que nadie use.
No porque esté mal construido. Sino porque la gente no lo necesitaba como tú creías.
En problemas complicados: analizas, defines, ejecutas y repites.
En problemas complejos necesitas: hipótesis, experimento, observación y ajuste.
Recuerda, no hay recetas replicables. Hay probabilidades.
Un buen PM no busca certezas absolutas. Busca aumentar las probabilidades de impacto.
Tienes que asumir que probablemente estás equivocado.
Esa mentalidad cambia cómo decides, cómo priorizas y cómo lanzas.
Si quieres ser el PM que trae claridad (no más caos), este es el programa.
Product Rockstar inicia el 23 de marzo.
3 semanas para afinar criterio, priorizar mejor y elevar tu nivel operativo.
Si quieres entrar a esta edición, ya puedes aplicar aquí.
Te gustaría sponsorear este newsletter? Escríbenos a roberto@growthrockstar.com con el asunto “Sponsor”.
📚 Otras lecturas que pueden interesarte:
Si nuestro blog te agrega valor, compártelo con tus amigos y colegas. 👇
Saludos Rockstar!