Ves el problema. El botón está en el lugar equivocado, el flujo tiene una trampa oculta, la feature de exportar pierde a la gente que más la necesita. Lo planteas. El PM asiente, dice "buen punto, déjame revisar el roadmap". Seis meses después, nada cambió. Al día siguiente, encuentras cinco tickets nuevos sobre el mismo problema.
Esta es la realidad diaria de diseñadores, ingenieros, leads de soporte y analistas en la mayoría de organizaciones de producto. Ven issues que el PM no. No pueden simplemente ponerlos en el roadmap ellos mismos. La habilidad que cierra el gap es influencia sin autoridad, y tiene movimientos sorprendentemente específicos. Este artículo destila lo que funciona, construyendo sobre la pieza de Tanya Donska en Mind the Product.
El error core que cometen los no-PMs
El instinto es abogar por el problema en tu propio lenguaje. Los diseñadores describen violaciones de UX. Los ingenieros describen deuda técnica. Los leads de soporte describen patrones de tickets. Los analistas describen anomalías de métricas. Todos certeros. Ninguno suena como un problema de roadmap a un PM que está balanceando 30 peticiones competidoras en términos de negocio.
La traducción que funciona es mover el problema del lenguaje de tu función a una métrica de negocio que el PM ya está trackeando. Una vez vive en su mundo, compite por prioridad en términos familiares.
Movimiento 1: Traduce el problema a métricas de negocio
El patrón
Toma tu observación y exprésala como un coste u oportunidad que mapea a algo en lo que el PM es medido. El mismo problema expresado de dos formas:
| Tu lenguaje | Lenguaje del PM |
|---|---|
| El botón de exportar es difícil de encontrar | Los usuarios pasan 4 minutos intentando encontrar exportar. Por 1.200 usuarios semanales, eso son 200 horas desperdiciadas al mes y aproximadamente 12% de riesgo de churn en el segmento |
| El flujo de reset de password está roto | El reset de password falla el 22% de las veces. Cada fallo genera un ticket de soporte que cuesta 7 minutos de tiempo de soporte. 1.200 tickets al mes equivalen a 140 horas de soporte |
| El empty state del dashboard es confuso | Los usuarios nuevos que ven el empty state churnan a 3x la tasa de los usuarios que alcanzan el estado poblado en la semana 1 |
El esfuerzo de traducción es lo que desbloquea la conversación. El PM no puede decir no a un número que conecta con sus metas.
Movimiento 2: Encuentra las métricas que ellos ya están vigilando
Antes de llevar un problema a un PM, descubre cuáles son sus prioridades actuales. Tres fuentes:
- Sus OKRs trimestrales (normalmente compartidos internamente)
- Las métricas que citan en reuniones de roadmap
- Las quejas de sus stakeholders que han repetido últimamente
Si están enfocados en activación, enmarca tu problema como bloqueante de activación. Si están enfocados en retención, enmárcalo como riesgo de retención. Si están enfocados en cost-to-serve, enmárcalo como coste de soporte. El mismo issue subyacente normalmente puede enmarcarse para encajar con la prioridad actual.
Movimiento 3: Haz que arreglarlo sea más barato que ignorarlo
Los PMs hacen cálculos mentales de coste-beneficio en cada petición de roadmap. La forma más rápida de perder es presentar un problema sin estimación del coste de arreglarlo. La forma más rápida de ganar es venir con un scope de solución que parezca pequeño.
La adopción llegó al 68% en tres meses tras rehacer la navegación. Esa es la clase de evidencia que mueve roadmaps.
No necesitas saber el coste real de ingeniería. Necesitas hacer el caso de que el coste de no arreglarlo es mayor que cualquier arreglo plausible. Si también puedes sugerir una primera versión de scope pequeño ("podríamos probar mover el botón sin rediseñar la página"), la petición pasa de "otra petición grande" a "experimento de bajo coste".
Movimiento 4: Ofrece el arreglo más pequeño posible primero
La trampa clásica de los no-PMs abogando por arreglos: describen la solución ideal, que es grande. El PM la añade mentalmente a la lista multi-trimestral y la olvida.
Reenmárcalo como la versión más pequeña que probaría si el arreglo importa. Un movimiento de botón. Un cambio de copy. Un A/B test simple. Si la versión pequeña muestra impacto, la versión más grande se vuelve más fácil de justificar. La mayoría de arreglos entran al roadmap como experimentos pequeños, no como features completos.
Movimiento 5: Saber cuándo perdiste y qué hacer en lugar
No todo esfuerzo de abogacía tiene éxito. A veces la prioridad simplemente no es la tuya. Tres respuestas que preservan influencia futura:
- Aceptación elegante. "Entendido, tiene sentido dado todo lo que compite. Voy a seguir recolectando datos sobre esto; avísame cuando pueda volver a entrar". Quemar una relación para ganar una pelea cuesta todas las peleas futuras.
- Documenta la evidencia. Incluso cuando la respuesta es no, registra los datos que trajiste. Seis meses después, cuando el problema haya crecido, tu abogacía previa con evidencia es lo que hace que el segundo intento aterrice.
- Encuentra el camino alternativo. Si el roadmap no se va a mover, ¿puedes arreglarlo en tu función? Un diseñador puede enviar una pequeña mejora de UX en una release existente. Un ingeniero puede incluir un arreglo en una refactorización. El roadmap no es el único canal.
Qué no funciona (y por qué seguimos intentándolo)
- Repetir el problema más fuerte. Si el framing no aterrizó la primera vez, la repetición no ayuda. Cambia el frame.
- Ir alrededor del PM a su manager. Ganas esta ronda, pierdes todas las futuras.
- Frustración personal en el mensaje. "Sigo trayendo esto y nada pasa" se lee como problema de relación, no problema de roadmap.
- Citar otras empresas que lo resolvieron. Útil como contexto, inútil como argumento principal. A los PMs les importa su producto, no las empresas benchmark.
- Mostrar el diseño o el detalle técnico. Guarda esto para la conversación de implementación. La conversación de abogacía es sobre el caso de negocio.
El efecto compuesto de hacer esto bien
Los no-PMs que aprenden a abogar efectivamente se vuelven la gente que el PM busca para input. La relación cambia de "alguien trayéndome problemas" a "alguien cuyos problemas valen mi atención". A lo largo de un año, esto significa:
- Tus insights dan forma al roadmap consistentemente, no ocasionalmente
- Te invitan a conversaciones de producto en etapas más tempranas
- Tu crecimiento de carrera se acelera porque te ven como estratégico, no solo táctico
- El producto en sí mejora porque la señal de planta baja llega a la capa de decisión
Para llevar
No necesitas autoridad para influir en el producto. Necesitas traducción. Toma el problema que ves, exprésalo en el lenguaje de negocio en el que el PM es medido, encuentra la métrica que ellos ya están vigilando, haz que arreglarlo parezca más barato que ignorarlo, propón una primera versión pequeña y acepta elegantemente cuando la respuesta sea no. Hecho consistentemente, esto convierte observación de planta baja en cambios enviados. Sin esto, los mejores insights mueren en conversación mientras el producto acumula la fricción que nadie tuvo el framing para arreglar.
