LinkedIn se ha convertido en la plataforma principal donde los product managers construyen la reputación externa que las evaluaciones de desempeño internas no logran reflejar del todo.
Compartir tu forma de pensar el producto, desde los marcos de discovery hasta los tradeoffs de priorización y los post-mortems de lanzamientos, demuestra la claridad estratégica que buscan quienes contratan y los posibles colaboradores mucho antes de una entrevista formal.
Las publicaciones de product managers que mejor funcionan en LinkedIn suelen girar en torno a una decisión que no salió como se esperaba.
Lanzar algo que nadie usó, matar una funcionalidad que según las métricas debía funcionar o descubrir un caso de uso que nunca anticipaste: estas historias muestran la velocidad de aprendizaje que separa a los buenos pensadores de producto de quienes solo lanzan funcionalidades.
La especificidad es lo que marca la diferencia: las opiniones vagas se pasan de largo y los ejemplos concretos se guardan.
Publicar con constancia durante seis meses suele dar resultados que se acumulan: conversaciones con reclutadores para cargos de un nivel claramente más alto, invitaciones a eventos de la comunidad de producto y mensajes directos de fundadores que leyeron una publicación y pensaron 'esta persona entiende'.
La audiencia que construyes en LinkedIn se convierte en un consejo asesor privado al que puedes consultar cuando estás resolviendo tu próximo problema de producto.
- 1
La funcionalidad que lanzamos y nadie usó: un post-mortem
Una autopsia honesta de un lanzamiento fallido, con cifras de uso y el paso de discovery que te saltaste. Los product managers confían en los colegas que publican sus errores, y la lección llega más lejos que cualquier victoria.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Lanzamos una funcionalidad que nos llevó un trimestre entero construir. Seis semanas después del lanzamiento, el uso estaba por debajo del 2%. Este es el post-mortem honesto.
La idea vino de un puñado de cuentas enterprise muy insistentes que la pidieron directamente, en voz alta, en varias revisiones trimestrales de negocio. Tomamos ese volumen como señal de demanda y nos saltamos el paso que habría detectado el problema: validar con una muestra más amplia del segmento objetivo real, no solo con las cuentas más ruidosas.
Resultó que esas cuentas en particular tenían un flujo de trabajo poco común que hacía que el pedido tuviera sentido para ellas y casi para nadie más. El resto de nuestra base de usuarios no tenía el problema que resolvía esta funcionalidad.
Construirla no fue el error. El error fue tratar tres voces ruidosas como una muestra representativa.
Ahora exigimos un tamaño mínimo de muestra validada antes de que algo entre al roadmap, sin importar lo senior o insistente que sea la cuenta que lo pide. Ruidoso no es lo mismo que representativo, y lo aprendimos por las malas, con un trimestre entero de ingeniería.
- 2
Cómo le digo que no a la dirección sin decir que no
La gestión de stakeholders es la habilidad de producto que no se enseña y que todos quieren aprender. Compartir las frases y los replanteamientos que usas en conversaciones de roadmap la vuelve práctica de inmediato.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Cómo le digo que no a la dirección sin pronunciar nunca la palabra.
En lugar de "no podemos hacer eso", digo: "esto es lo que tendríamos que despriorizar para hacerle lugar, ¿cuál de estas dos cosas te importa más?". Eso convierte un rechazo en un tradeoff que ellos eligen, y casi siempre cae mejor que un no rotundo.
En lugar de "eso no es prioridad", digo: "cuéntame qué resultado esperas de esto, quiero asegurarme de que estemos resolviendo la versión correcta del problema". La mitad de las veces, esto revela que la necesidad real es más pequeña o distinta de lo que se pidió al principio.
En lugar de quedarme callado cuando no estoy de acuerdo, digo: "tengo una preocupación con este enfoque, ¿puedo compartirla antes de comprometernos?". Presentarlo como una preocupación que merece ser escuchada, y no como una objeción que hay que vencer, hace que de verdad me escuchen.
Nada de esto es manipulación. Es simplemente un encuadre honesto que respeta la autoridad de la dirección y protege la integridad del roadmap.
- 3
Tu roadmap es una lista de deseos. El mío tiene criterios para matar iniciativas
Un planteamiento provocador que presenta una práctica concreta, como definir de antemano las condiciones para abandonar cada iniciativa. La apertura provocadora gana el clic; el marco gana el guardado.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
La mayoría de los roadmaps son listas de deseos. El mío tiene criterios para matar iniciativas, definidos antes de escribir una sola línea de código.
Cada iniciativa de nuestro roadmap ahora tiene una condición explícita: esta es la métrica que esperamos mover, este es el umbral por debajo del cual la abandonamos y esta es la fecha de control en la que la evaluamos. No son metas aspiracionales, son disparadores reales de abandono acordados de antemano.
Esta sola práctica mató tres iniciativas el último año que, de otro modo, habrían seguido arrastrándose durante meses por la inercia del costo hundido. Cada una liberó capacidad real de ingeniería para algo que importaba más.
También cambia las conversaciones con los stakeholders. "Probemos y vemos" invita a un debate interminable sobre si está funcionando. "Acordamos matarlo si no llega a X en esta fecha" vuelve la decisión casi mecánica cuando llega el día.
Un roadmap sin criterios para matar iniciativas no es un plan. Es una colección de esperanzas que nadie se comprometió a evaluar de verdad.
- 4
Hicimos 30 entrevistas con usuarios en 30 días. Este es el sistema de reclutamiento
El discovery continuo suena genial hasta que intentas agendarlo. Una guía práctica con números sobre cómo reclutar participantes resuelve el cuello de botella que, en silencio, mata la mayoría de las prácticas de investigación.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Hicimos 30 entrevistas con usuarios en 30 días. Este es el sistema de reclutamiento exacto que lo hizo posible, porque agendar es donde la mayoría de las prácticas de discovery mueren en silencio.
Un canal de reclutamiento permanente: un aviso dentro de la app, siempre activo, que ofrece una llamada de 20 minutos a cambio de acceso anticipado a funcionalidades. Corre de forma continua en lugar de lanzarse desde cero en cada ronda de investigación.
Un grupo precalificado: a quien acepta se le etiqueta automáticamente con datos básicos de segmento, así que cuando necesitamos cinco administradores de cuentas enterprise en concreto, no buscamos en frío, filtramos una lista que ya existe.
Un link de agenda de un solo clic que se envía apenas la persona acepta, cuando el interés está en su punto más alto, en lugar de un correo de seguimiento manual días después que la mitad del grupo nunca abre.
Un horario fijo de entrevistas, a la misma hora cada día hábil, protegido en el calendario aunque nadie lo haya reservado todavía. Así el equipo crea el hábito de entrevistar en lugar de tratar cada entrevista como un evento especial alrededor del cual hay que reorganizarse.
El volumen no vino de trabajar más. Vino de quitar la fricción que hace que la mayoría de los equipos haga cuatro entrevistas y luego deje de hacerlas sin decir nada.
- 5
El PRD de una página que reemplazó nuestra especificación de 12
El exceso de documentación es un dolor compartido entre product managers. Mostrar exactamente qué secciones conservaste y por qué ingeniería lo prefirió le da a quien lee un entregable para probar con su propio equipo.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Nuestros PRDs solían tener 12 páginas. Ahora tienen una, y el equipo de ingeniería me dice que lo prefiere.
Lo que conservamos: el planteamiento del problema, en dos oraciones como máximo. La métrica de éxito, un solo número, no una lista de cinco. Los no-objetivos explícitos, es decir, lo que deliberadamente no vamos a resolver, que terminó evitando más crecimiento del alcance que cualquier nivel de detalle sobre lo que sí resolvíamos. Y las preguntas abiertas, listadas con honestidad, en lugar de fingir que cada decisión ya estaba tomada.
Lo que eliminamos: descripciones detalladas de mockups que duplicaban el archivo de Figma, listas exhaustivas de casos límite que ingeniería estaba en mejor posición de detectar durante la implementación, y una sección de "contexto" que nadie leía más allá del primer párrafo.
El feedback de ingeniería fue directo y útil: la versión de 12 páginas les hacía sentir que les entregaban una decisión terminada para ejecutar. La versión de una página les hace sentir que les entregan un problema que pueden ayudar a resolver.
La extensión de la documentación nunca protegía a nadie. Solo hacía que el product manager se sintiera más minucioso.
Cuenta gratis
Crea tu cuenta gratis
ThoughtMint convierte lo que sabes en publicaciones de LinkedIn que suenan a ti. Por ahora la aplicación está en inglés: puedes usarla desde hoy y te avisaremos por correo cuando llegue la versión en español.
Prueba gratis: 7 días o 2500 palabras de IA, lo que ocurra primero. Sin tarjeta de crédito.
- 6
Un cliente pidió un botón de exportar. Necesitaba algo completamente distinto
Una anécdota clásica de los cinco porqués con un pedido de funcionalidad real. Revelar el trabajo de fondo que el cliente intentaba resolver enseña técnica de discovery a través de una historia y no de una clase.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Un cliente pidió un botón de exportar. Lo que realmente necesitaba era algo que ese botón nunca habría resuelto.
Primer pedido: "¿pueden agregar una exportación a CSV?". Un pedido fácil; lo podríamos haber lanzado en un sprint y cerrado el ticket.
En cambio, pregunté por qué. Resultó que exportaban los datos para pegarlos en una hoja de cálculo aparte y compartir un resumen semanal con su equipo, porque nuestra vista dentro de la app no se podía compartir con personas fuera de su cuenta.
Volví a preguntar por qué: el resumen que armaban a mano cada semana tenía las mismas cinco métricas, recalculadas desde cero cada vez, porque no había forma de guardar ni compartir una vista.
La solución real no era un botón de exportar. Era una vista de dashboard guardada y compartible, una funcionalidad completamente distinta que resolvía el ritual semanal real y no solo su síntoma.
Con el tiempo igual construimos el botón de exportar, porque algunos casos de uso de verdad necesitan los datos en bruto. Pero lo que usan hoy es la vista compartible, y no existiría si solo hubiéramos lanzado el primer pedido.
- 7
Seis marcos de priorización que he usado, y el que me quedé
Una lista con veredictos honestos sobre RICE, ICE y compañía, incluido dónde te falló cada uno. Las comparaciones de marcos basadas en uso real siempre le ganan a las explicaciones de marcos.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Seis marcos de priorización que de verdad he usado, con veredictos honestos, y el que me quedé.
RICE: bueno para obligar a cuantificar, pero los puntajes de alcance y confianza se manipulaban todo el tiempo. Curiosamente, el puntaje de confianza de cada persona caía justo en el umbral necesario para justificar su proyecto favorito.
ICE: más rápido que RICE, el mismo problema de manipulación, solo que con menos números que maquillar.
Modelo Kano: realmente útil para entender qué genera encanto y qué es una expectativa básica, pero demasiado pesado para usarlo en cada decisión. Ahora lo reservo para la planificación grande del roadmap, no para el triage semanal.
MoSCoW: demasiado binario para cualquier cosa con matices reales; bajo presión de los stakeholders, todo termina siendo "imprescindible".
Matrices de puntuación ponderada: rigurosas en teoría, lentas en la práctica, y los pesos mismos se convirtieron en su propio campo de batalla político.
El que me quedé, casi siempre: una pregunta simple que obliga a decidir. "¿Qué pasa si no hacemos esto durante seis meses?" Si la respuesta honesta es "nada cambia de forma significativa", no es realmente una prioridad, sin importar cuánto puntúe en papel.
Los marcos sirven para estructurar el debate. Ninguno reemplaza el criterio que hay debajo.
- 8
El prototipado con IA cambió lo que significa 'viable'. La mayoría de los roadmaps no se ha dado cuenta
Una reacción a la tendencia sobre cómo el prototipado rápido cambia la economía entre construir y validar. Conectar un tema de moda con decisiones concretas de roadmap te posiciona por encima del ruido.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
El prototipado asistido por IA cambió en silencio lo que significa "viable" en una decisión de roadmap, y la mayoría de los procesos de planificación no se ha puesto al día.
Hace un año, validar una idea de funcionalidad medianamente compleja implicaba un spike de ingeniería de varias semanas antes de saber si valía la pena. Ese costo definía qué ideas llegaban siquiera a considerarse para el roadmap: cualquier cosa que exigiera un esfuerzo real de validación quedaba despriorizada por defecto, solo porque comprobarla era caro.
Hoy, un prototipo rudimentario y testeable para la misma idea muchas veces se puede construir en días, a veces en horas, con herramientas asistidas por IA. Eso cambia por completo la economía real de la decisión entre construir y validar.
Empezamos a tratar "armemos una versión rudimentaria y probémosla" como un elemento legítimo del roadmap por derecho propio, no como un atajo para saltarse la planificación. Varias ideas que hace un año habrían muerto en una reunión de priorización ahora reciben feedback real de usuarios en menos de una semana.
El proceso de roadmap que la mayoría de los equipos sigue usando asume que validar es caro. Esa suposición es cada vez más falsa, y el proceso de planificación debería reflejarlo.
- 9
Nuestra sprint review por dentro: la pregunta que revela el crecimiento oculto del alcance
Contenido de proceso detrás de escena con una pregunta concreta que cualquiera puede robar. Los pequeños detalles operativos como este son la forma en que los product managers evalúan la experiencia real de sus colegas.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Una pregunta en nuestra sprint review revela el crecimiento oculto del alcance mejor que cualquier burndown chart: "¿qué construimos en este sprint que no estaba en el ticket original?"
La mayoría de los equipos compara lo que se lanzó con lo que se planificó y lo da por bueno si los números coinciden más o menos. Esta pregunta apunta a otra cosa: no si el resultado del sprint coincidió con el plan, sino si el plan mismo creció en silencio a mitad del sprint sin que nadie lo señalara.
Las respuestas suelen ser reveladoras. Un ticket "pequeño" que sumó tres requisitos adicionales durante la implementación, ninguno lo bastante grande por sí solo como para provocar una conversación de redefinición del alcance, pero que juntos convirtieron una tarea de dos días en una semana.
Ahora lo medimos de forma explícita, no para buscar culpables, sino porque el crecimiento del alcance sin señalar era la principal razón por la que nuestras estimaciones se desviaban a lo largo de un trimestre, una pequeña adición a la vez.
Es una pregunta pequeña. Hacerla con constancia, en cada sprint, es lo que la vuelve útil. Si la haces una sola vez, solo recibes un encogimiento de hombros.
- 10
Product managers: ¿qué métrica dejaste de reportar y no extrañas?
Una publicación con pregunta sobre higiene de métricas que da vuelta la típica adoración por los dashboards. Las respuestas sacan a la luz métricas de vanidad de distintas empresas y crean un hilo que los product managers les reenvían a sus equipos de analítica.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Pregunta sincera para otros product managers: ¿qué métrica reportabas religiosamente y terminaste dejando de lado porque resultó inútil o directamente engañosa?
La mía fue la de usuarios activos semanales, reportada de forma aislada, en un producto donde "semanal" no era la frecuencia correcta para nuestro caso de uso. La mayoría de nuestros usuarios más intensivos solo necesitaban el producto, legítimamente, cada pocas semanas, y la métrica los hacía parecer usuarios a punto de irse cuando no lo eran.
La reemplazamos por una métrica de engagement ajustada a la frecuencia real de uso, y el dashboard por fin contó una historia que coincidía con lo que decían las conversaciones con clientes.
Sospecho que la mayoría de los equipos carga al menos con una métrica heredada como esta: algo que tenía sentido cuando se configuró y que ahora solo genera ruido o, peor, impulsa malas decisiones porque nadie la ha cuestionado en años.
¿Cuál es la tuya? Las estoy juntando para reenviárselas a nuestro equipo de analítica como excusa para volver a auditar nuestro dashboard.
Preguntas frecuentes
¿Qué debe publicar un product manager en LinkedIn?
Publica historias de decisiones: cómo priorizaste entre apuestas que competían entre sí, qué reveló el discovery que cambió el plan y post-mortems de funcionalidades que no funcionaron. El trabajo de un product manager es criterio invisible, así que hacer público tu razonamiento es la única forma de demostrarlo.
Evita repetir marcos teóricos, que ya saturan el feed; una anécdota real sobre cómo manejaste un conflicto con stakeholders enseña más y llega más lejos que otra explicación de RICE.
¿Con qué frecuencia debe publicar un product manager en LinkedIn?
Dos o tres veces por semana es realista junto a la carga de trabajo de producto. Saca el material de lo que ya produces: un tradeoff de un PRD se convierte en una publicación, un hallazgo de una entrevista con usuarios en otra y una lección de una retro en una tercera.
Anonimiza los detalles del producto si hace falta; lo que la gente quiere es el razonamiento. Los product managers que publican con constancia notan mejores mensajes de reclutadores en un trimestre, porque quienes contratan pueden ver un criterio que de otro modo tendrían que sondear en las entrevistas.
¿Importa la presencia en LinkedIn para una carrera en product management?
Cada vez más, sí. La contratación de product managers se está moviendo hacia la evidencia de cómo piensas, y un registro público de historias de decisiones y post-mortems funciona como portafolio en un rol que de otro modo no lo tiene.
Las ofertas para cargos senior y de dirección de producto muchas veces llegan después de meses de escritura visible. También se acumula dentro de tu empresa: los stakeholders que leen tus publicaciones le dan más confianza a tu roadmap.
Empieza con un post-mortem honesto; va a rendir más que cualquier lista de marcos que puedas compartir.
Herramientas gratis para LinkedIn
Da formato a tus publicaciones y revisa cómo se verán antes de publicarlas.
Más ideas de publicaciones