Hay algo casi mágico en ver cómo una decisión tomada desde el dato correcto transforma una experiencia de usuario. No es magia, claro. Es analítica digital bien hecha.

Pero ¿cuántas veces creemos estar midiendo bien… cuando en realidad solo estamos sumando eventos?

En equipos de producto, hablar de datos es fácil. Lo difícil es medir lo que realmente importa: ese momento de fricción en el funnel que parece invisible, ese comportamiento del usuario que se diluye entre dashboards.

Medir bien no es coleccionar KPIs. Es saber hacer la pregunta correcta y construir el sistema adecuado para responderla. Medir bien es una decisión de diseño.

¿Qué significa medir bien?

* Medir bien es priorizar la comprensión sobre el volumen.

* Medir bien es evitar el vanity data y centrarse en el comportamiento.

* Medir bien es tener claridad sobre lo que se quiere accionar después del insight.

No se trata de tener una herramienta cara ni de montar un stack sofisticado. Se trata de cultura. De saber que sin una buena medición, las decisiones de producto son, en el mejor de los casos, apuestas intuitivas.

En Decathlon lo tienen claro

Tuve la suerte de conversar con Jorge López, Head of Digital Analytics en Decathlon España, y hablar de todo esto. De cómo entienden el rol del dato, de cómo usan Amplitude, y de cómo han logrado identificar puntos críticos en el funnel de conversión que no eran visibles con herramientas tradicionales.

👉 Puedes ver la entrevista completa aquí:

Si estás en un equipo de producto, datos o UX, creo que te va a dar buenas ideas y quizá alguna inspiración.

“Un mal producto con buena gestión financiera no va a ningún lado. Pero un buen producto con mala gestión… te pierde el partido.” — Jaime Medina, CEO de Startup CFO

Hace unos días grabamos un episodio con Jaime Medina, fundador de Startup CFO, en el que hablamos sobre un tema que rara vez se discute con profundidad: la relación entre el equipo de producto y el CFO.

En el ecosistema startup estamos muy acostumbrados a pensar en producto como algo casi autónomo: diseño centrado en el usuario, decisiones basadas en datos de uso, discovery continuo… pero, ¿cuántas veces involucramos a Finanzas de verdad?

Jaime tiene una visión muy clara: el CFO no está para revisar facturas ni hacer reporting por obligación. Está para ayudar a tomar mejores decisiones. Especialmente, las de producto.

💸 El CFO no es un deliverable. Es una herramienta estratégica

Uno de los mensajes más potentes de Jaime fue este: el reporting no es el trabajo del CFO, es su herramienta. No sirve para entregar un PDF cada mes, sino para detectar que estamos invirtiendo en la dirección equivocada, o que estamos gastando sin retorno real.

"¿Por qué estamos metiendo pasta en inbound si outbound tiene mejor conversión?"

En otras palabras, el CFO tiene que estar tan cerca del negocio como del Excel.

🔁 ¿Tu producto es recurrente o simplemente lo quieres creer?

Otra joya que dejó Jaime es la crítica al sesgo aspiracional que tenemos en producto (y como founders): creer que tenemos un modelo de negocio recurrente cuando en realidad el caso de uso no lo es.

Puedes cobrar por suscripción. Pero si el usuario solo tiene necesidad una vez al año, tienes un problema de retención disfrazado de MRR.

“Imagínate que haces un SaaS para organizar bodas. Por muy recurrente que quieras que sea… no lo es.”

📊 Habla el idioma del CFO (si quieres que te aprueben el roadmap)

¿Quieres convencer al CFO de que priorice una funcionalidad? Jaime fue muy claro: habla en términos de retorno de inversión.

* ¿Cómo afectará esa funcionalidad al churn?

* ¿Reducirá el cash payback?

* ¿Incrementará el ticket medio?

La clave está en presentar las apuestas del roadmap como escenarios con impacto financiero estimado, no solo como mejoras de UX.

🧪 Elimina incertidumbre, pero con cabeza

Finalmente, Jaime recuperó la esencia del enfoque lean: una startup es una máquina de eliminar incertidumbre. Pero no lo haces por intuición, lo haces con datos. Y si los datos no están, al menos modela hipótesis con rangos, escenarios, riesgos.

“Apunta al caso optimista, toma decisiones en el base, y finańciate para el peor.”

🧠 ¿Qué debería hacer un Product Manager diferente mañana?

* Agenda una reunión con Finanzas. En serio. Conócelos, explícales tu mundo.

* Comparte tus métricas de uso con contexto financiero.

* Empieza a pensar en unit economics. Pero desde el cash.

* Usa cohortes, no averages. No caigas en la trampa de la “media de la teta y el huevo”.

* No compres features milagro. Mide. Compara. Decide.

Este episodio es oro puro si alguna vez te has preguntado: ¿cómo puedo justificar el impacto de producto más allá de lo cualitativo?

Puedes escucharlo completo aquí →

Últimamente todo lo que escuchamos sobre inteligencia artificial tiene que ver con prompts, ChatGPT, generación de imágenes o vídeos. Pero hoy quería traeros una conversación muy distinta.

Invité a Daniyal Shahrokhian al podcast para hablar de la otra IA.La que no se hace viral en redes, pero que se lleva usando desde hace años para resolver problemas reales en empresas. La que requiere datos bien montados, procesos duros de entrenamiento, validación y precisión. Y la que —aunque no tenga nombre de chatbot— mueve millones.

Durante una hora hablamos de:

* Cuál es la diferencia real entre IA generativa y la que él llama "discriminativa".

* Qué tipo de datos se usan para entrenar modelos en el mundo real (y por qué eso es más difícil de lo que parece).

* Cómo funcionan técnicas como el transfer learning y qué es eso de congelar capas de un modelo.

* Qué retos hay al aplicar IA en industrias como la farmacéutica.

* Y por qué el mayor problema no es montar el modelo, sino conseguir y limpiar los datos.

Me gustó mucho una reflexión de Dani:

“No aprendas IA porque sí. Aprende IA cuando veas un problema concreto que quieras resolver. Así es como realmente se aprende.”

Si te interesa entender cómo se aplica la IA más allá del hype, o si estás pensando en usarla en tu empresa, te recomiendo que lo escuches entero.

🎧 Aquí tienes el episodio completo →

El otro día entrevisté a Álvaro Gil, analista de datos en Mojang Studios, la empresa detrás de Minecraft, y aún sigo pensando en todo lo que aprendí.

Imagínate tener que analizar el comportamiento de más de 300 millones de jugadores, cada uno con su estilo, su ritmo y su forma única de jugar. Ahora imagina que de ese caos tienes que sacar ideas claras que ayuden a mejorar el juego más vendido de la historia. Eso es lo que hace Álvaro cada día.

Durante la conversación hablamos de todo:✅ cómo funciona el equipo de Data Analytics dentro de Mojang,✅ qué tipo de datos se recopilan en el juego (¡sin saber la edad ni el género del jugador!),✅ cómo usan plataformas como Databricks para manejar volúmenes gigantes de datos,✅ y cómo han conseguido que los desarrolladores usen los datos sin que se sientan dirigidos por ellos.

Uno de los momentos que más me gustó fue cuando hablamos de data storytelling. Álvaro lo explicaba con claridad: no basta con tener los mejores insights si nadie los entiende o si no sabes venderlos. En su día a día, eso significa a veces hacer presentaciones sin un solo número, porque lo importante es el mensaje, no el decimal.

También hablamos mucho sobre el papel de la inteligencia artificial en su trabajo. Spoiler: no va a reemplazar a los analistas, pero sí les va a liberar mucho tiempo para centrarse en lo que realmente importa: pensar mejor, entender el contexto, trabajar con los stakeholders y aportar valor más allá del código.

💡 Si estás en el mundo del análisis de datos, el diseño de producto, el desarrollo o el gaming, este episodio es para ti.

👉 Puedes ver el episodio completo aquí:

Nos vemos en el próximo.

Hace tiempo que quería hablar con Ignacio Arriaga. Lo conocí por su newsletter, Disaaster —sí, con dos aes—, donde escribe con una honestidad brutal sobre software, negocio y producto. Pero, sobre todo, porque ha hecho algo que pocos pueden decir: construir un SaaS rentable, sin inversión, desde Ciudad Real. Y seguir al frente, 13 años después.

Hace unos días compartí un clip de Ignacio en el que decía algo que me dejó clavado:

“Aceptar que tienes un negocio de puta madre con margen alto… reestructúrate un poco. Igual no vas a crecer tanto. ¿Y qué?”

La frase tocó un nervio. La publiqué y la reacción fue inmediata: mensajes, reposts, debates.Parece que somos muchos los que estamos empezando a hacernos esa misma pregunta en voz alta.

La enshitification del SaaS

En esta entrevista hablamos del concepto de enshitification: esa palabra que suena tan mal como la situación que describe. La degradación progresiva de un producto por culpa de decisiones centradas en las ventas y no en el usuario.

Ese momento en el que un producto que era bueno empieza a estropearse, no por falta de talento, sino por decisiones centradas en contentar a inversores, justificar estructuras, o inflar el ticket medio.

Y cuando eso pasa, todo se resiente: la experiencia, la percepción de valor, el pricing… incluso el equipo.

Crecer no es gratis (ni siempre es bueno)

Ignacio tiene una perspectiva valiosísima: ha dirigido Acumbamail durante más de 13 años, sin inversión externa, con un equipo pequeño y un producto que sigue siendo relevante y rentable.

Durante la charla hablamos de:

* Por qué muchas empresas SaaS acaban traicionando a sus propios usuarios.

* Cómo el equipo de ventas puede pervertir la evolución de un producto.

* Qué significa crecer por encima de tus posibilidades reales.

* El nuevo hype de la IA y cómo está volviendo a justificar crecimientos absurdos.

“Solo hay una cosa que crece de forma infinita: el cáncer.”— Ignacio Arriaga

Mi lectura personal

* No todo crecimiento es sano.

* No todos los productos necesitan escalar para ser buenos.

* Y muchas veces, la obsesión por escalar destruye lo que funcionaba.

Puedes escuchar la entrevista completa aquí:

→ ¿Te gusta el contenido? Suscríbete a mi canal de YouTube y apoya al podcast.

→ ¿Quieres venir a hablar al podcast? Contesta a este email.

Si trabajas en un equipo de producto o desarrollo, seguro que alguna vez has sentido que hay una especie de trinchera entre ambos mundos. Los product managers pidiendo rapidez, los desarrolladores exigiendo calidad, las fechas de entrega tensando la relación... Vamos, un clásico.

Por eso, cuando tuve la oportunidad de entrevistar a Raul Gonzalez, CTO y asesor tecnológico, no dudé en preguntarle sobre cómo mejorar la colaboración entre producto y desarrollo. Raúl ha trabajado con startups y scale-ups ayudando a construir equipos técnicos eficientes y alineados con el negocio. Así que, si alguien sabe de esto, es él.

¿Por qué hay tantas fricciones entre producto y desarrollo?

Le pregunté directamente: ¿Dónde están las mayores tensiones entre estos dos equipos? Y su respuesta fue clara: viene de lejos.

Raúl explica que la estructura tradicional de trabajo en cascada dejó una herencia difícil de romper. Antes, producto definía los requisitos y los pasaba a desarrollo como si fueran una fábrica, sin apenas interacción. Con la llegada de Agile, en teoría, esto cambió. Pero, en la práctica, aún vemos equipos trabajando en silos, sin entenderse del todo.

También me habló de un error común: pensar que el delivery es solo cosa de desarrollo. En realidad, entregar producto es una misión de equipo, y cuando no se entiende así, empiezan los problemas.

Aquí Raúl usó una metáfora que me pareció muy acertada: en un equipo de fútbol, defender no es solo tarea de los defensas. Si el equipo entero no colabora en la defensa, tarde o temprano recibirán goles. Lo mismo pasa en los equipos de producto: si desarrollo y producto no trabajan juntos en la entrega, el resultado será un caos. Todos deben asumir la responsabilidad del éxito del producto, sin delegar completamente en el otro equipo.

Velocidad vs. Calidad: ¿Se puede tener todo?

Uno de los grandes conflictos entre producto y desarrollo es el equilibrio entre ir rápido y hacer las cosas bien.

Raúl lo dejó claro: la calidad es lo que te permite ir rápido a largo plazo. Un equipo que construye con calidad desde el principio evita problemas futuros, reduce la deuda técnica y puede moverse con más agilidad. Pero claro, eso implica tomar buenas decisiones sobre cuándo y cómo asumir deuda técnica.

Aquí soltó una comparación que me encantó: la deuda técnica es como una deuda financiera. Si la usas bien, te da un impulso; si abusas de ella, acabas ahogado.

Cómo mejorar la colaboración entre producto y desarrollo

Si tuviera que quedarme con tres ideas clave de la entrevista, serían estas:

* Construir un equipo de verdad. No basta con juntar a product managers y desarrolladores en la misma reunión. Hay que generar confianza, empatía y propósito compartido.

* Los desarrolladores deben entender negocio y los PMs tecnología. Si cada equipo solo habla su propio idioma, la comunicación se rompe. Raúl insiste en que los ingenieros deberían hablar con usuarios y los PMs deberían entender las implicaciones técnicas de sus decisiones.

* Eliminar la mentalidad de silos. Producto no es el enemigo de desarrollo y viceversa. Los mejores equipos trabajan con una visión común y desafían mutuamente sus ideas para llegar a mejores soluciones.

Raul ha sacado un playbook sobre como escalar tu equipo que es una pasada! Echale un ojo aquí!

Si alguna vez has sentido fricción entre producto y desarrollo en tu empresa, te recomiendo que veas la entrevista completa. Hay ideas súper valiosas para cualquier equipo que quiera trabajar mejor y entregar producto sin tanto drama.

🔗 Mira la entrevista completa aquí:

→ ¿Te gusta el contenido? Suscríbete a mi canal de YouTube y apoya al podcast.

→ ¿Quieres venir a hablar al podcast? Contesta a este email.

Si hay un conflicto que se repite en casi todas las empresas de producto, es el de marketing contra producto. Dos mundos que deberían estar alineados y, sin embargo, muchas veces parecen rivales en una pelea de egos y prioridades. Para hablar de esto, me senté con Luis Encabo, un experto en marketing y ventas con experiencia en empresas como ThePowerMBA, además de haber montado su propia agencia. Y, como era de esperar, la conversación fue directa, sin filtros y con algún que otro momento de "tensión divertida".

¿Por qué nos llevamos mal?

Empezamos con una pregunta directa: ¿Por qué hay tantas fricciones entre marketing y producto? Según Luis, la clave está en que muchas veces no hablamos el mismo idioma. Marketing se enfoca en la captación y en vender, mientras que producto quiere construir con lógica y sin promesas excesivas. Y aquí viene la pregunta clave: ¿quién tiene razón?

Luis no se anduvo con rodeos: ambos fallan. Si producto no comunica bien lo que está construyendo y sus limitaciones, marketing improvisa y vende cosas que no existen (o que no funcionan como deberían). Si marketing no entiende bien el producto, crea mensajes vacíos que no generan ventas.

El mito del "marketing vende humo"

Uno de los puntos que más me interesaba discutir con Luis era este mito recurrente: Marketing promete cosas que producto no puede entregar. Y su respuesta fue clara: no es que marketing "venda humo", es que muchas veces no tiene la información necesaria para saber qué puede vender de verdad.

Aquí es donde las empresas que mejor funcionan marcan la diferencia: producto y marketing tienen que trabajar juntos desde el inicio. Si el equipo de marketing no conoce bien el producto y lo que realmente aporta al usuario, está condenado a generar mensajes irrelevantes o que no convierten.

¿Cómo solucionamos esta guerra eterna?

Le pedí a Luis consejos prácticos para que producto y marketing dejen de ser rivales y empiecen a remar juntos. Su respuesta se puede resumir en tres puntos clave:

* Marketing y producto deben entenderse mutuamente. Si trabajas en marketing, habla con el equipo de producto y prueba el producto. Si trabajas en producto, involúcrate en las estrategias de captación y conversión.

* Sesiones de trabajo conjuntas. No vale con enviar un brief o un documento por Notion. Hace falta sentarse juntos y entender cómo alinear los objetivos.

* Validación constante. No lances funcionalidades sin saber cómo se van a comunicar. No hagas campañas sin estar seguro de que el producto lo respalda.

¿Cuándo entra marketing en el desarrollo de producto?

Otro debate interesante fue el de cuándo es el momento adecuado para que marketing se involucre. ¿Desde el día uno o cuando ya hay algo tangible? Luis lo tiene claro: cuanto antes, mejor. Y puso un ejemplo brutal: hoy en día, con herramientas como Facebook Ads, puedes validar una idea sin necesidad de desarrollar el producto. ¿Por qué esperar meses para saber si algo interesa al mercado?

En resumen, marketing y producto no son equipos separados. Son dos partes de la misma ecuación y, si no trabajan juntos, el resultado será siempre el mismo: mala comunicación, clientes confundidos y oportunidades perdidas.

Si te ha parecido interesante esta conversación, te recomiendo que veas el episodio completo en YouTube. Luis compartió ejemplos muy concretos y consejos prácticos que seguro pueden ayudarte a mejorar la relación entre marketing y producto en tu empresa.

→ ¿Te gusta el contenido? Suscríbete a mi canal de YouTube y apoya al podcast.

→ ¿Quieres venir a hablar al podcast? Contesta a este email.