La concepción errónea que muchos tienen sobre lo que significa ser Product Manager
La diferencia entre un PM promedio y uno excepcional no está en tener las mejores ideas, sino en su capacidad de validarlas antes de construir.
👋 ¡Hola! Te doy la bienvenida a esta edición de la newsletter de Product Rocks. Si aún no lo has hecho, te invito a unirte a la comunidad de Product Rocks, un espacio creado para profesionales que buscan crecer como Product Managers. Ahí podrás encontrar la Biblioteca de Producto (una colección gratuita de resúmenes de libros en español) y los eventos mensuales de la comunidad.
Imagínate una empresa donde un stakeholder se reúne con el equipo de producto para abordar un problema urgente. El engagement ha caído de forma constante en las últimas semanas y no está claro qué hacer. Es ahí cuando, desde el fondo de la sala, aparece el Product Manager. Pecho en alto, seguridad absoluta, como si estuviera a punto de dar la mejor solución que nadie ha escuchado antes. Sin dudarlo y sin que la voz le tiemble, dice:
–Implementemos el modo oscuro en la aplicación. Es algo muy importante hoy en día, y seguro va a mejorar el engagement. Yo lo uso en todas mis apps y me hace falta poder tenerlo acá.
El stakeholder pregunta:
–¿Tenemos información que soporte esto?
El PM responde con confianza:
–No es necesario. Yo tengo 5 años trabajando en este tipo de productos y conozco muy bien al cliente.
Sin más discusión, la funcionalidad se prioriza sin validación ni datos que la respalden. No hay experimentación ni hipótesis, solo una afirmación basada en la experiencia del PM. El desarrollo se estima inicialmente en un mes, pero se extiende primero por un mes adicional. Finalmente, tras otros dos meses de retraso, lanzan la funcionalidad.
El resultado es desalentador: nada cambia. El engagement continúa en caída libre, y lo que comenzó como un problema de semanas se convierte en meses sin que la métrica muestre signos de recuperación.
Pero el PM ni se inmuta. El tiene todo bajo control.
Con la misma seguridad con la que propuso la solución inicial, ahora dice:
–Es que los clientes no entienden la funcionalidad. Debemos implementar una funcionalidad que les explique el valor del modo oscuro.
Y así empieza un ciclo interminable. Se diseña una nueva funcionalidad para solucionar el problema de la anterior. Se asignan más recursos. Se gasta más tiempo. Se suman nuevas ideas. Pero nada mejora. No hay validación, no hay aprendizaje, solo una serie de soluciones basadas en suposiciones.
Lo peor es que este tipo de decisiones no solo hace perder meses de trabajo, sino que puede matar un producto, o a su equipo. Pero lo más peligroso es que este no es un caso aislado. Ocurre en muchas empresas, una y otra vez. La razón es simple: demasiados PMs creen que su trabajo es tener ideas y lanzar funcionalidades, cuando en realidad su trabajo es resolver problemas.
Ser PM no es ser el que tiene todas las respuestas
Uno de los errores más comunes sobre el rol de Product Manager es pensar que es la persona que tiene las mejores ideas. Que su trabajo es "saber" lo que el usuario necesita, tomar decisiones basadas en su criterio y liderar la ejecución con confianza absoluta. Pero esa mentalidad es peligrosa.
El problema con este enfoque es que convierte el desarrollo de producto en un ejercicio de ego en lugar de un proceso basado en datos, validación y aprendizaje continuo. Un PM no está ahí para ser el genio de la sala. Su trabajo no es imponer soluciones, sino encontrar las preguntas correctas y asegurarse de que el equipo tenga la información necesaria para tomar decisiones inteligentes. El mejor Product Manager no es el que dice "hagamos esto", sino el que dice "vamos a descubrir qué deberíamos hacer".
La principal responsabilidad de un PM
El trabajo de un Product Manager no es solo “gestionar un backlog”. Su responsabilidad principal es identificar los problemas más importantes y asegurarse de que, junto con el equipo, se encuentre la mejor manera de resolverlos. Y la clave está en descubrir, no en asumir. Muchos PMs cometen el error de decidir qué construir basándose solo en opiniones, intuición o presión interna de stakeholders. Este es el camino que lleva a invertir meses desarrollando algo que nadie usará. Un verdadero PM, en cambio, reduce la incertidumbre y valida las ideas antes de comprometer recursos.
En su libro Inspired, Marty Cagan explica esto brillantemente al señalar que todo producto enfrenta cuatro riesgos fundamentales que deben mitigarse antes de escribir una sola línea de código:
El riesgo de valor: ¿Los clientes encontrarán valor en la solución que construyamos? ¿La utilizarán? ¿Pagarán por ella?
El riesgo de usabilidad: ¿Los clientes entenderán cómo usarla? ¿Lograrán obtener el valor que esperamos?
El riesgo de factibilidad: ¿Podemos construir la solución? ¿Tenemos los recursos necesarios para hacerlo?
El riesgo de viabilidad: ¿Esta solución tiene sentido para el negocio? ¿Qué resultados esperamos alcanzar?
Estos riesgos deben abordarse antes de lanzar, no después, y hacerlo rápidamente. No puedes esperar a tener el producto terminado para descubrir que nadie lo necesita, que los usuarios no entienden cómo usarlo, o que la empresa no podrá mantenerlo.
Es como invertir dinero esperando un retorno. Todos sabemos que apostar en activos de alto riesgo puede ser muy rentable, pero también puede hacerte perder todo. Por eso existen analistas que estudian las inversiones antes de hacerlas. La gente que invierte dinero sin investigar suele perder.
Aquí es lo mismo, solo que el recurso no es dinero, es el tiempo de tu equipo. Y a diferencia del dinero, que se ve claramente cuando se gasta, el costo del tiempo mal invertido es más difícil de notar. Muy pocos PMs están a cargo del P&L del negocio, así que no ven directamente cuánto está costando cada mala decisión. Pero cuando entiendes esto, es evidente: hacer producto es una inversión y gestionar bien el riesgo es el trabajo. Así como no invertirías a ciegas en acciones sin investigar, acá tampoco deberías decidir en qué gastar meses de desarrollo sin validar primero. A menos, claro, que tengas recursos ilimitados y puedas darte el lujo de desperdiciarlos. Pero no conozco a nadie en ese escenario.
Y aquí está lo importante: reducir el riesgo no es un ejercicio teórico. No se resuelve desde el escritorio, ni en reuniones con stakeholders, ni se descubre en un workshop lleno de post-its. La única forma real de validar si una idea vale la pena es interactuando con clientes y experimentando. Necesitas salir, hablar con usuarios y probar hipótesis en el mundo real. Validar antes de construir, así de simple.
No hay atajos ni fórmulas mágicas. Si tomas decisiones sin salir a validar, lo único que estás haciendo es convencerte de que tienes razón en lugar de descubrir si realmente la tienes.
"El peor error que puede cometer un PM no es elegir la solución equivocada. Es nunca tomarse el tiempo de validar si lo que está construyendo realmente vale la pena.”
Si todavía necesitas una razón más para validar antes de construir, aquí la tienes: el 70% de las startups tecnológicas fracasan, y en la mayoría de los casos, no es porque ejecutaron mal, sino porque construyeron algo que nadie quería. Según un análisis de Statista basado en post-mortems de startups, la razón número uno por la que fracasan es porque su producto o servicio no resolvía una necesidad real de mercado. No se quedaron sin dinero. No fueron superados por la competencia. Simplemente construyeron algo que los usuarios nunca pidieron.
Si esto le pasa a startups enteras con millones de dólares en inversión, ¿qué te hace pensar que tu equipo es diferente? La validación no es opcional. Es la única forma de asegurarte de que no estás desperdiciando tiempo, dinero y esfuerzo en una idea que solo sonaba bien en tu cabeza.
Interactuando con tus clientes
Si crees que tienes una buena idea, lo primero que debes hacer no es ejecutarla, sino salir e interactuar con clientes. No para convencerlos de que es buena, sino para validar dos cosas: que el problema que quieres resolver realmente existe y que merece ser resuelto.
Aquí es donde muchos fallan. Es fácil convencerse de que un problema es importante solo porque lo has experimentado personalmente o porque parece lógico que exista. Pero la pregunta clave es: ¿Este problema realmente afecta a suficientes personas como para justificar construir algo alrededor de él?
Si solo tú o unas pocas personas lo sufren, entonces no es un problema del mercado, es una preferencia personal. También puede pasar que el problema exista, pero que a nadie le importe lo suficiente como para hacer algo al respecto. Si no duele, si no genera fricción real, los usuarios no van a cambiar su comportamiento ni pagar por una solución.
Muchos PMs se saltan este punto. Asumen que porque algo es un problema, la gente pagará o cambiará su forma de hacer las cosas para resolverlo. Pero la realidad es que hay muchísimos problemas reales que simplemente no son lo suficientemente grandes o dolorosos como para que los usuarios tomen acción.
Un gran ejemplo de esto es Olly.bot, un asistente personal basado en IA que creció a 250,000 usuarios, pero fracasó cuando intentó monetizar. Su creador asumió que, porque la gente lo usaba, también estarían dispuestos a pagar. Pero cuando introdujo un modelo de pago, el número de usuarios activos semanales cayó de 70,000 a 9,000 y solo 400 personas aceptaron pagar $4 al mes. No porque el producto fuera malo, sino porque no resolvía un problema lo suficientemente crítico como para que la gente quisiera pagar por él.
Construir algo útil no es suficiente. Para que un producto tenga éxito, debe resolver un problema que afecte a suficientes personas y que sea lo suficientemente molesto como para que busquen activamente una solución. Pero no puedes asumirlo. Tienes que validarlo.
El problema es que muchas validaciones están mal hechas. Preguntar directamente "¿Te gusta esta idea?" no te va a dar una respuesta real. La mayoría de las personas dirá que sí, no porque realmente lo necesiten, sino porque es fácil decirlo cuando no hay costo ni compromiso de por medio. Si validas de esta manera, lo único que obtendrás es una falsa sensación de certeza.
En The Mom Test, Rob Fitzpatrick explica cómo evitar este problema y hacer preguntas que realmente te den información útil. La clave está en cambiar el enfoque de la idea al usuario y su comportamiento real. Para obtener respuestas valiosas, sigue estas reglas:
Habla sobre la vida del cliente, no sobre tu idea. No preguntes si les gusta lo que tienes en mente, porque te dirán lo que quieres escuchar. En su lugar, investiga cómo viven el problema que quieres resolver. Si estás construyendo una app de productividad, no preguntes “¿Te gustaría una aplicación para organizar tu día?”, pregunta “¿Cómo organizas tus tareas actualmente? ¿Qué es lo más frustrante de ese proceso?”. Ahí es donde encontrarás insights reales.
Pregunta sobre el pasado, no sobre el futuro. La gente es optimista cuando habla del futuro, pero su comportamiento pasado es lo único confiable. En lugar de preguntar “¿Comprarías una herramienta para gestionar tus finanzas?”, pregunta “Cuéntame sobre la última vez que tuviste problemas manejando tu dinero. ¿Qué hiciste?”. Así sabrás cómo toman decisiones en la realidad, no en teoría.
Escucha más, habla menos. Si hablas demasiado, vas a influir en las respuestas sin darte cuenta. Haz preguntas abiertas y quédate callado. Déjalos hablar. El mejor insight que puedes obtener suele venir después de una pausa incómoda.
No busques aprobación, busca hechos y compromisos. Que alguien te diga “Suena interesante” no significa nada. Si de verdad les interesa, estarán dispuestos a hacer algo al respecto. Pídeles un compromiso tangible: que se registren en una lista de espera, que hagan un depósito inicial o que inviertan tiempo en probarlo. Si nadie está dispuesto a hacer algo más que decirte "buena idea", no tienes validación.
Todo este proceso no lo debes hacer solo. Trabaja con el Product Designer para estructurar bien estas entrevistas y asegurarte de que realmente estás validando lo que importa. Porque si lo haces mal, solo estarás convenciendo a tu equipo de trabajar en algo sin valor. Y la realidad es que tu opinión, la de tu jefe o la de los stakeholders no vale nada comparada con lo que realmente piensan los clientes.
El concepto de experimentación en producto
Luego de validar que la idea que tienes resuelve un problema real y que merece ser resuelto, recién ahí puedes empezar a pensar en cómo resolverlo. Hasta ahora, todo el enfoque ha estado en el problema, y eso no es casualidad. Muchos PMs hacen lo contrario: saltan directo a la solución sin entender primero el problema.
“Un problema bien planteado es un problema medio resuelto”.
Charles Kettering
Pero plantear bien un problema no es suficiente. También necesitas asegurarte de que la solución que propones realmente funciona antes de invertir tiempo y recursos en construirla. Ahí es donde entra la experimentación. Y cuando hablamos de experimentación, no es una metáfora ni una moda de growth hacking. Es el método científico, tal cual lo enseñó Galileo Galilei en los 1600. Literalmente Galileo enseñando Product Managementen el siglo XXI.
El método científico parte de un principio simple: no asumimos que sabemos la verdad, la descubrimos a través de la observación, hipótesis, experimentación y análisis. Y eso es exactamente lo que hicimos cuando salimos a hablar con clientes: observamos. Identificamos patrones, entendimos comportamientos y recolectamos evidencia sobre lo que realmente sucede en la vida de nuestros usuarios.
Ahora viene la siguiente etapa: formular una hipótesis y probarla. No basta con creer que una solución funcionará. Hay que diseñar experimentos que nos permitan validar si nuestra hipótesis es correcta antes de invertir meses construyendo algo que quizás no sirva.
Tomemos el ejemplo de la introducción de esta newsletter. El Product Manager asumió que el modo oscuro aumentaría el engagement simplemente porque él lo usa en todas sus apps. En lugar de darlo por hecho, pudo haber validado si realmente tendría ese impacto. Pero antes de siquiera preocuparse por su efecto en el engagement, había una hipótesis más fundamental que debía validar primero:
Hipótesis: Si implementamos el modo oscuro, al menos el X% de los usuarios lo activará dentro de las primeras Y semanas.
Antes de medir impacto en engagement, primero necesitábamos saber si los usuarios realmente activarían la funcionalidad. Porque si no la adoptan, no hay forma de que tenga algún efecto en la métrica final.
Validar esta hipótesis antes de construir habría sido simple. Un experimento rápido hubiera sido agregar un botón falso en la aplicación que dijera "Activar modo oscuro". Esto solo hubiera requerido de algunas horas de trabajo. Si los usuarios hacían clic, en lugar de activar la funcionalidad, se les mostraría un mensaje que dijera: "Estamos trabajando en esta funcionalidad.".
¿Qué hubiera logrado este experimento?
Confirmar si la hipótesis era correcta. Si los usuarios hacían clic en el botón, había evidencia clara de que existía interés en la funcionalidad. Si no lo hacían, se invalidaba la hipótesis antes de escribir una sola línea de código.
Evitar tomar decisiones basadas en suposiciones falsas. Sin este experimento, el equipo habría invertido meses construyendo algo basado en una corazonada. Validarlo primero evita desarrollar funcionalidades que nadie realmente necesita.
Ahorrar recursos y tiempo. En lugar de gastar meses en diseño y desarrollo solo para descubrir después que nadie lo usa, este experimento habría dado la respuesta en días, con un costo prácticamente nulo.
Este es el punto clave de la experimentación: antes de invertir tiempo y recursos construyendo algo, necesitas validar si realmente vale la pena. En el ejemplo, si no logras validar que los usuarios adoptarían la solución, no importa cuánto esfuerzo dediques a optimizarla, promocionarla o medir su impacto, simplemente estás perdiendo el tiempo.
Eric Ries lo explica perfectamente en The Lean Startup:
El aprendizaje validado: Las startups no existen solo para producir cosas, ganar dinero o atender a los consumidores. Existen para aprender cómo crear negocios sostenibles. Este conocimiento puede desarrollarse científicamente, llevando a cabo experimentos frecuentes que permitan a los emprendedores probar todos los elementos de su idea.
Y esto no aplica solo a startups. Cada producto o funcionalidad que decides construir es una apuesta. Si no validas antes de construir, lo que estás haciendo no es Product Management, es un salto al vacío.
El riesgo de no experimentar
El 90% de los experimentos fallan. Este es un dato que obtuve de Ronny Kohavi, PhD, consultor, profesor y experto en el arte y la ciencia de las pruebas A/B, quien analizó miles de experimentos en compañías como Microsoft, Airbnb y Amazon. En promedio, solo 1 de cada 10 experimentos valida con éxito una idea.
Por lo tanto, para tener éxito experimentando, necesitas hacerlo de manera frecuente y económica. Si buscas implementar 10 ideas exitosas, probablemente necesitarás realizar unos 100 experimentos. No se trata de acertar siempre, sino de maximizar el número de intentos para aumentar tus probabilidades de éxito.
Ahora bien, ¿qué pasa si no experimentas? Decides apostar todo a una sola idea. Inviertes tiempo, recursos y esfuerzo sin validar nada. Y esperas que funcione. En esencia, acabas de hacer un experimento… pero solo uno. Y si sabemos que 9 de cada 10 experimentos fallan, entonces tu probabilidad de éxito es del 10%.
Para ponerlo en perspectiva: si realmente quieres jugar con tan malas probabilidades, mejor ve al casino y apuesta todo al rojo en la ruleta. Al menos ahí tienes casi un 50% de probabilidades de ganar y lo sabrás al instante, sin esperar 3 meses desarrollando un “MVP”.
Bono: Los casos de negocio
Muchos piensan que los casos de negocio están fuera del concepto de "descubrir" (por eso lo incluyo como bono), asumiendo que es tarea exclusiva de consultores o equipos financieros. Esto es un error, al menos desde mi punto de vista. Así como validamos si los usuarios adoptarán una solución, también debemos validar si tiene sentido para el negocio. No basta con que los usuarios deseen algo, si no genera valor para la empresa o si el costo de desarrollo no se justifica, simplemente no deberíamos hacerlo.
Aquí es donde entran los casos de negocio. Y no, no hablo de un documento de 30 páginas lleno de proyecciones irreales. Un caso de negocio bien hecho es una herramienta simple que responde una pregunta clave: ¿vale la pena invertir en esto? Si no puedes justificarlo de manera clara, probablemente no lo vale.
Para responder esto, hay tres cosas que debes analizar:
Impacto en ingresos o costos → ¿Esto atraerá nuevos clientes, reducirá churn o aumentará el ticket promedio? ¿O solo sumará costos sin retorno?
Escalabilidad → ¿Esta solución funcionará para un segmento grande o solo para un grupo reducido de usuarios? Si impacta a menos del 1% de los clientes, ¿realmente vale la pena?
Tiempo de recuperación → ¿Cuánto tiempo tomará recuperar la inversión? Si cuesta 500K construirlo y genera 50K al año, estás quemando dinero.
Ahora, sé que algunos ven los casos de negocio como algo que se aleja del pensamiento centrado en el cliente. A ellos les digo: no hay mejor forma de pensar en el cliente que asegurarse de que el negocio sea rentable y sostenible. Si no lo es, simplemente no habrá negocio para seguir resolviendo sus necesidades.
¿Y entonces?
Si algo deberías llevarte de todo esto, es lo siguiente: hacer Product Management no es lanzar funcionalidades, es gestionar el riesgo.
El peor error que puedes cometer no es elegir la solución equivocada. Es nunca tomarte el tiempo de validar si lo que estás construyendo realmente vale la pena. Si sigues confiando solo en corazonadas, en opiniones sin datos o en lo que suena lógico, vas a desperdiciar tiempo, esfuerzo y dinero en ideas que nunca debieron pasar de una conversación.
El buen Product Management no es una cuestión de intuición ni de experiencia, es un proceso disciplinado de descubrimiento, validación y experimentación. Un proceso que no se basa en lo que crees que funcionará, sino en lo que puedes demostrar con evidencia.
La próxima vez que alguien sugiera una idea “brillante” para crear o mejorar un producto, hazte estas preguntas:
¿Estamos seguros de que este problema realmente existe? ¿O solo asumimos que sí?
¿Es un problema lo suficientemente importante como para que los usuarios lo quieran resolver?
¿Podemos validar si la solución realmente será adoptada o generará los resultados esperados?
¿Tiene sentido para el negocio? ¿O solo lo estamos haciendo porque “suena bien”?
Si no tienes respuestas claras a estas preguntas, no tienes validación. Y si no tienes validación, no tienes nada.
La diferencia entre un PM malo y un gran PM es simple: el primero construye y espera a ver qué pasa. El segundo valida, experimenta y solo construye cuando tiene suficiente evidencia de que vale la pena.
¡Gracias por leer! Puedes seguirme en LinkedIn, donde semanalmente comparto contenido sobre Product Management y liderazgo.
Que tengas un buen día 🙏
Rómulo
P.D. Si te gustó esta newsletter, dale "me gusta", compártela y, si aún no lo has hecho, considera suscribirte.