Story Builder: Construir Historias desde Cero con Rigor (Artículo 7 de 7)
Serie Gemba: AI Mercadona User Story Framework — La herramienta conversacional que cierra el ciclo del framework completo
Este es el séptimo y último artículo de una serie de 7 sobre el AI Mercadona User Story Framework. Hemos recorrido el Quality Guard, que validaba la solidez de nuestras investigaciones. Pasamos por Research & JTBDs, el corazón investigativo del framework. Luego vimos cómo transformar esos JTBDs en historias de usuario con rigor en JTBD to Stories. Conocimos el Quality Coach, que evaluaba nuestro trabajo con seis dimensiones de calidad. Exploramos Story Splitting, el arte de fragmentar historias complejas en incrementos entregables. Ahora cerramos con el módulo que completa el framework: el Story Builder, la herramienta conversacional que permite construir historias de usuario de calidad sin necesidad de un PRD completo.
El Story Builder representa algo fundamental en la evolución del trabajo del Product Manager en Mercadona Tech. No es simplemente otra herramienta más. Es el reconocimiento de que no toda buena idea comienza con un documento formal. Es el puente entre el pensamiento rápido y la creación estructurada.
La Realidad que El Story Builder Resuelve
Cuando pensamos en cómo se generan las historias de usuario en una organización como la nuestra, es fácil asumir que todo comienza en un PRD bien estructurado. Que cada idea pasa por research, que cada problema viene documentado con datos y contexto. Pero la verdad es más matizada.
La verdad es que muchas de las mejores ideas surgen en conversaciones espontáneas. Un PM está en una reunión de planificación y alguien menciona un problema que ha visto repetidamente. Un stakeholder en un comité ejecutivo describe una fricción que existe en el sistema. Un cliente más grande reporta una ineficiencia que mata su productividad. El gerente de un almacén regional cuenta cómo sus equipos están desperdiciando tiempo en una tarea repetitiva. No hay PRD. No hay investigación formalizada. Hay un problema real, urgente, que merece atención inmediata.
En estas situaciones, los PMs se enfrentan a un dilema. Por un lado, el rigor que el framework exige es importante: necesitamos evidencia, necesitamos entender el contexto del usuario, necesitamos validar que estamos atacando un problema real y no una solución en busca de propósito. Por otro lado, la velocidad también importa. No queremos que la burocracia del proceso impida que ideas válidas lleguen al desarrollo.
Story Builder resuelve este dilema. Es la herramienta conversacional que permite a un PM con una idea, un problema detectado en el terreno, o una conversación reciente, transformar eso en una historia de usuario de calidad sin pasar por todo el pipeline formal. Pero —y esto es crítico— sin reducir la calidad ni las exigencias del framework.
La Base Teórica Sigue Siendo La Misma
Lo primero que es importante entender es que Story Builder no inventa una nueva metodología. Utiliza exactamente la misma base teórica que todos los módulos anteriores del AI Mercadona User Story Framework: Jobs to Be Done, el checklist de Wendel, y el análisis de cambio de comportamiento.
Lo que cambia es el punto de entrada. En el pipeline completo del framework, comenzamos con un PRD (o lo que en nuestros documentos internos llamamos DAPP). El Quality Guard la examina. Research & JTBDs descubre o refina los trabajos implícitos. Esos JTBDs validados se transforman en historias. El Quality Coach las evalúa. Story Splitting las organiza en entregas. Es un flujo lineal, casi una cadena de montaje de calidad.
Story Builder invierte el proceso. No comienza con un documento. Comienza con una persona que tiene una pregunta. Y a través de seis fases bien estructuradas, esa persona articula un problema lo suficientemente bien como para que los desarrolladores entiendan exactamente qué necesitan construir. La rigor viene en las preguntas, no en el documento de entrada.
Esta es una diferencia sutil pero profunda. Porque significa que el framework no es un procedimiento que requiere documentación previa. Es un conjunto de principios que pueden aplicarse conversacionalmente.
Las Seis Fases de Story Builder
Fase 1: Contexto Inicial — La Trampa de la Solución
Todo comienza con una pregunta simple: “¿Qué problema quieres resolver? ¿Para qué producto?”
Pero aquí es donde ocurre algo extraordinario. Muy frecuentemente, el PM responde algo como: “Quiero agregar un botón de filtrado”, o “Necesito una nueva columna en la tabla”, o “Debemos integrar con el sistema de CRM”.
El Story Builder hace algo que parece contradictorio: rechaza la respuesta. No rechaza el problema, sino la forma en que ha sido expresado. El módulo responde: “Veo que tienes una solución en mente. Pero primero necesito entender: ¿qué problema tiene el usuario que esta solución resolvería?”
Esta detección de la “trampa de la solución” es sorprendentemente común. Los PMs —especialmente aquellos con experiencia técnica o que han estado cerca del desarrollo— tienden a pensar en términos de características y soluciones, no en términos de problemas y trabajos. Es una deformación ocupacional completamente comprensible. Hemos pasado años diciendo “construyamos un filtrado”, así que es natural que los problemas se articulen automáticamente como soluciones.Pero Jobs to Be Done nos enseña que esta forma de pensar es exactamente invertida. El trabajo que el usuario está tratando de hacer existe independientemente de cualquier solución. Y hay múltiples formas de resolver ese trabajo. Si obligamos al PM a pensar en términos de el problema subyacente, abrimos la puerta a innovación, a mejores soluciones, a un entendimiento más profundo.
El Story Builder no permite pasar a la siguiente fase hasta que ha conseguido articular un problema, no una solución. Y lo hace sin hostilidad. Lo hace con la paciencia de un coach que ha visto este patrón cien veces antes.
Fase 2: Descubrir El Trabajo — El Método Del “¿Por Qué?”
Una vez que tenemos un problema articulado, el Story Builder entra en la Fase 2: descubrir el trabajo que el usuario está tratando de hacer.
Esta fase utiliza la técnica del “¿Por qué?” a tres, cuatro, o incluso cinco niveles de profundidad. Es la técnica clásica de investigación cualitativa, pero automatizada de una manera que es pedagógica.
Funciona así: el PM dice algo como “Nuestros usuarios quieren filtrar productos más rápido”. El Story Builder pregunta: “¿Por qué es importante que encuentren productos rápido?” La respuesta podría ser: “Porque se aburren y abandonan la sesión”. Entonces: “¿Por qué abandonarían la sesión? ¿Qué hay en juego?” “Porque están haciendo su compra semanal y tienen prisa, o porque se cansaron de desplazarse”. Y así sucesivamente.
Después de cinco minutos de este diálogo, lo que emergió es diferente de donde empezó. No es “agregar filtros”. Es “ayudar a los usuarios a completar su compra semanal de manera eficiente”. O quizás: “Permitirles acceder únicamente a los productos que realmente necesitan, ahorrándoles decisiones cognitivas”. O incluso: “Ayudarles a sentirse en control de una cantidad abrumadora de opciones”.
Cada uno de estos es un “trabajo” diferente. Y cada uno podría resolverse de múltiples maneras. El filtrado es una solución para algunos. Una lista de “mis productos habituales” podría ser la solución para otros. Un carrito inteligente que aprende con el tiempo sería la solución para otros.
El Story Builder tiene una prueba de validación para asegurarse de que realmente has descubierto un trabajo y no solo una solución reformulada: ¿puede este trabajo ser implementado de múltiples formas? Si la respuesta es sí, entonces es un trabajo. Si solo hay una forma de hacerlo, entonces probablemente sigue siendo una solución disfrazada de trabajo.
Fase 3: El Checklist De Wendel — Haciendo Específico Lo General
Ahora tenemos un trabajo. Pero “los usuarios quieren completar su compra rápida” es todavía demasiado general. ¿Qué usuarios? ¿Bajo qué circunstancias? ¿Con qué contexto?
La Fase 3 introduce el checklist de Wendel, que consta de cuatro preguntas mandatorias que deben responderse con datos concretos y específicos:
Primera pregunta: Experiencia previa. ¿Es este un trabajo nuevo o recurrente? ¿Cuánto tiempo llevan usando el producto? ¿Han intentado resolver este trabajo antes de otras maneras?
Segunda pregunta: Relación con el producto. ¿Cómo interactúan hoy con el producto? ¿Es su primer contacto o son usuarios veteranos? ¿Lo usan diariamente o ocasionalmente?
Tercera pregunta: Motivación situacional. ¿Qué los impulsa en ESTE momento? ¿Hay presión de tiempo? ¿Hay consecuencias por no lograr el trabajo? ¿Es voluntario u obligatorio?
Cuarta pregunta: Impedimento actual. ¿Qué específicamente les está impidiendo lograr el trabajo ahora mismo? ¿Es un problema técnico, cognitivo, de diseño?
Si el PM responde con generalidades —”todos nuestros usuarios”, “la mayoría de personas que compran”— el Story Builder rechaza y pide especificidad. “Eso es demasiado amplio. Necesito entender exactamente quién tiene este trabajo. ¿Es el cliente ocasional que viene cada dos semanas? ¿Es la ama de casa que compra para su familia? ¿Es el restaurante que compra para abastecer su cocina?”
Esta insistencia en la especificidad es lo que separa una historia de usuario útil de una que suena bien pero es imposible de desarrollar. Porque un desarrollador necesita saber: ¿para quién estoy construyendo esto? ¿En qué contexto? ¿Con qué limitaciones?
Si dices “como usuario” sin más, el checklist de Wendel rechaza la respuesta. Te obliga a ser específico.
Fase 4: Las Tres Dimensiones Del Trabajo
Ahora el Story Builder te lleva a la Fase 4, donde las cosas se ponen más interesantes. Porque un trabajo humano no es solo una tarea funcional. Tiene tres dimensiones.
La dimensión funcional es la más obvia. Es la tarea práctica que necesitan accomplir. Encontrar productos rápido. Completar la compra. Pagar. Recibir su pedido. Estas son las cosas medibles, las cosas que los desarrolladores pueden construir.
Pero luego está la dimensión emocional. ¿Cómo quieren sentirse? ¿Quieren sentirse en control? ¿Organizados? ¿Tranquilos de que están tomando buenas decisiones? ¿Confiados de que no se olvidan nada? ¿Seguros de que están obteniendo buen valor?
Y finalmente la dimensión social. ¿Cómo quieren ser percibidos? ¿Quieren parecer eficientes? ¿Responsables? ¿Sofisticados? ¿Atentos a los detalles?Estas tres dimensiones existen simultáneamente. Y la experiencia más potente ocurre cuando un producto resuelve las tres. No solo permite que la tarea sea completada (funcional), sino que hace que el usuario se sienta bien mientras la hace (emocional) y lo hace parecer bien (social).
Muchas historias de usuario se quedan atrapadas únicamente en la dimensión funcional. “Como usuario, quiero filtrar, para encontrar productos más rápido”. Es técnicamente correcta. Pero pierdes la motivación más profunda. El desarrollador no entiende realmente por qué importa esto. Y entonces no optimiza para las experiencias que harían que el usuario se sienta en control o que lo hiciera parecer eficiente.
El Story Builder te obliga a explorar las tres dimensiones. Y luego, como bonus, te hace pensar en las ansiedades y las barreras. ¿Qué temores tienen los usuarios? ¿Qué podría evitar que adopten esta característica incluso si funciona perfectamente?
Por ejemplo, alguien podría tener miedo de que los filtros sean tan complejos que sean más confusos que la búsqueda manual. O miedo de que el sistema filtre incorrectamente y pasen por alto algo que necesitaban. Estas ansiedades son reales. Y ignorarlas significa que construirás una característica que funciona pero que nadie usa.
Fase 5: Cambio De Comportamiento — Del Ahora Al Nuevo
Aquí es donde la historia de usuario se vuelve medible. El Story Builder te obliga a pensar en: ¿cómo cambiaría el comportamiento del usuario si logras resolver este trabajo?
Esto no es teórico. Es cuantificado. Tiene rangos.
El usuario está haciendo algo hoy de una cierta manera. El “ahora” es medible. Quizás: buscar productos en su carrito de compra semanal toma doce minutos. Quizás toman treinta y cinco decisiones sobre qué productos incluir o excluir. Quizás tienen una tasa de abandono de veinte por ciento.
Cuando resuelvens el trabajo con éxito, hay un “nuevo” comportamiento. Y ese nuevo comportamiento tiene tres rangos:
Mínimo: El umbral por debajo del cual el usuario estaría decepcionado. Para la búsqueda de productos, quizás: ocho minutos y cuarenta segundos. Ese es un treinta por ciento de mejora. No es espectacular, pero es notabilidad. Es suficiente para que el usuario piense: “Sí, esto es un poco mejor”.
Target: El resultado realista y deseable. Quizás: seis minutos. Una mejora del cincuenta por ciento. Aquí es donde realmente sientes que algo cambió. Tu compra semanal es notablemente más rápida.
Over-top: El resultado excepcional, la “vaya, esto es increíble” versión. Quizás: tres minutos y treinta y seis segundos. Una mejora del setenta por ciento. Tu compra que solía tomar el tiempo de un café ahora toma lo que cuesta pagar. Es transformador.
Estos rangos no son arbitrarios. Son validados contra datos reales. Contra el comportamiento actual. Contra benchmarks de soluciones comparables. Contra lo que los usuarios mismos dicen cuando se les pregunta: “¿Cuánto tiempo sería suficientemente rápido?”
El Story Builder insiste en estos números porque son lo que le permite al equipo de producto entender realmente si el trabajo está siendo resuelto. No es: “¿Funciona el filtrado?” Es: “¿Los usuarios pueden ahora encontrar un producto en menos de nueve segundos?” Eso es verificable. Eso es medible. Eso es lo que importa.
Fase 6: La Historia Completa En Formato JTBD Reforzado
Cuando has pasado por las cinco fases anteriores, la Fase 6 es casi ceremonial. El Story Builder te entrega una historia de usuario completa, pero no en el formato anticuado de “como [usuario], quiero [característica], para [beneficio]”.
Es una historia completa en lo que el framework llama “formato JTBD Reforzado”. Contiene:
El trabajo articulado de manera clara y específica
El usuario específico con los cuatro elementos del checklist de Wendel completamente rellenos
Las tres dimensiones del trabajo (funcional, emocional, social)
Las ansiedades y barreras identificadas
El cambio de comportamiento cuantificado con los tres rangos (mínimo, target, over-top)
Los criterios de Given-When-Then: la secuencia de eventos que debe ocurrir para que el usuario complique su trabajo
La puntuación de 6D: cada historia se evalúa exactamente con las mismas seis dimensiones que todas las otras historias del framework
No hay atajos. La calidad es idéntica a la de una historia que vino de un PRD completo que pasó por todo el pipeline. Porque el rigor no vino del documento. Vino de las preguntas.
El Módulo No Te Permite Saltarte Pasos
Un aspecto del Story Builder que algunos PMs encuentran inicialmente frustrante es su inflexibilidad. El módulo no te permite saltarte fases. No puedes estar en la Fase 2 y pensar “ya he respondido esto, déjame pasar a la Fase 5”. No. El módulo es demandante. Es pedagógico. Es —podríamos decir— un poco obstinado.
Pero esta obstinación tiene un propósito. Porque lo que descubrimos en los primeros proyectos piloto fue que cuando los PMs podían saltarse pasos, lo hacían. Y invariablemente, cuando la historia llegaba a desarrollo, faltaba contexto crítico. Nadie había pensado realmente en las ansiedades del usuario. O no había claridad sobre las tres dimensiones del trabajo. O el cambio de comportamiento era vago.
Entonces el Story Builder fue diseñado para ser imposible de saltarse. Cada fase desbloquea la siguiente. Si no respondes la pregunta de la Fase 3 con suficiente especificidad, no puedes avanzar. Punto.
Esto es frustrante durante quince minutos. Y entonces se vuelve revelador.
El Efecto Formativo — La Verdadera Razón De Existencia De Este Módulo
Aquí está el insight clave que separa a Story Builder de ser simplemente otra herramienta de generación de contenido: el efecto formativo.
Después de usar Story Builder varias veces, algo cambia en cómo el PM piensa sobre los problemas. Ya no necesita que la IA le pregunte “¿cuál es el impedimento actual?” porque automáticamente se encuentra pensando en ello cuando alguien describe un problema. Ya no olvida preguntar sobre las dimensiones emocionales y sociales porque ha internalizado que un trabajo humano es tridimensional.
El módulo se vuelve gradualen dispensable. No porque haya generado contenido, sino porque ha cambiado la forma en que su usuario piensa.
Esto es lo que diferencia a un asistente de IA de un copiloto real. Un asistente genera salida. Un copiloto cambia cómo piensas sobre la entrada.
Un asistente te ahorra tiempo escribiendo. Un copiloto te hace ser mejor en tu trabajo. Y la verdadera medida del éxito no es cuántas veces lo usas, sino cuántas veces no lo necesitas porque has internalizado el modo de pensar que enseña.
Los PMs que han utilizado Story Builder durante dos meses en Mercadona Tech reportan algo similar: que las reuniones con stakeholders se sienten diferentes. Que naturalmente hacen preguntas más profundas. Que se sienten más seguros diciendo “no creo que eso sea realmente el problema que necesitamos resolver” porque pueden articular por qué. Que tienen más conversaciones sobre el contexto emocional y social de las decisiones de los usuarios, no solo la lógica funcional.
Eso es el efecto formativo. Y es potencialmente más valioso que cualquier historia de usuario que el módulo haya generado.
La Puntuación De 6D Sigue Siendo La Misma
Un punto que es importante mencionar explícitamente: cada historia generada por Story Builder es calificada con el mismo sistema de 6D que el resto del framework. No hay excepción. No hay “ya que fue conversacional, podemos relajar los estándares”.
Las seis dimensiones son:
Claridad del Usuario: ¿Sabemos exactamente quién es el usuario y en qué contexto opera?
Profundidad del Trabajo: ¿Entendemos la verdadera necesidad debajo de la característica, o estamos resolviendo una solución?
Especificidad del Comportamiento: ¿Podemos medir si el trabajo está siendo resuelto?
Viabilidad Técnica: ¿Es razonable construir esto con la tecnología disponible?
Alineación Estratégica: ¿Ayuda esto a alcanzar los objetivos del producto y la compañía?
Testabilidad: ¿Podemos diseñar un test que demuestre si esta característica logra su objetivo?
Una historia que viene de un PRD formal tiene que puntuar bien en estas seis dimensiones. Una historia que viene de una conversación de quince minutos en Story Builder también. No hay diferencia. El rigor es consistente.
Esto tiene un efecto importante: significa que Story Builder es genuinamente útil para problemas reales, no solo para brainstorming rápido. No es una herramienta para generar “ideas locas”. Es una herramienta para convertir problemas reales en historias de usuario que pueden ser desarrolladas inmediatamente.
Conclusiones: El Viaje Completo Del Framework
Hemos llegado al final. En estos siete artículos, hemos recorrido la totalidad del AI Mercadona User Story Framework. Comenzamos con Quality Guard, validando la solidez de nuestras investigaciones de usuario. Pasamos a Research & JTBDs, donde descubrimos los trabajos verdaderos que nuestros usuarios estaban tratando de hacer. Vimos cómo JTBD to Stories transformaba esos trabajos en historias de usuario estructuradas. Conocimos al Quality Coach, quien nos enseñaba a evaluar nuestro propio trabajo con rigor. Exploramos Story Splitting, entendiendo cómo particionar el trabajo complejo en incrementos que podían ser entregados en sprints reales. Y finalmente, aquí en este séptimo artículo, hemos visto el Story Builder, que nos permitía comenzar con una conversación en lugar de un documento y terminar con una historia de usuario de calidad idéntica.
¿Qué significa todo esto cuando se ve como un sistema completo?
El AI Mercadona User Story Framework no es un conjunto de herramientas separadas. Es un sistema coherente basado en un conjunto de principios compartidos. Jobs to Be Done no es simplemente una teoría que usamos en Research & JTBDs. Es la lente a través de la cual evaluamos historias en Quality Coach. Es la base sobre la que Story Builder construye sus preguntas. Es lo que nos permite saber que una historia es “realmente buena” en lugar de simplemente “técnicamente correcta”.
El checklist de Wendel no es solo algo que hacemos en Story Builder. Es lo que permite que Quality Coach sepa si tu historia especifica suficientemente al usuario. Es lo que hace que Story Splitting tenga sentido: porque sabemos exactamente para quién estamos dividiendo el trabajo.
Los seis criterios de puntuación son exactamente iguales en todas partes. La calidad de una historia de usuario no depende de cómo entró en el sistema. Depende de si resuelve un trabajo real para un usuario específico de una manera que pueda ser verificada.
Esto tiene implicaciones profundas. Significa que el trabajo del Product Manager no es “crear especificaciones”. Es “descubrir problemas reales y especificar soluciones verificables a esos problemas”. Es investigación, análisis crítico, pensamiento estratégico, y comunicación clara. No es redacción de documentos Word con viñetas.
El framework amplifica eso. No hace que el PM desaparezca. Lo libera del trabajo mecánico de traducir un PRD en historias para que pueda hacer más trabajo de pensamiento. Más investigación. Más conversación con usuarios. Más reflexión estratégica sobre qué problemas merecen ser resueltos. Más tiempo pensando en cómo los equipos de producto deben trabajar en lugar de gastar energía asegurando que las historias tengan la estructura correcta.
Los datos de adopción en Mercadona Tech han sido reveladores. Los equipos que utilizan el framework de manera completa reportan un aumento del diecisiete por ciento en la velocidad de desarrollo. No porque escriban historias más rápido. Sino porque escriben historias que son claras la primera vez. Las preguntas de aclaración durante el refinamiento disminuyen. El trabajo reescrito disminuye. El desarrollo que toma un camino equivocado porque la historia fue ambigua disminuye.
Los PMs reportan que se sienten más confiados en su trabajo. Porque no están dependiendo de su intuición para saber si una historia es “buena”. Tienen criterios. Tienen un sistema. Pueden mirar una historia y saber exactamente cuáles son sus fortalezas y dónde necesita más trabajo.
Los desarrolladores reportan que es más fácil trabajar. Porque las historias especifican lo que importa, no lo que es técnicamente fácil. Porque pueden hacer preguntas de aclaración que tienen respuestas reales, basadas en investigación de usuario, no simplemente en lo que el PM recordaba haber dicho.
Pero el insight más profundo es quizás que el framework es educativo. No es una solución que simplemente se implementa y se olvida. Es algo que los PMs internalizan. A través de la repetición, a través de las preguntas que el framework les obliga a hacer, a través del estándar que el framework establece para la calidad, los PMs se vuelven mejores en su trabajo.
El Story Builder, entonces, no es simplemente la última herramienta. Es la herramienta que cierra el círculo. Porque reconoce que no todos los problemas comienzan con un PRD. Algunos comienzan con una conversación. Y el framework debería ser lo suficientemente flexible para capturar eso, mientras mantiene el mismo rigor.
La verdadera revolución del AI Mercadona User Story Framework no es que exista. Es que es posible ser tanto flexible como riguroso. Es posible acelerar la creación de historias de usuario sin sacrificar la calidad. Es posible usar IA de una manera que amplifique la capacidad humana en lugar de reemplazarla.
El PM del futuro en Mercadona Tech no será el que escriba menos documentos. Será el que piense mejor sobre qué construir y por qué. Será el que pase menos tiempo en la mecánica de escribir especificaciones y más tiempo en investigación de usuario, pensamiento estratégico, y facilitación de decisiones entre equipos. El framework le da el espacio para eso.
Y eso, finalmente, es lo que todo esto ha sido sobre. No sobre historias de usuario. Sobre cómo trabajamos. Sobre cómo creemos que el trabajo de producto debería hacerse en una empresa que entiende que la velocidad sin claridad es simplemente caos con prisa, pero la claridad sin velocidad es un análisis infinito.
El AI Mercadona User Story Framework intenta ser ambos. Claro y rápido. Riguroso y flexible. Científico y accesible. Con esta séptima herramienta, el círculo está completo. Ahora es trabajo nuestro usarlo.