Ideas cortas sobre cómo se construyen mejor los productos digitales. Sin newsletter, sin calendario editorial: cuando hay algo que vale la pena escribir.
Hay software que resuelve un problema real de forma que el usuario no podría resolver de otra manera. Y hay software que envuelve en una interfaz algo que el usuario ya hacía con Excel. La diferencia importa más de lo que parece.
Articular lo que se aprende revela los huecos de comprensión mejor que cualquier otra forma de estudio. Compartirlo hace visible la evolución profesional.
Uso IA a diario y tengo reservas fundadas sobre algunas de sus consecuencias. Ambas cosas son compatibles. Esa tensión es la posición honesta.
El mapa de empatía es una herramienta de síntesis, no de investigación. Usarlo como sustituto del research genera una falsa sensación de conocer al usuario que puede ser más peligrosa que no tener ningún artefacto.
En la práctica, todos los stakeholders tienen razones legítimas para que su petición sea prioritaria. El trabajo del PM es navegar esa presión con criterio propio y un proceso transparente.
Los equipos de desarrollo te enseñan a ser más preciso, más honesto sobre lo que no sabes, y más respetuoso con el coste real del trabajo. Si estás dispuesto a escuchar.
La inteligencia artificial lleva demasiado tiempo siendo protagonista de conversaciones que confunden el medio con el fin. El problema no es la tecnología. El problema son las preguntas que le hacemos.
La tensión entre diseño y producto en muchos equipos no viene de intereses incompatibles. Viene de roles mal definidos, procesos que no incluyen al diseño en el momento correcto, y falta de lenguaje común.
La cultura del backlog infinito nos ha enseñado a valorar la producción. Pero el trabajo más importante del producto digital es el que ocurre antes de construir cualquier cosa.
La transición del diseño al producto no es un salto. Es una acumulación. Y tiene más sentido de lo que parece desde fuera.
El Net Promoter Score tiene décadas de historia y millones de implementaciones. También tiene problemas metodológicos conocidos que hacen que muchas de esas implementaciones midan casi nada útil.
Añadir es fácil. Quitar requiere criterio, valentía y una comprensión profunda de lo que realmente importa al usuario.
UX no es diseñar pantallas bonitas. Es entender el contexto completo en el que una persona intenta conseguir algo, y eliminar todos los obstáculos posibles en ese camino.
Sostener una posición de producto frente a quien tiene más autoridad es parte del trabajo. La clave no es el no, sino cómo se argumenta y cuándo.
Toda feature urgente tiene un coste que no aparece en la estimación: el trabajo que no se hace, la deuda que se acumula, y la pérdida de foco del equipo. Ese coste es real aunque nadie lo contabilice.
El refinamiento es potencialmente una de las actividades más valiosas en equipos ágiles. En la práctica, muchas sesiones son una hora de tiempo colectivo que no aporta nada. La diferencia está en cómo se preparan.
Las métricas de vanidad son las que hacen bien en un dashboard pero no dicen nada sobre si el producto está generando valor real. Lo difícil es reconocerlas en el propio contexto.
La IA está cambiando qué parte del trabajo de producto se puede automatizar. Lo que no cambia es qué parte requiere criterio, contexto y responsabilidad. La diferencia importa más que nunca.
Los fracasos exponen los supuestos que guiaron las decisiones. Los éxitos los ocultan. Esa diferencia genera más aprendizaje del que solemos aprovechar.
La investigación de usuarios no requiere laboratorios de usabilidad ni agencias de research. Con un poco de método y creatividad, hay mucho que se puede aprender sin gastar casi nada.
La frase 'el usuario quiere' se usa para justificar casi cualquier decisión de producto. Es una de las frases más útiles y más peligrosas del vocabulario del PM.
El roadmap es una herramienta de alineación y comunicación. El problema es que muchos equipos lo usan como un calendario de promesas que no se pueden cumplir. Y todos lo saben.
Mantener el criterio propio frente a los stakeholders es una habilidad. Reconocer cuándo ese criterio está incompleto también lo es.
Los datos no hablan solos. La información bruta no se convierte en conocimiento útil sin alguien que sepa qué preguntas hacerle. Eso es lo que diferencia un dato de una señal.
El backlog es una herramienta de gestión, no un inventario de verdades. Entender esa diferencia cambia completamente cómo se trabaja con él.