De JTBDs Validados a User Stories: El Arte de No Perder Información (Artículo 4 de 7)
Serie Gemba: AI Mercadona User Story Framework — Tres marcos integrados para traducir research en stories implementables
Introducción: La Brecha de Traducción
Imagina este escenario común en cualquier equipo de producto: Acabas de terminar una ronda de investigación rigurosa con clientes reales. Tienes notas ricas, videos de sesiones, transcripciones de conversaciones donde los usuarios explicaban exactamente qué estaban tratando de lograr, cuándo lo intentaban, qué les frustraba y qué resultados querían ver. Los insights están ahí, tangibles, cargados de contexto.
Entonces llega el momento de escribir las user stories para el sprint. Y aquí es donde sucede algo mágico y terrible a la vez: toda esa riqueza desaparece.
Lo que comenzó como “Una madre que intenta completar su compra mientras sus hijos corren entre los pasillos, y tiene miedo de olvidar items de su lista porque está distraída” se convierte en: “Como cliente, quiero poder acceder a mi carrito rápidamente, para completar mi compra.” El usuario se vuelve genérico. El comportamiento cambia desaparece. La frustración emocional se evapora. Los criterios de éxito se vuelven vagos. Y lo peor: el equipo de ingeniería recibe una descripción de una característica (carrito rápido), no de un resultado que el usuario necesita lograr.
Este es el problema central que resuelve el AI Mercadona User Story Framework en su segundo acto: convertir research validado en stories estructuradas sin perder información.
En este artículo —cuarto de una serie de siete sobre cómo construimos un framework de user stories que honra la research y produce historias implementables— te mostraremos exactamente cómo evitar que tu research valiosa se diluya en el camino hacia el backlog.
Ahora aprenderás tres marcos integrados que, usados juntos, garantizan que nada se pierda en la traducción.
Parte 1: Por Qué la Información se Pierde en la Traducción
Antes de mostrar cómo retener información, necesitamos entender por qué desaparece. Hay tres culpables principales.
El Culpable 1: La Abstracción sin Raíces
Cuando un PM comienza a escribir una story después de investigación, enfrenta una presión cognitiva inmediata: necesita abstraer, generalizar, “crear una historia que aplique a muchos usuarios.” Piensa que si escribes sobre María, una madre específica en Castellón con dos niños, un presupuesto de 40€ y el hábito de comprar los martes, estarás siendo demasiado anecdótica.
Pero aquí está el problema: esa especificidad no es una limitación, es tu mayor activo. María representa un patrón. Lo que la hace específica (el contexto de presión temporal, la carga cognitiva, el punto de dolor de olvidar items) es exactamente lo que hace su job relevante y observable.
Cuando el PM “abstracts away” estos detalles para crear un “usuario promedio,” lo que realmente está haciendo es desechar información.El Culpable 2: La Solución Oculta en el Comportamiento
Muy frecuentemente, lo que comienza como “el cliente quiere poder completar su compra sin olvidar nada” es en realidad un job expresado como solución. El cliente nunca dijo “quiero una lista de favoritos.” Lo que el cliente dijo fue: “Me olvido de items. Tengo miedo de llegar a casa y darme cuenta de que falta algo.”
El job es “asegurarme de que tengo todo lo que necesito para alimentar a mi familia esta semana.” Pero cuando el PM escribe “quiero una lista de favoritos” en la story, ha colapsado el job en una característica.
El Culpable 3: Las Dimensiones Ocultas de Motivación
Cuando María dice “tengo miedo de olvidar algo,” está expresando una motivación emocional de seguridad. Cuando dice “no quiero que mi familia se enfade conmigo por olvidar cosas,” está expresando una motivación social. Cuando dice “necesito ser eficiente porque solo tengo 20 minutos,” está expresando una motivación funcional.
Estas tres dimensiones —funcional, emocional, social— determinan completamente qué experiencia funcionará para María. Pero en la story tradicional, todas esas dimensiones se colapsan en una frase genérica: “Como cliente, quiero X para Y.”
Parte 2: La Trilogía de Marcos que Detiene la Pérdida
El framework de Mercadona resuelve estos tres problemas usando tres marcos integrados. Ninguno funciona solo. Juntos, son prácticamente a prueba de “desvinculación de información.”
Marco 1: JTBD Reforzado — El Contenedor de Contexto Completo
La versión reforzada de Jobs to Be Done que usamos en Mercadona extiende la simple estructura “cuando X, quiero Y, para Z.” Una JTBD Reforzada contiene ocho elementos:
A. Job Principal (El Qué)
La tarea fundamental que el usuario está tratando de lograr. Debe ser un job, no una solución. Un job responde “¿Por qué?” Un user puede hacer el job de múltiples formas.
B. Struggle (La Fricción Actual)
El dolor concreto, específico, frecuentemente expresado en citas literales de investigación. Preserva la intensidad emocional en múltiples capas: Operativa (”Me olvido items”), Emocional (”Me arrepiento”), Social (”Mi familia me reclama”), Contextual (”Especialmente cuando estoy con los niños”).
C. Trigger (El Cuándo)
El momento específico en el que el job se vuelve urgente. Determina completamente el contexto de diseño. El trigger debe ser observable y verificable.
D. Outcome (El Resultado Deseado)
El estado futuro específico que el usuario quiere ver. Los outcomes deben ser cuantificables o al menos observables.
E. Tres Dimensiones de Motivación
Motivación Funcional: ¿Qué quiere lograr en términos concretos, medibles?
Motivación Emocional: ¿Cómo quiere sentirse?
Motivación Social: ¿Cómo quiere ser percibida?F. Anxieties y Barriers
Los obstáculos que previenen que el cambio suceda:
Ansiedad: “¿Y si la lista se borra?” “¿Y si el sistema no está actualizado?”
Barrier operativa: “No sé si este producto está disponible en mi tienda”
Barrier contextual: “En el supermercado no tengo WiFi estable”
Estas ansiedades y barriers no son “cosas que resolver después.” Son restricciones del diseño ahora.
G. Validación: Job vs Solución
Un elemento metacognitivo. El PM debe verificar continuamente: “¿Es esto realmente un job o una solución?” Herramienta: “¿Podría un usuario lograr esto de múltiples formas?” Si la respuesta es NO, has colapsado la solución en el job.
H. Rastreo de Fuente
Cada elemento de la JTBD Reforzada debe poder ser trazado hasta la evidencia de research. Cuando alguien cuestiona la story más tarde, puedes volver a la fuente.
Marco 2: Wendel Checklist — Las Cuatro Preguntas Que Revelan si tu Usuario es Real
Stephen Wendel identifica cuatro factores críticos que determinan si un usuario realmente hará el cambio de comportamiento que el producto espera.
Pregunta 1: ¿Cuál es la Experiencia Previa del Usuario?
¿Ha intentado algo similar antes? ¿Cómo le fue? Un usuario sin experiencia previa mapeada es una bandera roja.
Pregunta 2: ¿Cuál es la Relación del Usuario con el Producto Actual?
¿Usa el producto? ¿Confía en él? Determinará la fricción de adopción.
Pregunta 3: ¿Cuál es la Motivación Situacional del Usuario?
¿Qué sucede en el contexto específico que lo hace ahora motivado a cambiar? La motivación no es estática.
Pregunta 4: ¿Cuál es el Impedimento Actual que Previene el Cambio?
¿Qué específicamente está frenando el cambio ahora? La solución debe diseñarse para superar este impedimento específico.
Si no puedes responder completamente todas cuatro preguntas para tu usuario, tu story no está lista.
Marco 3: Behavior Change — De NOW a NEW
¿Qué cambia realmente cuando el usuario interactúa con tu solución? Muchas user stories describen características, no cambios de comportamiento. Un cambio de comportamiento responde: ¿Qué estaba haciendo el usuario ahora? ¿Qué hará diferente? ¿Cuánto cambiará?
Componente A: NOW — El Comportamiento Actual, Documentado
Para María: “Cada martes intenta recordar mentalmente qué necesita comprar. A menudo falla, olvidando items importantes. Para compras grandes, realiza una lista en papel que frecuentemente pierde. El resultado: olvidar alrededor del 15-20% de los items planeados.” La riqueza está en la especificidad: qué intenta, cómo falla, con qué frecuencia.
Componente B: NEW — El Comportamiento Deseado
NEW debe ser explícito sobre qué comienza, qué se detiene, qué cambia.
START: María comienza a usar la app de lista en el contexto del supermercado.
STOP: María deja de intentar memorizar completamente.
DIFFERENT: María cambia su relación con el riesgo de olvidos. De “es inevitable” a “es controlable.”
Componente C: Rangos de Cambio
Mínimo (aceptable): Usa la lista para el 30% de compras. Olvidos se reducen 50%.
Target (esperado): Usa la lista para el 70%. Olvidos se reducen 80%.
Over-top (aspiracional): Usa la lista para el 90%. Olvidos se reducen 95%.
Tres niveles porque diseño es una práctica bajo incertidumbre. Si defines solo “target,” cuando obtuviste “mínimo,” tu equipo pensará que fracasó.
Parte 3: Integrando los Tres Marcos — De Research a Stories
El workflow es: Input (JTBD Reforzado + Wendel Checklist + Behavior Change mapeado) → Proceso (PM estructura la información en Story Format) → Output (Story legible por ingeniería y diseño que mantiene toda la riqueza contextual).
La Estructura de Story que Retiene Información
Una story creada correctamente tiene esta estructura: EPIC (Job Principal), STORY (Nombre específico del comportamiento), ACCEPTANCE CRITERIA (Given/When/Then con Trigger, NEW behavior y Observable outcome), CONTEXT (Wendel Checklist), MOTIVATIONS (Funcional, Emocional, Social), BARRIERS (Anxieties e impedimentos), EVIDENCE (Rastreo a investigación), SUCCESS METRICS (Mínimo / Target / Over-top).
Cada elemento del marco aparece en la story. No hay colapso de información. El equipo de ingeniería puede leer “Acceptance Criteria” y entender exactamente qué construir. El equipo de diseño puede leer “Context” y entender por qué el usuario necesita lo que necesita.
Ejemplo Concreto: De JTBD a Story
Tomando la JTBD de María (madre de dos niños que compra los martes bajo presión de tiempo), la story resultante incluye: Epic “Confidence in Grocery Completeness”, Story “Load and Review Favorite List Before Shopping”, con criterios de aceptación que especifican carga en menos de 2 segundos, funcionalidad offline, persistencia de datos. El contexto incluye su experiencia previa fallida con listas y su relación con la app. Las métricas de éxito definen tres niveles: Mínimo (30% adopción, 50% reducción olvidos), Target (70% adopción, 80% reducción), Over-top (90% adopción, 95% reducción).
La riqueza de información retenida es total. El equipo de ingeniería sabe qué construir. El equipo de diseño entiende por qué María rechazaría algo complicado. El PM puede explicar por qué esta story es importante.
Parte 4: Puntuación 6D — Evaluando la Salud de tu Story
No todas las stories son iguales. El framework incluye un sistema de puntuación en seis dimensiones que evalúa la confianza en cada story:
Dimensión 1: JTBD Context (0-10)
¿Cuán rico y específico es el contexto de la JTBD? Stories de investigación real típicamente puntúan 8-10. Las especulativas puntúan 2-3.
Dimensión 2: User Specificity (0-10)
¿Cuán específico es el usuario? ¿Puedes describirlo sin decir “usuario” o “cliente”?
Dimensión 3: Behavior Change Clarity (0-10)
¿Cuán claro es el cambio de comportamiento? ¿Puedes describir observable NOW vs NEW?
Dimensión 4: Control Zone (0-10)
¿Cuánto de este cambio está dentro del control de tu producto?
Dimensión 5: Time Constraints (0-10)
¿Cuán bien entiendes las restricciones de tiempo del usuario?
Dimensión 6: Survivable Experiment (0-10)
¿Podría este cambio ser validado en un experimento pequeño antes de invertir en desarrollo completo?
La puntuación 6D no es “bueno si >7.” Es un diagnóstico. Una story que puntúa 2/10 en Behavior Change Clarity tiene un problema crítico. Las stories provenientes de research validado típicamente puntúan ≥7 en las primeras dos dimensiones automáticamente.
Parte 5: El Rol de AI en la Traducción
La IA —incluyendo sistemas avanzados— no puede reemplazar research. No puede inventar JTBDs válidas. Pero la IA es excepcional en:
Retener información sin colapsar: Puede producir una story estructurada que contiene todos los elementos sin perder densidad de información.
Verificar completitud: Puede preguntar “¿respondiste todas las preguntas de Wendel?” y rechazar una story incompleta.
Generar variantes: Puede generar múltiples versiones de story con diferentes puntos de entrada.
Puntuación 6D honesta: Puede puntuar basado en datos explícitos, evitando el sesgo humano.
Rastreo de evidencia: Manteniendo referencias explícitas a research original.
Pero —y esto es crítico— El PM todavía decide. El framework de Mercadona mantiene el criterio humano en decisiones de producto. La IA mantiene la consistencia y trazabilidad. Juntos, retienen información sin perder calidad.
Conclusiones: Síntesis de Cómo Retener Información en la Traducción
1. El Problema es Real: Tres fuerzas trabajan contra la retención: la presión de abstraer, la tendencia a colapsar el job en una solución, y la omisión de dimensiones motivacionales.
2. JTBD Reforzada es el Contenedor: Ocho elementos que preservan cada aspecto crítico de la investigación. La clave está en la especificidad.
3. Wendel Checklist Revela si tu Usuario es Real: Cuatro preguntas que convierten un usuario abstracto en uno concreto cuyas decisiones puedes predecir.
4. Behavior Change Especifica el Qué Cambia: Observable NOW vs NEW, con rangos mínimo/target/over-top.
5. La Story Estructurada Retiene Todo: Epic > Story > Acceptance Criteria > Context > Motivations > Barriers > Evidence > Metrics.
6. Puntuación 6D es Diagnóstico, No Veredicto: Seis dimensiones que revelan dónde está incompleta una story.
7. La IA Retiene, El Humano Decide: El rol de IA es mantener información. El rol del PM es investigar y elegir.
8. Honestidad Sobre Gaps: Un gap documentado es una oportunidad. Un gap no documentado es una bomba de tiempo.
Reflexión Final: De Donde Venimos, Hacia Donde Vamos
Si has leído los artículos 1, 2, 3 y este artículo 4, has recorrido un camino completo de research a product:
Artículo 1: Identificaste un DAPP rico en contexto de negocio
Artículo 2: Investigaste ese problema con metodología rigurosa
Artículo 3: Validaste que habías encontrado Jobs verdaderos, no soluciones disfrazadas
Artículo 4 (este): Tradujiste esos jobs en stories que retienen toda la información
Quedan tres artículos más: Artículo 5 sobre el Quality Coach para evaluar calidad de stories, Artículo 6 sobre Story Splitting para descomponer stories grandes, y Artículo 7 sobre el Story Builder conversacional.
Por ahora, la lección es simple: La información que pierdes en la traducción de research a story no se recupera después. Construye tus stories con estructura suficiente para retenerla. Integra los tres marcos. Puntúa honestamente. Y mantén el rastreo a las fuentes.
Tus usuarios —y tu equipo— lo agradecerán cuando las stories sean tan ricas en contexto que el desarrollo se vuelve claramente identificado hacia el outcome real, no hacia una característica genérica.
Este artículo es parte de la serie “Gemba” sobre el “AI Mercadona User Story Framework”. Próximo artículo: “Quality Coach: Evaluando la Calidad de tus User Stories.”
Última actualización: Febrero 21, 2026