El AI Mercadona User Story Framework — Visión General (Artículo 1 de 7)
Serie Gemba: Cómo construimos un framework con IA para transformar PRDs en backlogs de calidad en Mercadona Tech
Este es el artículo 1 de 7 en la serie “Gemba” sobre el AI Mercadona User Story Framework.
Introducción: El Dilema del Product Manager en Mercadona Tech
En Mercadona Tech, gestionamos doce verticales de producto que cubren prácticamente todos los aspectos de la operación de la compañía. Desde el checkout y tienda online, pasando por logística, flota, almacenes y última milla, hasta sistemas internos de recursos humanos y planificación de ventas. Cada vertical es compleja, con centenares de historias de usuario que fluyen a través del pipeline de desarrollo.
Los Product Managers de Mercadona enfrentan una paradoja moderna: están más ocupados escribiendo historias que entendiendo usuarios. El día se consume en redactar especificaciones, refinar criterios de aceptación, negociar con ingeniería sobre el alcance. Pero el verdadero valor del PM—entender los problemas del negocio, hablar con clientes, detectar oportunidades, tomar decisiones estratégicas—queda relegado a momentos robados entre reuniones.
Esta realidad nace de un problema estructural. Cada PRD (Product Requirements Document) que llega al equipo de producto requiere una transformación manual: se debe analizar el problema, investigar qué está faltando, generar hipótesis sobre qué quieren realmente los usuarios, fragmentar ese trabajo en historias pequeñas y deployables, evaluar si las historias resultantes son de calidad. Todo esto, antes de que un ingeniero escriba una línea de código.
El resultado es un cuello de botella silencioso. Los sprints no avanzan al ritmo que podrían. Las historias contienen inconsistencias porque los PMs escriben bajo presión. Se descubren gaps fundamentales cuando ingeniería intenta construir. Los stakeholders esperan con incertidumbre mientras el equipo de producto intenta cumplir.
Hace aproximadamente seis meses, decidimos experimentar. En lugar de contratar más PMs o aceptar que esto era simplemente “el costo de hacer negocio”, preguntamos: ¿Y si pudiéramos automatizar las partes rutinarias de este proceso? ¿Y si un sistema de IA pudiera hacer el trabajo mecánico—evaluar calidad de PRDs, detectar gaps, diseñar investigación, escribir borradores de historias—de modo que nuestros PMs recuperaran tiempo para lo que realmente importa?
Así nació el AI Mercadona User Story Framework, un sistema inteligente en seis módulos diseñado para asistir a los PMs, no para reemplazarlos. Este marco utiliza técnicas avanzadas de investigación de usuarios (Mom Test), Jobs-to-be-Done, patrones de escritura de historias de clase mundial, y scoring dimensional para ayudar a convertir PRDs en backlogs de calidad consistentemente alta.
Este artículo presenta la visión general del framework, cómo surgió, por qué cada módulo existe, y cómo juntos crean un nuevo modelo de trabajo para el product management. Los siguientes artículos profundizarán en cada uno de los seis módulos, mostrando ejemplos reales, casos de uso, y cómo los PMs pueden integrar esta herramienta en su día a día.
El Problema: La Brecha entre PRD y Backlog de Calidad
Antes de entender la solución, es importante clarificar el problema con precisión. En Mercadona Tech, cuando un PRD llega al equipo de producto, típicamente incluye una descripción del problema que se quiere resolver, contexto de negocio sobre qué objetivo estratégico respalda este trabajo, algunos requisitos funcionales o puntos de alcance, y a veces un diagrama o flujo de usuario.
Lo que rara vez incluye es evidencia real de que hemos entendido el problema desde la perspectiva del usuario. No hay investigación con usuarios reales. No hay hipótesis validadas sobre qué comportamiento queremos cambiar. No hay descomposición clara de lo que es un trabajo deployable versus lo que es demasiado grande para un sprint.
Los PMs heredan este PRD y comienzan el trabajo de transformación manual. Primero, intentan evaluar si el PRD está lo suficientemente bien definido para pasar a ingeniería. Si no, hay que rellenar gaps. Luego, diseñan una investigación informal (a menudo solo conversando con stakeholders, no con usuarios finales). Con esa investigación, generan hipótesis sobre qué beneficios buscan los usuarios. A continuación, escriben las historias de usuario, intentando separar el problema (JTBD) de la solución propuesta, asegurarse de que cada historia implique un cambio de comportamiento observable, y que sean lo suficientemente pequeñas como para ser completadas en un sprint.
Finalmente, deben validar que las historias sean de calidad—que no sean genéricas, que tengan criterios de aceptación claros, que sean independientes de otras historias, que no sean demasiado grandes ni demasiado pequeñas.
Este proceso, cuando se hace bien, toma entre 20 y 40 horas de trabajo del PM. Cuando se hace mal—cosa que ocurre bajo presión de tiempo—resulta en historias que ingeniería no puede ejecutar, que falta contexto, que tienen criterios de aceptación vagos, o que son tan grandes que requieren subsplitting en el medio del sprint.
Multiplicado por doce verticales, decenas de PRDs por trimestre, y el hecho de que nuestros mejores PMs son buscados constantemente para opiniones estratégicas, el resultado es un sistema crónicamente bajo de capacidad para hacer este trabajo bien.
La Hipótesis: Automatizar lo Rutinario, Liberar el Juicio
Nuestra hipótesis era simple pero radical: la mayoría de este trabajo no requiere un PM humano. Requiere inteligencia, pero no juicio humano. Un sistema de IA, entrenado en patrones de excelencia en product management, podría hacer el 70-80% del trabajo de forma completamente automática, con calidad consistente, eliminando variación y permitiendo que nuestros PMs usen su tiempo para las cosas que realmente requieren juicio: hablar con usuarios, entender el contexto competitivo, tomar decisiones sobre priorización y trade-offs.
El concepto central es que un PM moderno no debería ser un “escritor de historias”. Debería ser un “investigador de problemas y tomador de decisiones”. La IA puede ser el escriba, el revisor, el detector de inconsistencias. El PM puede ser el líder que formula preguntas, valida hipótesis, y aprueba o rechaza las propuestas que la IA genera.
Para esto, construimos seis módulos que juntos forman un pipeline coherente: cada uno tiene una responsabilidad clara, pero todos ellos se retroalimentan. Si el PRD es de mala calidad, el Quality Guard lo detecta temprano. Si la investigación encuentra gaps, se generan preguntas de Mom Test. Si las historias resultantes no son de calidad, el Quality Coach las rechaza. Todo el sistema está diseñado para mantener un estándar consistente de excelencia.
Los Seis Módulos: Arquitectura del Framework
1. Quality Guard: La Frontera de Calidad
El primer módulo, Quality Guard, cumple una función crítica: actúa como guardaespaldas de calidad en la frontera entre proceso de producto y equipo de ingeniería. Su responsabilidad es evaluar si un PRD está suficientemente bien definido para pasar a trabajar en historias.
Quality Guard opera bajo la premisa de que es más económico rechazar un PRD de baja calidad temprano que invertir decenas de horas de PM en transformarlo. Por eso analiza el PRD en tres dimensiones:
La dimensión de completitud del problema: Quality Guard verifica que el PRD articule claramente cuál es el problema que se quiere resolver. No lo que quieres construir, sino el problema real. Detecta PRDs que son meramente descripciones de features sin raíz en problemas observados. Verifica que hay contexto de por qué este problema importa, qué sucede hoy que es insatisfactorio, quién sufre ese problema.
La dimensión de calidad SOP: Mercadona Tech sabe que muchos problemas de producto no son realmente problemas de producto. Son problemas de proceso, de formación, de herramientas. Quality Guard analiza si el PRD confunde un problema de SOP (procedimiento operativo estándar) con un problema de producto. Quality Guard detecta estos escenarios y genera un documento de handoff para que el equipo de procesos lo maneje, no el equipo de producto.
La dimensión de separación QUÉ/CÓMO: Un PRD de calidad articula claramente qué problema queremos resolver sin prescribir cómo debe hacerlo. Muchos PRDs incurren en el error de llegar con solución propuesta ya decidida. Quality Guard analiza si hay una separación clara entre el problema y la solución, si se deja espacio para que ingeniería diseñe cómo construir esto.
Cuando Quality Guard rechaza un PRD, no es un rechazo definitivo. Genera un documento de retroalimentación clara indicando qué falta, qué está mezclado, qué debería ser un proyecto de proceso en lugar de producto. Cuando aprueba, le da paso al siguiente módulo con una evaluación de riesgos.2. Research & JTBDs: De la Incertidumbre a la Evidencia
Una vez que Quality Guard aprueba un PRD, comienza el trabajo de Research & JTBDs (Jobs-to-be-Done). Este módulo tiene dos responsabilidades entrelazadas: primera, detectar qué falta en nuestro entendimiento del problema; segunda, generar investigación validada que nos diga qué trabajo necesitan hacer realmente los usuarios.
El módulo comienza analizando el PRD y haciendo la pregunta fundamental: ¿Qué asunciones tenemos sobre este problema que aún no hemos validado? Genera una lista de gaps. Una vez identificados, diseña un plan de investigación utilizando la metodología Mom Test de Rob Fitzpatrick. El Mom Test enseña a hacer preguntas que revelan verdades, no soluciones. En lugar de preguntar “¿Te gustaría un dashboard de combustible?”, se pregunta “¿Cuándo fue la última vez que quisiste saber cuánto combustible consumiste? ¿Qué intentaste hacer? ¿Cómo lo resolviste?”
Con esa evidencia, el módulo genera Jobs-to-be-Done estructurados con evidencia real: Job Performer específico, trigger concreto, struggle documentada con citas, outcome deseado, tres dimensiones de motivación (funcional, emocional, social) y ansiedades y barreras.
3. JTBD to Stories: La Transformación Estructurada
Con JTBDs validados en mano, el módulo JTBD to Stories se dedica a la transformación estructurada que convierte trabajos deseados en historias de usuario deployables. Aplica tres frameworks integrados: el JTBD Reforzado (con struggle, trigger, outcome y tres dimensiones de motivación), la Wendel Checklist (cuatro preguntas obligatorias sobre experiencia previa, relación con producto, motivación situacional e impedimento actual), y el Cambio de Comportamiento (START/STOP/DIFFERENT con rangos cuantificados).
Cada historia recibe un scoring de seis dimensiones y el output se estructura en tres niveles: Epic (visión estratégica), Features (2-5 capacidades) y Stories (implementables en 1-2 sprints) con criterios de aceptación Given-When-Then derivados de comportamientos observados.4. Quality Coach: Evaluador de Excelencia
Después de que las historias son generadas y refinadas, el módulo Quality Coach actúa como evaluador de calidad final. Su responsabilidad es asegurar que las historias resultantes no solo sean funcionales, sino que sean de clase mundial. Quality Coach evalúa cada historia contra la métrica de seis dimensiones, pero también detecta siete antipatrones comunes: el usuario genérico (”Como usuario quiero...”), la ausencia de cambio de comportamiento, la historia falsa (tarea técnica disfrazada), la solución como necesidad, el entregable fuera de zona de control, el “todo urgente”, y el splitting horizontal por capas técnicas.
Para cada story que puntúa bajo, el módulo ofrece una versión reescrita en formato JTBD. No como imposición sino como sugerencia que el PM puede adoptar, adaptar o descartar.
5. Story Splitting (Eduardo Ferro): La Descomposición Experta
El módulo Story Splitting, basado en la metodología de Eduardo Ferro (@eferro), detecta stories demasiado grandes y las descompone en incrementos que cumplen tres condiciones: ser independientemente valiosos, desplegables por separado y completables en 3 días o menos. Aplica nueve heurísticas de splitting: comenzar por outputs, estrechar segmento, extraer utilidad básica, de dummy a dinámico, simplificar outputs, dividir por capacidad, dividir por ejemplo, learning vs earning, y ponerla en muletas.
La base teórica es el concepto de “experimento sobrevivible”: cada story debe poder fallar sin consecuencias graves. Una regla fundamental: los splits deben ser siempre verticales, nunca horizontales.
6. Story Builder: El Asistente Conversacional
El sexto módulo, Story Builder, es un asistente conversacional para PMs que quieren crear historias desde cero, sin partir de un PRD estructurado. Guía al PM a través de un diálogo en 6 fases: contexto inicial (con detección de “trampa de solución”), descubrir el Job (técnica del ¿Por Qué?), Wendel Checklist, tres dimensiones del trabajo, cambio de comportamiento cuantificado, y story completa en formato JTBD Reforzado.
Lo poderoso de Story Builder es que democratiza la escritura de historias y tiene un efecto formativo: después de varias sesiones, los PMs internalizan las preguntas y mejoran su criterio incluso sin la herramienta.
El Corazón del Framework: Scoring Dimensional Unificado
Corriendo a través de todos los seis módulos hay un lenguaje común: el scoring dimensional de seis dimensiones. Este es el nervio central que conecta todos los módulos y asegura que toda la evaluación de calidad sea coherente.
Las seis dimensiones son: Contexto JTBD (¿hay evidencia cualitativa y cuantitativa del problema?), Especificidad del Usuario (¿responde a las 4 preguntas del Wendel Checklist?), Cambio de Comportamiento (¿qué va a hacer el usuario de forma diferente y está cuantificado?), Zona de Control (¿el equipo controla el entregable?), Restricciones Temporales (¿la urgencia es real o artificial?), y Experimento Sobrevivible (¿qué pasa si nos equivocamos?).
Cada dimensión se puntúa de 0 a 10. Lo importante es que este scoring no es arbitrario. Está basado en décadas de investigación en product management, en patrones de historias de usuarios extraordinarias, y en lo que hemos aprendido en nuestras propias doce verticales.
Filosofía: PM Como Investigador y Tomador de Decisiones
En el fondo, el AI Mercadona User Story Framework está basado en una filosofía sobre qué debe ser el product management moderno. No creemos que un PM sea un “escritor de historias”. Una historia es un artefacto. Lo que importa es el pensamiento que la precede. Los grandes PMs son investigadores de usuarios, descubridores de oportunidades, y tomadores de decisiones bajo incertidumbre.
Este framework invierte esa relación. Usa IA para hacer el acto de escribir automático, permitiendo que el PM se enfoque en lo que realmente importa: entender el problema. Pasa el 80% de tu tiempo investigando, hablando con usuarios, entendiendo contexto. El 20% que antes gastabas escribiendo historias, ahora úsalo para refinar lo que la IA sugiere.
El Futuro: PM + IA, No PM O IA
Un PM sin IA disponible está constantemente bajo presión de tiempo. Escribe historias rápido porque hay muchas. Esas historias terminan siendo genéricas, con antipatterns, inconsistentes en calidad. El PM no tiene tiempo de investigar realmente.
Un PM con IA disponible puede hacer las cosas que realmente importan. Pasar tiempo en Gemba—ir donde ocurre el trabajo real. Hablar con conductores de flota sobre cómo toman decisiones. Observar gerentes de almacén en un cambio de turno. Entender frustración en tiempo real. Luego volver y decir a la IA: “Esto es lo que vi, genera historias alrededor de estos trabajos deseados.”
Hemos visto esto en nuestras primeras implementaciones. Los PMs que han abrazado el framework reportan que dedican 15-20% más tiempo a hablar con usuarios. Sus backlogs tienen 40% menos incidentes relacionados con historias mal definidas. Los sprints son más predecibles.
Conclusiones: El Viaje Comienza
El AI Mercadona User Story Framework no es una solución a un problema de “escribir historias de usuario”. Es una solución a un problema mucho más profundo: cómo puede la industria de product management escalar cuando hay más complejidad de la que un número finito de PMs puede gestionar.
Los seis módulos trabajando juntos—Quality Guard asegurando que PRDs sean sólidos, Research & JTBDs trayendo evidencia de usuario, JTBD to Stories transformando investigación en especificaciones, Quality Coach asegurando excelencia, Story Splitting creando backlogs ejecutables, Story Builder democratizando la creación—forman un ecosistema coherente de product excellence.
En los artículos siguientes de esta serie, exploraremos cada módulo en profundidad. Veremos ejemplos reales de cómo se ve cuando cada módulo trabaja. Compartiremos los patrones que hemos codificado, las métricas que importan, los casos de uso donde el framework agrega más valor.
El product management en Mercadona Tech está en transición. De un modelo donde PMs son principalmente escritores de historias, a un modelo donde PMs son investigadores respaldados por inteligencia artificial. Mercadona Tech está en el Gemba de esa transformación. El viaje apenas comienza.
Gracias por compartir, muchas ganas de ir entendiendo todo este proceso.
Súper didáctico para ir entendiendo un poco mejor toda esta época de cambio. Das muchas señales entre tanto ruido 👌🏻