No esperaba la reacción. Decenas de mensajes pidiendo detalles. Empresas pequeñas y grandes preguntando cómo lo habíamos hecho. Equipos de ingeniería contando que llevaban meses pensando en algo parecido pero no sabían por dónde empezar. Personas no técnicas queriendo entender qué hay realmente detrás de un buscador moderno.

Este artículo es la respuesta a todas esas preguntas. Y al final hay un fichero descargable que puedes darle a Claude Code para empezar tu propio proyecto siguiendo el mismo método.

Por qué lo cuento todo

En Mercadona tenemos un Modelo que se llama Calidad Total. No es un documento ni un manual: es el sistema que guía las decisiones de todos los que trabajamos en la compañía, desde la persona que repone en una tienda hasta el comité de dirección. Cuando hay que elegir entre dos caminos, el Modelo te dice cuál respeta lo que debe respetarse, y en qué orden.

El Modelo de Mercadona identifica cinco componentes a los que la empresa tiene que satisfacer simultáneamente, y lo hace en un orden concreto: primero El Jefe —que es como llamamos al cliente en Mercadona—, después el Trabajador, después el Proveedor, después la Sociedad y, finalmente, el Capital. Los cinco a la vez, pero con esa secuencia de prioridad. La frase que se repite internamente es que “para que el avión vuele, tienen que cumplirse todas las leyes de la física al mismo tiempo”: atender a todos, sin perder el orden.

El componente que me interesa hoy es el cuarto: la Sociedad. Las personas, entidades y lugares que rodean a la empresa. Juan Roig lo resume con una frase que cualquiera que trabaje cerca le ha oído alguna vez: mi sueño es compartir el modelo. Si alguien aprende a hacer las cosas bien, hay emprendedores. Si hay emprendedores, hay empresas. Si hay empresas, hay empleo. Si hay empleo, hay riqueza. Si hay riqueza bien gestionada, hay bienestar.

Compartir lo que aprendemos es, dentro del Modelo de Mercadona, una de las formas naturales de cumplir con el componente Sociedad.

Por eso este artículo no se queda en la anécdota. Voy a contar exactamente cómo está construido nuestro buscador: qué algoritmos lo componen, qué decisiones tomamos en cada capa, por qué descartamos algunas alternativas que parecían obvias, qué reglas de gobernanza aplicamos al modelo de aprendizaje, y qué stack abierto puede reproducirlo. Y voy a entregar al final un playbook descargable para que cualquier equipo, sin importar su tamaño, pueda usarlo como punto de partida.

Si lo que cuento sirve para que un equipo de tres personas en cualquier sitio reemplace un buscador caro por uno propio, mejor, y más controlable, este artículo habrá cumplido su función.

A quién le sirve esto

Antes de entrar en detalle, conviene aclarar para quién es útil lo que viene a continuación.

Este artículo está pensado para dos lectores muy distintos a la vez. El primero es alguien sin formación técnica que quiere entender realmente cómo funciona un buscador moderno: por qué a veces encuentra lo que busca y por qué otras veces no, qué está pasando cuando un sistema “aprende” de los clics, por qué unas tiendas online tienen buscadores que parecen leerte la mente y otras te muestran resultados absurdos. Para este lector, voy a explicar cada concepto antes de usarlo y a evitar la jerga gratuita.

El segundo lector es alguien técnico que quiere replicar el sistema. Para ese lector, voy a dar el detalle suficiente para que el playbook final tenga sentido: nombres concretos de algoritmos, parámetros, decisiones de validación, métricas. No voy a esconder nada relevante por miedo a que el artículo parezca denso.

Mi apuesta es que ambos lectores pueden convivir en el mismo texto si la estructura está bien. La parte técnica explica el porqué. La parte conceptual explica el qué. Y las dos juntas dan la única respuesta honesta a ¿cómo se hace un buscador?: no hay una respuesta corta, pero tampoco es magia.

Por qué un buscador propio

En una tienda online, el buscador es la puerta principal. La gente no navega catálogos cuando ya sabe lo que quiere: escribe el nombre y espera que aparezca. Si no aparece, se va. No reformula, no explora, no vuelve a probar dos veces. Se va.

En nuestra tienda online, el buscador maneja 4,4 millones de búsquedas a la semana. Si el 4% no devuelve resultados, hablamos de unos 176.000 usuarios a la semana que escriben algo razonable y no encuentran nada. Eso era exactamente lo que nos pasaba. Y era lo más educado que podía pasar: el resto de búsquedas, las que sí devolvían resultados, también podían ser mejores. Solo que ahí no teníamos un número rojo que nos avisara.

El problema con un buscador estándar —cualquier buscador estándar, sea un SaaS o el motor que viene con el e-commerce— es que está diseñado para ser bueno con cualquier catálogo. Eso suena bien hasta que recuerdas que tu catálogo no es cualquier catálogo. Tus usuarios no escriben como los de cualquier otra tienda. Tu negocio no premia los mismos resultados que el de tu competidor. Y, sobre todo, tienes datos de comportamiento real —qué buscan, qué clican, qué compran— que un buscador genérico no puede aprovechar bien porque no son suyos.

Construir el tuyo te da tres cosas concretas. La primera es control sobre el ranking: tú decides qué señales pesan más, cómo se ponderan, qué hacer con productos que aparecen mucho pero se compran poco, qué hacer con productos nuevos que todavía no tienen historial. La segunda es mejora dirigida: cada decisión que tomas se mide contra los datos reales de tu negocio, no contra un benchmark sintético. Si una decisión mejora un 1% el ranking de tu catálogo, te lo llevas tú. La tercera es propiedad de la pieza: una de las decisiones más críticas del negocio deja de depender de un proveedor externo y pasa a ser conocimiento que se queda dentro del equipo.

Hay una cuarta razón, menos romántica pero igual de relevante: el coste. Un buscador SaaS razonablemente serio cuesta varios miles de dólares al mes para un volumen como el nuestro. Un buscador propio bien diseñado cuesta una fracción. Eso no es razón suficiente por sí sola —si gastando dinero compras calidad, gasta dinero—, pero cuando construyendo el tuyo *además* mejoras la calidad, el cálculo deja de ser una decisión y se convierte en una conclusión.

Decidimos construir el nuestro. Lo que viene a continuación es exactamente cómo lo hicimos.

La arquitectura, en una página

Antes de entrar en cada componente, conviene tener una imagen mental. Un buscador moderno parece complejo, pero no lo es tanto si lo ves como un proceso de cuatro pasos.

Imagina que entras en una librería gigantesca con un papel donde has escrito tres palabras del libro que buscas. Para encontrarlo mandas a dos personas. La primera busca todos los libros cuyo título contenga literalmente esas tres palabras. La segunda busca libros que, aunque no usen exactamente esas palabras, traten del mismo tema. Vuelven las dos con su lista. Tú las cruzas, descartas los libros que no estén en esa librería concreta, y un experto en el catálogo te ordena lo que queda según lo que sabe del negocio: qué libros se prestan más, cuáles son recientes, cuáles encajan mejor con tu petición. Lo que tú ves es la lista final.

Eso es, casi literalmente, lo que hace un buscador como el nuestro. Cambia “libros” por “productos”, “dos personas” por “dos algoritmos de búsqueda” y “experto en el catálogo” por “modelo de aprendizaje”, y tienes toda la arquitectura.

Veamos las piezas.

1. Normalizar la consulta

Cuando alguien escribe “Café Molido”, el sistema convierte ese texto en su forma canónica: minúsculas, sin acentos, separado en palabras. “Café Molido” pasa a ser una lista con dos elementos: “cafe” y “molido”. La regla de oro: la normalización al consultar tiene que ser **exactamente la misma** que la normalización al indexar el catálogo. Si lo indexas con acento y lo buscas sin acento, no hay match. En nuestro catálogo descubrimos que el 100% de los usuarios escribe sin acentos: eso decidió la convención.

2. Dos búsquedas en paralelo

Sobre la consulta normalizada, el sistema lanza dos búsquedas simultáneas.

La primera es **léxica**: busca productos cuyo nombre, marca o descripción contenga literalmente las palabras del usuario. Si escribes “leche”, encuentra productos con “leche” en alguna parte. Lo hace con **BM25**, un algoritmo clásico que puntúa cada producto según cuántas veces aparece la palabra y lo rara que es esa palabra en el catálogo (las palabras raras puntúan más). Corre sobre **Tantivy**, un motor escrito en Rust, embebido en el servicio, sin clúster aparte. Devuelve los 100 mejores candidatos.

La segunda es **semántica**: convierte la consulta en un vector de 384 números que representa su “significado” y busca, en una matriz precomputada de todos los productos, cuáles son más parecidos en ese espacio. Encuentra cosas que la primera no encuentra: si buscas “para fregar”, puede traerte “estropajo” aunque no contenga la palabra “fregar”. El modelo que genera los vectores se llama **e5-small** —abierto, multilingüe, ligero— y lo ejecutamos como ONNX INT8, una versión optimizada que cabe en 6 MB de memoria y responde en milisegundos sin tarjeta gráfica. Devuelve los 50 mejores candidatos.

3. Fusionar las dos listas

Tenemos dos listas con candidatos que a veces se solapan y a veces no. La técnica que usamos para combinarlas se llama **Reciprocal Rank Fusion**: cada producto recibe puntos inversamente proporcionales a su posición en cada lista. Si aparece el 1º en una y el 5º en la otra, suma por ambas. Si solo aparece en una, suma por una. Es robusta y no requiere calibrar pesos: solo usa posiciones, no puntuaciones absolutas, lo que la hace ciega al hecho de que BM25 y similitud semántica viven en escalas distintas.

Tras la fusión queda una lista de unos 60 candidatos. A continuación se aplica un filtro: descartar los productos que no estén en el surtido de la tienda concreta del usuario. Cómo hacemos ese filtro de forma eficiente es una decisión interesante por sí misma — la cuento en la siguiente sección.

4. Reordenar con aprendizaje automático

Los 60 candidatos que quedan están razonablemente filtrados, pero no están bien ordenados. Decidir qué producto va arriba requiere algo más que las puntuaciones anteriores: requiere un modelo entrenado con datos reales del negocio.

Ese modelo se llama Learning To Rank. En nuestro caso es CatBoost YetiRank, un algoritmo basado en árboles de decisión optimizado para problemas de ordenación. Recibe los 60 candidatos junto con 14 características de cada uno —su puntuación BM25, su parecido semántico, cuántas veces se ha comprado en las últimas semanas, lo popular que es entre clientes habituales, si lleva poco tiempo en el catálogo— y produce el orden final. Tarda menos de un milisegundo en hacerlo.

A todo esto le acompaña una pieza separada: el autocompletado, las sugerencias que aparecen mientras el usuario escribe. Esto no es una búsqueda completa: es un Trie (un árbol de prefijos) que devuelve, en microsegundos, productos cuyo nombre empieza por lo que llevas escrito. Tres señales para ordenar las sugerencias: en qué campo aparece el match, si coincide la palabra entera o solo el prefijo, y la posición dentro del nombre.

El presupuesto total

Todas las piezas se ejecutan en un tiempo casi imperceptible: menos de 15 milisegundos en el 99% de las consultas. En la práctica nuestra mediana es de 12 ms. Parpadear tarda unos 300 ms — el buscador entero responde unas 20 veces más rápido que un parpadeo. Cada componente tiene su sub-presupuesto, y si alguno se pasa, el sistema deja de responder a tiempo y la experiencia se degrada. Esa restricción estructura las decisiones que vienen a continuación.

Cinco decisiones que separan un prototipo de un buscador real

Las decisiones que vienen a continuación son las que más nos costó tomar y las que más diferencia hicieron. Cada una es independiente: pueden adoptarse por separado en cualquier proyecto. Y cada una responde a una alternativa que parecía obvia al principio y resultó equivocada al final.

1. Búsqueda híbrida: ninguna de las dos por separado funciona

La tentación inicial es elegir uno: o lexical, o semántico. La búsqueda lexical es rápida, predecible y barata. La semántica es lista, encuentra sinónimos y maneja preguntas en lenguaje natural. ¿Por qué hacer las dos?

Porque por separado son malas. Si solo usas lexical, el 33% de las consultas no devuelven resultados: alguien escribe “para fregar”, no aparece la palabra “fregar” en ningún producto, y el sistema se rinde. Si solo usas semántica, todo encuentra algo, pero ese “algo” es a menudo ruido: el modelo cree que “agua mineral” se parece a “agua oxigenada” y te las mezcla en el ranking.

Las dos juntas se complementan. La semántica garantiza recall (que siempre haya candidatos) y la lexical garantiza precisión (que los candidatos obvios estén ahí). En nuestros datos, el recall@50 sube de 0,547 (solo lexical) a 0,853 (híbrido). El porcentaje de búsquedas sin resultados pasa del 33% al 0%. Y luego, sobre las dos listas combinadas, el modelo de aprendizaje hace de juez final: aprende de los clics qué resultados son realmente buenos y qué resultados, aunque parezcan relevantes, los usuarios ignoran.

Cómo decidirla en tu caso: si tu catálogo tiene vocabulario abierto, queries en lenguaje natural o sinónimos relevantes, necesitas la capa semántica. Si tu catálogo es pequeño y los usuarios escriben siempre con el vocabulario del catálogo, quizá puedas empezar solo con lexical y añadir la semántica después. Pero la mayoría de catálogos reales necesitan ambas.

2. Un solo índice maestro con bitsets, no un índice por tienda

El surtido de productos cambia de una tienda a otra: no todas las tiendas tienen los mismos productos en stock. La forma ingenua de manejar esto es construir un índice de búsqueda independiente para cada tienda. En nuestro caso, eso son 762 índices, replicarlos para distintos órdenes de resultados, mantenerlos actualizados, reindexar uno cada vez que cambia un surtido.

La alternativa que adoptamos: un solo índice maestro con todo el catálogo, y para cada tienda mantenemos un **bitset** —un mapa de bits, un array binario donde cada bit representa “este producto está disponible aquí, sí o no”—. Cuando alguien busca desde una tienda, ejecutamos la búsqueda contra el índice maestro y filtramos el resultado haciendo una operación AND entre los IDs de los productos encontrados y el bitset de su tienda.

Las cifras hablan solas: 254 bitsets, cada uno de 813 bytes, suman **200 KB en total**. Una operación AND sobre un bitset es cuestión de microsegundos. Actualizar un surtido es sustituir un bitset entero, otra operación trivial. Comparado con mantener 762 índices físicamente separados, multiplicas por mil la simplicidad operativa y por mil el ahorro de almacenamiento.

Cómo decidirla en tu caso: siempre que tengas multi-tenancy con catálogos solapado —tiendas, marcas, regiones, idiomas— el patrón “índice maestro + bitset por tenant” gana. La regla es: ¿la mayoría del catálogo es común a todos los tenants? Sí → bitsets. ¿Cada tenant tiene un catálogo radicalmente distinto? Entonces sí, índices separados.

3. Validación walk-forward: nunca mezcles clics al azar

Cuando entrenas un modelo de ranking, necesitas separar tus datos en entrenamiento y test. La forma estándar en machine learning es coger todos los datos, mezclarlos al azar, y reservar el 20% para test. Esto se llama validación cruzada aleatoria (random k-fold).

En un buscador esto está mal. Los clics tienen estructura temporal: estacionalidad, lanzamientos de producto, campañas internas, días con más tráfico que otros. Si mezclas clics aleatoriamente, mezclas pasado y futuro, y el modelo “aprende” cosas que en producción no podría haber sabido. El resultado son métricas infladas: tu modelo parece haber mejorado un 5-10% más de lo que realmente mejorará en producción.

La alternativa correcta se llama **walk-forward**: entrenas con las semanas 1, 2 y 3, validas con la semana 4. Después puedes deslizar la ventana: entrenas con 2, 3 y 4, validas con 5. Y así. El modelo siempre se evalúa contra un futuro real, no contra un futuro que ya conoce.

Cómo decidirla en tu caso: cuando los datos tengan dimensión temporal —y en un buscador siempre la tienen—, walk-forward es obligatorio. No es opcional. Es una de esas decisiones que parecen un detalle metodológico y son, en realidad, la diferencia entre desplegar un modelo que mejora la métrica de negocio y desplegar uno que la degrada.

4. Corregir el sesgo de posición: clics no es lo mismo que relevancia

Hay un problema sutil con entrenar un modelo a partir de los clics de los usuarios: los usuarios clican más los primeros resultados independientemente de si son relevantes o no. Hay estudios serios sobre esto: el primer resultado se clica unas seis veces más que el quinto, aunque el quinto sea exactamente igual de bueno. Si entrenas un modelo asumiendo que “clic = relevante”, el modelo aprende a poner siempre arriba los productos que ya estaban arriba. Tu modelo se refuerza a sí mismo, los productos del top dominan, los productos buenos pero menos visibles nunca emergen, la diversidad del catálogo colapsa, y la calidad cae sin que te des cuenta. Esto se llama feedback loop o Relevance Feedback para los padres de la Recuperación de Información.

La corrección estándar se llama Inverse Propensity Weighting (IPW): a cada clic le das un peso inversamente proporcional a la posición en la que apareció. La fórmula que usamos es 1 dividido entre el logaritmo en base 2 de la posición más uno. Un clic en la posición 1 cuenta poco; un clic en la posición 8 cuenta mucho más, porque el usuario tuvo que ignorar siete resultados antes de llegar a él. Eso sí es una señal fuerte de relevancia.

Y lo complementamos con exploración: en el 5% de las búsquedas, el sistema mete deliberadamente 2-3 resultados aleatorios en las posiciones 3, 5 y 7. Suena raro pero es necesario: sin exploración, los productos nuevos nunca reciben clics y se quedan atrapados abajo para siempre. El 5% es un coste tolerable para evitar un equilibrio subóptimo permanente.

Cómo decidirla en tu caso: si tu modelo aprende de clics, IPW es obligatorio y exploración también. No hay alternativa razonable.

5. Guardrail del −2%: ningún modelo peor pasa, automáticamente

Reentrenar un modelo cada semana suena bien, hasta que un día el reentrenamiento produce un modelo peor. Si lo despliegas sin más, los usuarios siguen buscando, los clics siguen llegando —porque no tienen alternativa— y tu siguiente reentrenamiento se hace con datos sesgados por un modelo malo. La degradación es invisible y se acumula.

La defensa que aplicamos es un guardrail automático: el pipeline de reentrenamiento solo despliega un modelo si **ninguna de cuatro métricas cae más de un 2%** respecto al modelo en producción. Las cuatro métricas son MRR y NDCG, evaluadas tanto sobre el conjunto de test temporal (walk-forward) como sobre un golden set estático de 500 consultas con la respuesta ideal anotada manualmente. El golden set no se modifica nunca: es la única referencia inmune al feedback loop.

El pipeline produce tres decisiones posibles. **PROMOTE** si el candidato mejora más de un 0,5%. **HOLD** si está en el rango neutro entre −2% y +0,5% (queda en cuarentena, no se despliega). **REJECT** si cae más de un 2%. Y aún en el caso de PROMOTE, el despliegue real espera una hora antes de activarse, durante la cual cualquier persona del equipo puede abortarlo. Es el último gate humano.

Cómo decidirla en tu caso: si despliegas modelos de forma automática, necesitas un guardrail. El umbral exacto depende de tu sensibilidad: un −2% es estricto pero adecuado para un buscador con tráfico crítico. Para un sistema con menos riesgo puedes usar −5%. Pero el patrón —reglas automáticas + métrica independiente del propio sistema (golden set) + ventana humana antes del deploy— es universal.

El stack (todo abierto, todo replicable)

Una de las cosas que más sorprende al construir esto es lo poco exótico que es el stack. No hay tarjetas gráficas dedicadas, no hay bases de datos vectoriales, no hay servicios externos de cobro. Todo lo que viene a continuación es código abierto, cabe en un repositorio Python, y se ejecuta sobre máquinas estándar.

El motor lexical: Tantivy

Para la búsqueda por palabras clave usamos Tantivy, una librería escrita en Rust inspirada en Apache Lucene (La madre de todos los motores de búsqueda que ves hoy en día creado por Doug Cutting hace más de 25 años en Xerox Park). Lo más importante de Tantivy no es el rendimiento (que es excelente: respuestas en milisegundos sobre catálogos de miles de productos), sino que se ejecuta dentro del propio servicio. No hay un clúster aparte, no hay servidores de búsqueda dedicados, no hay JVM que mantener. El índice ocupa unos 20 MB de memoria y vive en el mismo proceso que el resto del código.

Tantivy soporta de forma nativa lo que necesitas para un buscador real: tokenización configurable, búsqueda por prefijos para el autocompletado, *facetas* para filtros (por categoría, marca, etc.), y *highlighting* de los términos coincidentes. La alternativa habitual —Elasticsearch o OpenSearch— está pensada para catálogos del tamaño de los de Wikipedia: si tu catálogo tiene menos de 100.000 documentos, Tantivy es probablemente la elección correcta.

El modelo semántico: e5-small ejecutado con ONNX Runtime

Para la capa semántica usamos un modelo de embeddings abierto llamado multilingual-e5-small, publicado por Microsoft Research. “Small” significa que el modelo tiene unos 118 millones de parámetros: pequeño en términos de modelos modernos, pero más que suficiente para nombres de producto cortos. Genera vectores de 384 dimensiones por consulta y por documento.

Ejecutar este modelo en su forma original (PyTorch) tarda unos 20 ms por consulta en CPU. Demasiado para nuestro presupuesto de latencia. La solución estándar es convertirlo al formato ONNX (Open Neural Network Exchange) y ejecutarlo con ONNX Runtime, una librería de inferencia muy optimizada. Con la cuantización a enteros de 8 bits (INT8) —una técnica que reduce la precisión numérica a cambio de un 4× de velocidad sin pérdida medible de calidad— el modelo pasa a ocupar unos 118 MB en memoria y devuelve un vector en 3–5 ms en una CPU normal1.

No hace falta GPU, no hace falta una base de datos vectorial. La matriz completa de embeddings de todo el catálogo —unos 4.300 productos por 384 dimensiones— ocupa 6 MB en RAM. La búsqueda por similitud es una multiplicación de matriz NumPy y un argsort: 1 ms para todos los productos.

El modelo de ranking: CatBoost YetiRank

El re-ranking final lo hace CatBoost, una librería de gradient boosting publicada como código abierto por Yandex. Lo elegimos tras una competición interna entre cinco algoritmos: CatBoost YetiRank, XGBoost, LightGBM con LambdaRank, una baseline Pointwise y una Listwise. CatBoost YetiRank ganó con menor varianza entre folds (MRR 0,867 ± 0,014) y con la mejor inferencia: el modelo entrenado pesa unos 5 MB y predice el orden de 60 candidatos en menos de un milisegundo.

YetiRank es la función de pérdida específica para problemas de ordenación que CatBoost incorpora: en lugar de optimizar la predicción de un valor (regresión) o una clase (clasificación), optimiza directamente el orden relativo entre documentos para una misma consulta. Es lo correcto técnicamente para learning-to-rank y, en nuestra competición, fue también lo correcto empíricamente.

El autocompletado: un Trie

El autocompletado no usa el motor de búsqueda. Usa una estructura de datos clásica llamada Trie (un árbol de prefijos), donde cada nodo representa una letra y cada camino desde la raíz hasta una hoja es un prefijo de una palabra del catálogo. Para encontrar las sugerencias de “atu”, recorres tres pasos en el árbol y devuelves todas las palabras que cuelgan de ahí.

La búsqueda en un Trie es del orden de microsegundos, no milisegundos. En nuestro caso, p50 = 3 microsegundos, p99 = 388 microsegundos. Eso permite responder a cada tecla que el usuario pulsa sin que la red sea el cuello de botella.

El resto: Python, NumPy, scikit-learn

El pegamento que une todas estas piezas es Python. La capa de servicio recibe la consulta, llama a Tantivy, llama al runtime ONNX para el embedding, hace el merge RRF con NumPy, aplica el bitset de la tienda, calcula las 14 features de los candidatos restantes, llama a CatBoost para el ranking final, y serializa el resultado. Toda la lógica matemática descansa en NumPy, y scikit-learn se usa solo durante el entrenamiento offline (split de datos, métricas, baselines).

No hay nada en este stack que no puedas instalar con un pip install o un cargo add. No hay licencias propietarias, no hay servicios externos de cobro recurrente, no hay infraestructura especializada. Esa es deliberadamente la apuesta: si la infraestructura es estándar, el conocimiento que generes es portable, y la pieza queda dentro del equipo.

Resumen de dependencias

- Búsqueda lexica: **Tantivy** (Rust, licencia MIT)

- Embeddings: **multilingual-e5-small** (MIT)

- Inferencia de embeddings: **ONNX Runtime** (MIT)

- Ranker: CatBoost (Apache 2.0)

- Pegamento: **Python + NumPy + scikit-learn** (BSD)

- Almacenamiento de matrices: NumPy en RAM, sin base de datos vectorial

Todo esto cabe en un proceso del orden de 100 MB de RAM (modelo + índice + matriz de embeddings + runtime). Una máquina modesta lo ejecuta sin despeinarse.

El workflow: cómo se trabaja con Claude Code en un proyecto así

He escrito ya, en artículos anteriores, sobre cómo cambia el trabajo cuando una parte del equipo lo hace conversando con un agente de IA. No voy a repetir aquí ese debate. Voy a contar, en concreto, cómo se distribuyó el trabajo en este proyecto, porque creo que es la parte más útil para alguien que quiera replicarlo.

El reparto: humano decide, agente ejecuta

La regla mental que aplicamos es simple. Todo lo que sea explorar —analizar datos, probar configuraciones, comparar alternativas, escribir scripts de evaluación, generar tablas— lo hace el agente. Todo lo que sea decidir —qué arquitectura adoptar, qué validación usar, qué guardrails poner, qué descartar— lo hacen las personas.

Esa distinción importa porque las dos partes son del mismo trabajo. Sin la exploración masiva, las decisiones se toman a ciegas. Sin las decisiones, la exploración se vuelve una pila de experimentos sin convergencia. La velocidad del agente es lo que permite explorar 175 configuraciones de BM25 en lugar de 5, comparar 3 modelos de embeddings en lugar de quedarse con el primero que funciona, y validar el ranker contra una competición de 5 algoritmos en lugar de adoptar el de moda. Es lo que convierte “una decisión basada en intuición” en “una decisión basada en datos reales del catálogo”.

Las cuatro fases del proyecto

El proyecto avanzó en cuatro fases bien delimitadas, cada una con un experimento canónico, un fichero de evaluación versionado y una decisión documentada al final.

Fase 0: exploración de datos. Empezamos sin escribir una sola línea de código de producto. Conectamos al agente los 479 MB de datos del catálogo, las analíticas, las consultas reales y los datos de compras, y le pedimos que respondiera preguntas concretas: ¿cuántas palabras tiene una consulta media?, ¿qué porcentaje contiene tildes?, ¿qué vocabulario aparece y con qué frecuencia? Aprendimos cosas que cambiaron decisiones posteriores: el 93,7% de las consultas tienen una sola palabra, el 100% se escriben sin acentos, el vocabulario activo son unos 1.300 términos. Sin estos datos, habríamos optimizado el sistema para problemas que no teníamos.

Fase 1: baseline lexico. Antes de complicarse, hay que tener un baseline. El agente probó 175 configuraciones de BM25 en una *grid search*. El ganador resultó ser BM25 con k1=0,5 y b=0 — ese cero en b es importante: significa no normalizar por longitud del documento, contraintuitivo en un buscador típico, pero correcto en un catálogo donde los nombres de producto son cortos y uniformes. Esto solo se descubre probando.

Fase 2: capa semántica. Con el baseline encima de la mesa, el agente comparó tres modelos de embeddings. e5-small ganó por equilibrio entre calidad y velocidad. Lo más interesante de esta fase no fue ganar un punto de MRR, sino constatar que la búsqueda semántica por sí sola produce demasiado ruido, y que la idea correcta era combinarla con la lexical, no sustituirla.

Fase 3: Learning To Rank. La que más tiempo nos llevó. Cinco modelos, validación cruzada con cinco particiones temporales, comparación de features, análisis de importancias. La decisión final —CatBoost YetiRank con 14 features— es producto de un experimento controlado, no de una intuición. La importancia de cada feature se midió: popularidad 37,5%, embeddings 29,8%, BM25 12,9%. Saber esto no fue accesorio: nos dio confianza para defender decisiones más adelante, por ejemplo descartar reglas manuales que solo replicaban señales que el modelo ya estaba capturando.

Fase 4: personalización. Aquí aprendimos negativamente. Probamos features personalizadas (afinidad por categoría, si el usuario es habitual). Su importancia offline resultó ser del 0%. La conclusión no fue “la personalización no funciona”, fue “no podemos validarla offline sin un mapeo consulta-usuario que no tenemos”. La decisión: aplazarla para test A/B en producción. A veces, el resultado más útil de una fase es saber que la fase no estaba lista.

El truco que sostiene todo: un CLAUDE.md no negociable

Si hay un solo elemento del que depende que este método funcione, es el fichero de reglas que vive en la raíz del proyecto y que el agente lee al principio de cada sesión. Lo llamamos CLAUDE.md. No es documentación; son restricciones.

Las reglas se dividen en cinco bloques: presupuestos de latencia (cada componente con su milisegundo máximo), reglas de arquitectura (qué algoritmos no se sustituyen sin proceso explícito), reglas de aprendizaje automático (IPW, walk-forward, golden set, guardrails), reglas de integración continua (qué tests bloquean un merge), y reglas de despliegue. Cada regla viene con su justificación —el porqué— y la consecuencia de violarla. Si el agente, en una sesión cualquiera, sugiere algo que viola una regla, hay un mecanismo de bloqueo que lo detiene antes de que entre al repositorio.

Este fichero es el conocimiento estable del proyecto. Es donde vive lo que hemos aprendido y no queremos volver a aprender. Es lo que se queda cuando el agente de IA cambia de versión, cuando el equipo rota, cuando el contexto de una conversación se corta. Es, literalmente, el componente que hace que un proyecto construido con vibe coding sea un proyecto, y no una colección de scripts que funcionaron una vez.

Y es, precisamente, lo que viene a continuación: el playbook completo en formato CLAUDE.md que puedes descargar y usar como punto de partida para tu propio buscador.

El playbook que liberamos

Al pie de este artículo encontrarás un fichero descargable: **searchmo-playbook.md**. No es un manifiesto ni una guía teórica. Es la misma plantilla de reglas que rige nuestro propio buscador, generalizada para que cualquiera pueda darle uso.

¿Qué contiene?

El fichero tiene cuatro bloques:

Reglas no negociables. Las restricciones que rigen el proyecto y que un agente de IA no puede violar sin proceso explícito. Incluye los presupuestos de latencia por componente (15 ms en total, distribuidos), las decisiones de arquitectura (no usar base de datos vectorial, no clúster externo, índice maestro con bitsets) y las reglas de aprendizaje automático (IPW obligatorio, walk-forward obligatorio, golden set obligatorio, guardrail −2%).

Las cuatro fases del proyecto. El orden en el que avanzar, con un objetivo medible al final de cada una. Fase 0: caracterización del catálogo y las consultas. Fase 1: baseline lexical con grid search. Fase 2: capa semántica con comparación de modelos. Fase 3: learning-to-rank con competición de algoritmos. Cada fase incluye prompts sugeridos para Claude Code: cómo pedirle que ejecute el grid search, cómo pedirle que monte el comparador de embeddings, cómo pedirle que entrene los cinco modelos de ranking.

Checklist de las cinco decisiones algorítmicas. Para cada una, los criterios que te ayudan a decidir cómo aplicarla en tu caso concreto. Si tu catálogo tiene tales características, decisión X. Si no, decisión Y.

Stack mínimo. Las dependencias concretas, con versiones probadas. Tantivy, multilingual-e5-small, ONNX Runtime, CatBoost, Python, NumPy, scikit-learn. Todo abierto, todo replicable.

¿Cómo usarlo?

1. Descarga el fichero y guárdalo como CLAUDE.md en la raíz de un repositorio nuevo.

2. Abre Claude Code en ese directorio.

3. Pídele que lea las reglas y empiece por la Fase 0.

4. A partir de ahí, trabajas conversación por conversación, fase por fase, con el agente ejecutando los experimentos y tú tomando las decisiones al final de cada uno.

El proceso completo nos llevó un mes, pero el 70% del trabajo —exploración de datos, baseline lexical, capa semántica y primera versión del ranker— se hizo en un fin de semana largo. El resto del mes fue refinamiento: gobernanza del modelo, golden set, pipeline de reentrenamiento y guardrails. No es un proyecto de un fin de semana en el sentido amateur del término. Pero tampoco un proyecto que requiera un equipo de quince personas: es un proyecto que un par de personas con criterio y un agente de IA pueden afrontar.

Lo que el playbook no resuelve por ti

Hay tres cosas que el fichero no puede resolver, y conviene saberlo antes de empezar.

Tu catálogo.El playbook describe el método. Los datos de tu catálogo son tuyos: qué productos tienes, cómo los describes, qué señales de comportamiento tienes registradas. Cuanta más calidad tengan estos datos —especialmente el log de clics— más rápido converge el sistema.

Tu juicio. Las cinco decisiones algorítmicas tienen un porqué; ese porqué se aplica al 80% de los casos. El 20% restante necesita criterio. El playbook te enseña qué preguntar, no qué responder.

Tu rigor. La parte más exigente no es la algorítmica: es la disciplina de medir, evaluar contra un golden set inmutable y respetar los guardrails cuando tu propio modelo se degrada. Esa parte la pones tú.

Lo que pedimos a cambio

Nada. El fichero se libera bajo licencia MIT. Puedes copiarlo, modificarlo, usarlo en proyectos comerciales, no atribuir, no devolver nada. El componente sociedad del Modelo de Mercadona no funciona como un trueque. Funciona como una multiplicación: si lo que aprendimos sirve para que otros equipos hagan algo mejor, estamos cumpliendo con el cuarto componente del Modelo de Mercadona a nuestra manera.

Si el playbook te sirve, nos encantaría saberlo. Pero no es una condición. Es solo curiosidad.

Al principio del artículo dije que no quería quedarme en la anécdota. He dado el detalle algorítmico, las decisiones críticas, el stack, el método de trabajo y un fichero descargable que reproduce todo lo que hemos aprendido. Si has llegado hasta aquí, ya tienes lo que necesitas para empezar tu propio buscador.

Compartir un playbook técnico es una forma de cumplir con el componente Sociedad del Modelo de Mercadona: una manera de operar en el día a día que también beneficie a quien está fuera del perímetro de la empresa.

Yo no espero que un equipo en otra empresa lea esto y construya el mejor buscador de la historia. Espero que alguien con un buscador caro, lento o poco controlable lea el artículo, descargue el fichero y se ahorre semanas de prueba y error. Si le ahorramos a un equipo el coste de aprender a tropezar, ya hemos cumplido nuestra parte.

El sueño de Juan Roig es compartir el modelo. Aplicado a un buscador parece pretencioso, pero es exactamente el mismo gesto: si alguien aprende a hacer algo bien, hay emprendedores; si hay emprendedores, hay empresas; si hay empresas, hay empleo; y, al final del camino, hay bienestar. Compartir lo que sabemos no es generosidad ni marketing. Es el modo en que un componente del Modelo de Mercadona se conecta con el siguiente.

Este post está dedicado a Juanjo Ponz Jordi Chulia Benlloch y al resto del equipo de Shop que lleva la tienda de Mercadona Online que son los que realmente han hecho este proyecto realidad. Mención especial también para Cristian Moncho Ivorra del equipo de Staff por hacer que el buscador vuele.

SearchMO Playbook — CLAUDE.md para construir tu propio buscador

La otra mitad es la dirección. Qué estás construyendo exactamente, por qué esa decisión y no otra, cómo vas a saber que lo que el agente te devuelve es correcto. Todo eso sigue sin resolverse cuando la única herramienta que tienes es “hablar con la IA”.

En los últimos meses ha aparecido una respuesta concreta a ese hueco, y está empezando a consolidarse con un nombre: spec-driven development. La idea es vieja — escribir specs antes que código existe desde los setenta — pero lo que es nuevo es que ahora las specs no son para humanos. Son para el agente. Y cambian radicalmente lo que puedes construir con IA sin perder el control de lo que estás construyendo.

Qué significa “spec” ahora

Antes de entrar en herramientas concretas, conviene entender qué significa “spec” en este contexto, porque no es lo que significaba hace diez años.

Una spec tradicional era un documento muerto. Alguien lo escribía, alguien lo leía, alguien lo ignoraba cuando llegaba la hora de programar. Al final del proyecto el documento y el código no se parecían en nada, y todo el mundo había aprendido a convivir con esa divergencia como quien convive con el goteo del grifo del baño.

Una spec para un agente de IA es otra cosa. Es un artefacto vivo que el agente lee antes de actuar, actualiza cuando toma decisiones, y consulta para verificar que lo que ha hecho encaja con lo que se le pidió. No es documentación post-hoc: es el contrato de trabajo. Puede ser un plan de fases, un conjunto de criterios de aceptación, una descripción del comportamiento esperado, una lista de verificaciones. Todo junto normalmente.

La diferencia práctica es brutal. Con vibe coding puro le dices al agente “hazme un buscador” y te lo hace. Lo que no sabes es qué asunciones ha tomado, qué edge cases ha ignorado, qué ha decidido por ti sin preguntarte. Con spec-driven development le das al agente el mismo “hazme un buscador”, pero también le das un documento que dice “estos son los requisitos no funcionales, estos los casos que tiene que manejar, esta la forma de validar que funciona, y estas las decisiones que no puedes tomar sin consultarme”. El agente ya no es un genio caprichoso. Es un ingeniero con mandato.

Esto lleva cincuenta años intentándose

Antes de que nadie hablase de vibe coding, agentes o spec-driven, la industria del software ya tenía claro que escribir código sin especificar antes qué debía hacer era una forma elegante de construir castillos sobre arena. La historia intelectual es larga y los nombres son conocidos, aunque casi nadie los cita fuera de la academia.

En 1969, Tony Hoare publicó An Axiomatic Basis for Computer Programming. Su propuesta era incómoda y radical: cada fragmento de código debía poder describirse con una pre-condición (lo que es cierto antes de ejecutarlo) y una post-condición (lo que garantiza después). La spec no era un documento anexo. Era el programa. El código era solo una forma de implementarlo.

Tres años después, en 1972, David Parnas publicó On the Criteria To Be Used in Decomposing Systems into Modules. Introdujo la idea de que cada módulo de software debía ocultar sus decisiones internas y exponer solo un contrato: qué puede asumir el cliente del módulo, qué promete cumplir el módulo. Contrato primero, implementación después.

En 1976, Edsger Dijkstra llevó la idea al extremo con A Discipline of Programming. Su tesis: el programa se deriva de la especificación, no al revés. Primero formalizas qué quieres que haga. Luego demuestras, paso a paso, que tu código lo cumple. Ingeniería como matemática.

El giro decisivo lo dio Donald Knuth en 1984 con Literate Programming. Knuth no hablaba de pre-condiciones ni demostraciones formales. Hablaba de algo más humano: un programa es un documento dirigido a un lector, y el código está embebido en la prosa que lo explica, no al revés. Su frase famosa: los programas deben tratarse como obras de literatura dirigidas a seres humanos.

Dos años después, en 1986, Bertrand Meyer formalizó la idea en un lenguaje real con Design by Contract: invariantes, pre y post-condiciones como parte del código ejecutable de Eiffel, el primer y único lenguaje realmente Orientado a Objetos. No como documentación. Como contrato verificable en tiempo de ejecución.

Y en 1994, Leslie Lamport publicó TLA+, un lenguaje para especificar sistemas distribuidos antes de escribirlos. Amazon, Microsoft y Google lo usan hoy para verificar piezas críticas de su infraestructura.

¿Por qué entonces casi ninguna empresa aplica estas ideas en su día a día? Porque el coste siempre fue asimétrico. Escribir la spec primero era lento. Mantenerla sincronizada con el código era un trabajo extra que nadie pagaba. El software funcionaba sin ella, aunque mal. Así que la industria eligió la vía rápida y acumuló cincuenta años de deuda conceptual.

Lo que ha cambiado ahora es el lector. Knuth escribía para humanos que casi nunca leían los programas de otros. Hoy el agente sí los lee. Los lee siempre. Y si tu código, tu arquitectura y tus decisiones no son legibles para él, no puede trabajar. Lo que era una aspiración ética se ha convertido en un requisito funcional.

Spec-driven development no es una moda de 2026. Es la primera vez en cincuenta años que hay un incentivo económico real para hacer lo que Hoare, Parnas, Dijkstra, Knuth, Meyer y Lamport llevan diciéndonos desde los setenta.

GSD: el workflow como contrato

GSD son las siglas de Get Shit Done. Es un conjunto de comandos que se instala encima de Claude Code y que convierte cualquier trabajo no trivial en una secuencia estructurada de fases con artefactos versionados. Lo desarrolló un ingeniero llamado Dan Gooding y está ganando adopción en equipos que usan agentes de IA en proyectos serios.

La idea central es sencilla: antes de escribir una línea de código, el agente te obliga a pasar por cuatro etapas — discutir, planificar, ejecutar, verificar — y cada una deja un artefacto en disco que la siguiente lee. No hay atajos. Si intentas saltar directamente a “implementa esto”, GSD te detiene y te hace definir primero el qué, el cómo y los criterios de aceptación.

En la práctica, trabajas con una serie de comandos muy concretos. /gsd:discuss phase hace al agente preguntarte lo que necesita saber antes de planificar — qué asunciones está tomando, qué decisiones dependen de ti, qué riesgos ve. /gsd:plan-phase genera un PLAN.md con la descomposición en tareas, dependencias entre ellas, y los tests que definirán que está hecho. /gsd:execute-phase ejecuta ese plan con commits atómicos por tarea. /gsd:verify-work valida al final que lo que se ha construido cumple los criterios que se fijaron al principio.

El resultado es que tu carpeta de trabajo deja de ser un vertedero de código generado y se convierte en una estructura de carpetas tipo .planning/001-fase-auth/ con tres ficheros: RESEARCH.md (lo que el agente investigó antes de planificar), PLAN.md (lo que va a hacer), VERIFICATION.md (cómo demostramos que está hecho). Esto no es documentación. Es el contrato que el agente firma consigo mismo y que tú puedes leer, auditar y modificar en cualquier momento.

Lo potente de GSD es que te obliga a pensar arriba-abajo. Primero el roadmap del proyecto. Luego las fases. Luego los planes. Luego el código. Cuando lo usas durante un par de semanas notas algo incómodo y revelador: la mayor parte del valor no está en la ejecución con IA, está en la conversación estructurada que te fuerza a tener antes. El agente te obliga a concretar cosas que de otra forma habrías dejado ambiguas. Y esas cosas ambiguas son exactamente las que después reventaban en producción.

El coste es evidente: GSD es mucho más lento que vibe coding para tareas pequeñas. Si lo que quieres es un script de veinte líneas, usar GSD es matar moscas a cañonazos. Pero para cualquier proyecto que dure más de una sesión y tenga más de una decisión importante, la inversión se paga varias veces.

Superpowers: disciplina en cada decisión

Superpowers ataca el mismo problema desde el ángulo opuesto. Lo desarrolló Jesse Vincent, un ingeniero conocido en la comunidad de Claude Code, y su tesis es muy distinta a la de GSD: el problema no es que el agente no tenga un plan global, es que en cada microdecisión del día a día se salta el rigor que aplicaría cualquier ingeniero senior.

Un ejemplo concreto. Le pides al agente que arregle un bug. Sin Superpowers, el patrón habitual es: el agente lee el error, propone una hipótesis, modifica el código, dice “listo”. A veces funciona. Otras veces parchea un síntoma y deja la causa real intacta. Con Superpowers activada, el agente no puede responder hasta que invoque una skill llamada systematic-debugging. Esa skill e obliga a seguir unprocedimiento: reproducir el bug de forma determinista, formular hipótesis, aislarlas una a una, verificar el fix con un test antes de declarar victoria. No es una sugerencia. Es un gate obligatorio.

Superpowers es, en la práctica, una colección de unas quince skills que cubren momentos concretos en los que los agentes suelen pifiarla: brainstoring antes de diseñar una feature, test-driven-development antes de escibir código, verification-before-completion antes de declarar algo como terminado, receiving-code-review cuando el usuario le da feedback, dispatching-paralle-agents cuando hay trabajo independiente que se puede paralelizar. Cada skill s un procedimiento probado empaquetado en un fichero markdown qu el agente carga cuado elcontexto lo requiere.

La parte inteligente del diseño es que las skills se auto-invocan. No tienes que acordarte de decir “usa TDD ahora”. El agente detecta que va a escribir código nuevo y la skill se activa sola. Detecta que estás a punto de declarar una tarea como hecha y la skill de verificación le exige evidencia antes de dejarle hacerlo. Las skills son, en el fondo, contratos de comportamiento que el agente firma con su yo futuro: “cuando me toque hacer X, voy a seguir obligatoriamente Y pasos”.

Donde GSD es arriba-abajo (primero el plan, luego la ejecución), Superpowers es abajo-arriba (no importa qué estés haciendo, cuando hagas esto lo harás así). Donde GSD protege contra la falta de dirección, Superpowers protege contra la falta de disciplina. Y aquí está el punto: son dos problemas distintos que requieren dos soluciones distintas.

En mi experiencia, la skill más valiosa de Superpowers es la más aburrida de todas: verification-before-completion. El agente no puede decir “hecho” hasta que ha ejecutado el comando que demuestra que funciona y ha mostrado la salida. Parece obvio. En la práctica, evita el 80% de los “terminé” prematuros que provocan después una ronda entera de debugging innecesario.## La diferencia que importa

La primera reacción cuando ves GSD y Superpowers juntos es pensar que compiten. Las dos hablan de estructurar el trabajo con agentes. Las dos meten disciplina donde vibe coding la esquiva. Las dos generan artefactos y fuerzan procedimientos. Parecen dos respuestas al mismo problema. No lo son. Resuelven problemas distintos, y entenderlo es la diferencia entre elegir uno, elegir otro, o combinarlos.

GSD organiza el **proyecto**. Su unidad de trabajo es la fase, que dura horas o días, y su foco es asegurar que antes de ejecutar algo haya un contrato claro de qué se va a hacer, por qué, y cómo se va a validar. Es el equivalente moderno de la idea de Dijkstra: deriva el código de la especificación. Si tu problema es que los agentes se lanzan a construir sin saber bien qué están construyendo, GSD es tu respuesta.

Superpowers organiza la **decisión**. Su unidad de trabajo es cada interacción individual del agente, que dura segundos o minutos, y su foco es que en cada microdecisión el agente siga el procedimiento correcto. Es el equivalente moderno de la idea de Meyer: contratos ejecutables que se verifican en tiempo de ejecución. Si tu problema es que los agentes se saltan pasos que cualquier ingeniero senior daría por obligatorios, Superpowers es tu respuesta.

En términos prácticos, la diferencia se nota así. Un proyecto gestionado con GSD pero sin Superpowers acaba con planes y fases impecables, pero cada fase internamente tiene los mismos problemas de vibe coding — el agente se salta verificaciones, propone fixes sin hipótesis, declara cosas hechas sin evidencia. Un proyecto con Superpowers pero sin GSD tiene cada decisión bien tomada, pero el conjunto carece de dirección — el agente implementa bien cosas que quizá no tenía que implementar. Los dos fallan, por motivos opuestos.

Juntos, se complementan de manera casi perfecta. GSD define el qué y el por qué a nivel de proyecto. Superpowers garantiza el cómo a nivel de cada paso. El resultado es lo más cercano a trabajar con un ingeniero senior disciplinado que he visto hasta ahora — no porque el agente sea un ingeniero senior, sino porque la combinación de estructura y disciplina le impide actuar como un junior que se salta pasos.

Hay una lectura más profunda aquí que conviene no perder. GSD es la herencia directa de la escuela formal de Hoare, Dijkstra y Parnas: el rigor viene de especificar primero. Superpowers es la herencia directa de Knuth y Meyer: el rigor viene de construir las garantías dentro del propio acto de programar. Medio siglo después, los dos caminos siguen siendo válidos. Y siguen siendo complementarios.

El sistema de previsión que estamos construyendo así

Voy a aterrizar todo esto con el proyecto real en el que más lo estoy aplicando. En Mercadona Tech estamos construyendo un sistema de previsión de demanda a escala industrial: predecir cuánto se va a vender de cada producto, en cada centro, en cada franja horaria, para cada día. Más de doscientas mil series temporales reconciliadas en cinco niveles de agregación, con intervalos de confianza que tienen que tener garantías matemáticas de cobertura. No es un proyecto donde vibe coding pueda llevarte lejos. Una decisión mal tomada en una fase temprana contamina todas las posteriores, y muchas de las decisiones solo se ven con años de oficio.

Aquí GSD hace su trabajo. El proyecto vive en fases: exploración de datos, baselines, modelos candidatos, reconciliación jerárquica, calibración de intervalos, despliegue a producción. Cada fase tiene su plan, sus criterios de aceptación y su verificación. Los documentos que se generan no son reportes para enseñar a un jefe. Son el contrato que el siguiente paso del proyecto lee antes de ejecutar. Cuando un colaborador entra al proyecto, no tiene que preguntarme qué está pasando — lee la fase activa y lo sabe.

Aquí Superpowers hace el suyo. Las disciplinas de verificación impiden que el agente reporte una métrica sin haberla validado con backtesting riguroso. El procedimiento obligatorio de debugging aparece cada vez que un modelo degrada en una fracción del dataset y nos fuerza a aislar la causa antes de parchear. La skill de verificación-antes de-completar evita los falsos positivos clásicos de la ciencia de datos, donde algo parece funcionar porque se ha medido mal.

Sin GSD, un proyecto de esta envergadura se convierte rápido en treinta notebooks que nadie sabe cómo conectar. Sin Superpowers, publicas una métrica que parece excelente hasta que la realidad te corrige. Con ambos, la IA acelera cada fase sin renunciar al rigor que un sistema de este tamaño exige.

Las tres capas

Si hace una semana dejábamos vibe coding como la Thermomix del software —velocidad accesible para todo el mundo —, ahora podemos terminar de dibujar el cuadro completo. Construir con IA no es una técnica, son tres capas que se apoyan unas en otras.

La primera capa es la velocidad. Vibe coding. La capacidad de conversar con un agente y ver cómo el código aparece en segundos. Resuelve el problema que durante décadas fue el cuello de botella del desarrollo: la distancia entre idea y prototipo.

La segunda capa es la dirección. Spec-driven development en su encarnación moderna, con herramientas como GSD al frente. Resuelve un problema más sutil y más viejo: cómo garantizar que lo que el agente construye responde realmente a lo que hace falta, no a lo que el agente ha interpretado que hacía falta. Hoare lo vio en el sesenta y nueve. Dijkstra en el setenta y seis. Nosotros lo estamos aplicando por primera vez a escala gracias a que el coste de mantener specs vivas ha colapsado.

La tercera capa es la disciplina. Superpowers y el resto de frameworks que meten rigor en cada decisión individual del agente. Resuelve el problema de que un agente que en promedio lo hace bien puede hacerte daño en los pocos casos en los que se salta un paso crítico. Meyer lo formalizó en Eiffel en los ochenta. Hoy lo tenemos disponible como skills que el agente invoca solo.

Las tres juntas son mucho más que la suma de las tres por separado. Velocidad sin dirección te lleva rápido a un sitio que no era el que querías. Dirección sin disciplina te lleva al sitio correcto con un sistema que falla cuando más importa. Disciplina sin velocidad te deja atrás, fabricando calidad en un mercado que premia la iteración rápida. Y velocidad sin dirección ni disciplina es exactamente lo que los ingenieros senior temen cuando oyen hablar de vibe coding.

La pregunta que te deberías hacer no es si adoptar IA en tu proceso de desarrollo. Esa batalla ya está resuelta. La pregunta es si estás adoptando las tres capas o solo la primera. Porque la primera es la que sale gratis. Las otras dos son las que deciden si dentro de un año tendrás un sistema que se sostiene o una deuda técnica imposible de pagar.

Si en algún momento te descubres pensando “el agente lo hace rápido pero no me fío de lo que entrega”, lo que te falta no es más IA. Es spec y disciplina. Y ambas existen, están maduras, y llevan cincuenta años esperando su momento.

Para unos es el futuro. Para otros es el principio del fin de la ingeniería de software seria. Yo llevo meses haciéndolo, y mi conclusión es que ambos tienen razón — pero por motivos que ninguno de los dos está viendo.

El término lo acuñó Andrej Karpathy a principios de 2025. Ex-director de IA en Tesla, cofundador de OpenAI. No es precisamente alguien que no entienda código. Su definición era provocadora a propósito: “Te rindes al vibe, abrazas los exponenciales, y te olvidas de que el código existe.”

La reacción fue inmediata. Los ingenieros senior se echaron las manos a la cabeza. Los builders que llevaban semanas prototipando con IA asintieron en silencio. Twitter se convirtió en un campo de batalla entre puristas y pragmáticos.

Pero el debate se está dando en términos equivocados. La pregunta no es si vibe coding “funciona” o “no funciona”. La pregunta es para qué funciona, para qué no, y qué cambia en cómo organizamos equipos de producto cuando una parte del equipo lo adopta.

Piensa en la Thermomix. Cuando apareció, los chefs profesionales la despreciaron. “Eso no es cocinar.” Y tenían razón — técnicamente. Pero millones de familias empezaron a preparar platos que antes les parecían imposibles. La Thermomix no sustituyó a los chefs. Cambió lo que podía hacer la gente que no era chef.

Vibe coding es la Thermomix del software. Y eso tiene implicaciones enormes para cualquiera que gestione un equipo de producto.

Cuando funciona (y funciona más de lo que los puristas admiten)

Hay un patrón que se repite en todos los equipos que conozco que han adoptado herramientas de vibe coding: el primer éxito llega rápidamente y es espectacular.

Un prototipo funcional en horas en lugar de días. Una herramienta interna que llevaba meses en el backlog y de repente existe. Un script de migración de datos que hubiera requerido una semana de trabajo manual. Una prueba de concepto para convencer a un stakeholder que antes necesitaba dos sprints de inversión.

No es magia. Lo que está pasando es que una enorme cantidad de código que escribimos es estructural, repetitivo, predecible. Configurar un proyecto, conectar una API, montar un CRUD, escribir tests unitarios para casos estándar. Un buen agente de IA hace esto en minutos porque ha visto millones de implementaciones similares. Y lo hace razonablemente bien.

Donde el vibe coding brilla de verdad es en ese espacio donde sabes exactamente lo que quieres pero el coste de implementarlo siempre ha sido demasiado alto. Herramientas internas que nadie prioriza. Automatizaciones que “ya haré cuando tenga tiempo”. Prototipos para validar ideas antes de invertir un sprint entero. Para un PM o un tech lead, esto es transformador: la distancia entre idea y validación se acorta radicalmente.

Cuando explota (y explota más de lo que los evangelistas admiten)

Ahora la otra cara. Y es una cara que muchos están descubriendo de la peor manera posible.

El problema fundamental del vibe coding es lo que yo llamo la deuda técnica invisible. Cuando un ingeniero escribe código, toma cientos de micro-decisiones: cómo manejar un error, qué pasa si la conexión se cae, cómo escala esto cuando hay diez mil usuarios concurrentes, qué asunciones estoy haciendo sobre los datos de entrada. Cada decisión es una pieza de conocimiento que vive en la cabeza del equipo.

Cuando el código lo genera una IA y tú solo validas que “funciona”, esas decisiones se toman igualmente. Pero nadie sabe cuáles fueron. El código pasa los tests. La feature funciona en staging. Todo verde. Hasta que en producción un edge case que nadie consideró tumba el servicio un viernes a las once de la noche. Y entonces necesitas debuguear código que no escribiste, basado en decisiones que no tomaste, con asunciones que no conoces.

He visto equipos que prototiparon algo en dos días con vibe coding y luego necesitaron tres semanas para hacerlo production-ready. El ratio real no es 10x. Es 2x con asterisco. Y el asterisco es importante.

El segundo problema es más sutil: la falsa sensación de competencia. Cuando puedes generar código que funciona sin entender por qué funciona, empiezas a tomar decisiones de arquitectura sin tener las bases para tomarlas. Es como conducir un Fórmula 1 con piloto automático — funciona hasta la primera curva que el sistema no ha visto antes.

Lo que cambia para el PM y el Tech Lead

Si gestionas un equipo de producto, vibe coding ya te afecta aunque no lo hayas adoptado oficialmente. Alguno de tus ingenieros lo está usando. La pregunta es si lo sabes y si has pensado en qué significa.

Lo primero que cambia son las estimaciones. Cuando un junior puede entregar en días lo que antes costaba semanas, tus modelos de capacidad dejan de funcionar. ¿Asignas más trabajo? ¿Reduces el equipo? ¿Asumes que la velocidad es sostenible? Ninguna de las tres respuestas es correcta sin contexto.

Lo segundo que cambia es el code review. Ya no estás revisando el trabajo de un ingeniero que tomó cada decisión conscientemente. Estás revisando código generado donde el autor no puede explicarte por qué eligió ese patrón y no otro. Esto requiere un tipo de revisión diferente: menos “¿por qué hiciste esto así?” y más “¿qué pasa si esto falla?”. Más adversarial, menos colaborativo.

Lo tercero, y esto es lo más importante para PMs: cambia lo que puedes pedir. Antes, un prototipo era caro. Ahora es barato. Eso significa que puedes validar más hipótesis antes de comprometer al equipo. Puedes mostrar un prototipo funcional al stakeholder en lugar de un wireframe. Puedes probar tres enfoques en paralelo en lugar de apostar por uno. Si eres PM y no estás aprovechando esto, estás dejando dinero en la mesa.

El buscador que construimos hablando

Voy a ponerte un ejemplo real, porque creo que es la forma más honesta de hablar de esto.

En Mercadona Tech teníamos un problema con nuestro buscador de la tienda online. Usábamos Algolia, un SaaS que nos costaba entre 9.000 y 15.000 dólares al mes. Funcionaba, pero teníamos un 4% de búsquedas sin resultados, un ranking que no podíamos controlar como queríamos, y una dependencia total de un proveedor externo para una pieza crítica del negocio: 4,4 millones de búsquedas a la semana.

Decidimos construir nuestro propio buscador. Búsqueda híbrida con keyword y semántica, un modelo de Learning to Rank entrenado con datos reales de clics de nuestros usuarios, autocompletado, el stack completo. Y lo desarrollamos con Claude Code.

¿Qué funcionó? La velocidad de exploración fue brutal. Analizar 479 megabytes de datos de catálogo y analítica, iterar sobre 12 experimentos diferentes, hacer una competición de 5 modelos de ranking con validación cruzada — todo eso se hizo conversando con agentes de IA. Tareas que hubieran requerido semanas de trabajo de un equipo de data science las completamos en días.

¿Qué no funcionó sin intervención humana? Las decisiones que definen si el sistema aguanta en producción o se cae el primer día. No usar Elasticsearch porque el coste y la latencia no encajaban. No usar Cloud Run porque los cold starts son fatales para un buscador. Diseñar un índice maestro con bitsets en lugar de 762 índices separados. Establecer las reglas de gobernanza del modelo: validación walk-forward en lugar de aleatoria, corrección de sesgo de posición obligatoria, un guardrail que bloquea automáticamente cualquier modelo que degrade más de un 2% las métricas.

Esas 29 decisiones técnicas no las tomó la IA. Las tomó un equipo con criterio. Y son exactamente las decisiones que separan un prototipo que impresiona en una demo de un sistema que sirve 4,4 millones de búsquedas a la semana sin caerse.

El resultado: un buscador que mejora el ranking un 85% respecto a Algolia, elimina completamente las búsquedas sin resultados, y cuesta menos de 900 dólares al mes. Construido en gran parte con vibe coding. Pero las decisiones que importan, tomadas por personas.

La herramienta, no la respuesta

Vibe coding no es revolución ni espejismo. Es una herramienta extraordinariamente potente que está en manos de todo el mundo por primera vez.

La Thermomix no mató a los restaurantes. Pero cambió para siempre lo que una persona sin formación culinaria podía preparar en su cocina. Vibe coding no va a eliminar a los ingenieros senior. Pero va a cambiar radicalmente lo que puede construir alguien con una idea clara y ganas de iterar.

La pregunta que deberías hacerte no es “¿vibe coding sí o no?”. Es: ¿en qué partes de mi producto estoy gastando tiempo de ingeniería en trabajo que una IA puede hacer igual de bien? ¿Y en qué partes estoy en riesgo de confiar en código que nadie entiende realmente?

Si puedes responder a esas dos preguntas con honestidad, el vibe coding va a ser una ventaja enorme. Si no puedes, va a ser una trampa.

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:

1. Claridad del Usuario: ¿Sabemos exactamente quién es el usuario y en qué contexto opera?

2. Profundidad del Trabajo: ¿Entendemos la verdadera necesidad debajo de la característica, o estamos resolviendo una solución?

3. Especificidad del Comportamiento: ¿Podemos medir si el trabajo está siendo resuelto?

4. Viabilidad Técnica: ¿Es razonable construir esto con la tecnología disponible?

5. Alineación Estratégica: ¿Ayuda esto a alcanzar los objetivos del producto y la compañía?

6. 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.

La paradoja del trabajo de software: El riesgo crece más rápido que el tamaño

Hace poco más de una década, mientras trabajaba en equipos de entrega continua, Eduardo Ferro se dio cuenta de algo que parecía desafiar la lógica. Si tomabas una tarea que normalmente tardaba una semana y la hacías el doble de grande, el riesgo asociado no se duplicaba. Se multiplicaba por cuatro. A veces, incluso por diez.

Este descubrimiento no era teórico. Lo vio una y otra vez en retros, en despliegues fallidos, en historias que se arrastraban sprint tras sprint. El patrón era consistente: cuanto más grande era una historia, más cosas podían salir mal. No de manera lineal. De manera exponencial.

La razón es simple pero profunda. Una historia pequeña —una que toma tres días o menos— es un “experimento sobrevivible”. Si algo falla, el equipo puede revertir rápidamente, aprender, y seguir adelante. El costo del error es manejable.

Pero una historia de dos semanas o más es diferente. Si falla, has invertido semanas en el trabajo. Otros equipos están esperando. Revertir no es una opción elegante; es un desastre. Los equipos no revierten. Aceptan un resultado mediocre. Dedican más tiempo a arreglarlo. La historia se estira. La incertidumbre crece. El riesgo se expande.

Esta es la razón por la que Eduardo Ferro diseñó el módulo de Story Splitting que hemos usado en el AI Mercadona User Story Framework: no como un ejercicio académico de descomposición, sino como una defensa práctica contra el riesgo exponencial. Su objetivo es simple pero ambicioso: detectar automáticamente las historias que son demasiado grandes para ser seguras y descomponerlas en incrementos que sean, cada uno, independientemente valiosos, desplegables por sí solos, y completables en tres días o menos.

El primer paso: Detectar cuando el peligro está oculto en el lenguaje

Eduardo reconoció que el tamaño excesivo de una historia casi siempre se anuncia a sí mismo. No a través del número de líneas, sino a través del lenguaje. Las historias que son demasiado grandes tienden a usar palabras específicas que revelan que esconden múltiples historias dentro de una sola.

Identificó seis categorías de indicadores lingüísticos que actúan como banderas rojas.

Primera categoría: las conjunciones coordinantes. Cuando una historia dice “Los usuarios pueden subir y descargar archivos”, está ocultando dos historias completamente separadas. Subir es un flujo completamente diferente al de descargar. Tienen diferentes interfaces, diferentes casos de error, diferentes criterios de éxito.

Segunda categoría: los conectores de acción. Palabras como “gestionar”, “administrar”, “procesar”, “manejar”. Estos verbos casi siempre esconden operaciones CRUD completas. “Gestionar usuarios” es crear, leer, actualizar y eliminar usuarios. Eso son potencialmente cuatro historias.

Tercera categoría: los conectores de secuencia. Palabras como “antes”, “después”, “luego”, “entonces”. Revelan historias que agrupan pasos separables que podrían entregarse de forma independiente.

Cuarta categoría: los indicadores de alcance. Palabras como “incluyendo”, “además”, “también”. Cada palabra de este tipo es un síntoma de que alguien añadió una característica más a lo que ya era una historia completa.Quinta categoría: los indicadores de opcionalidad. Palabras como “o bien”, “opcionalmente”, “alternativamente”. Cuando una historia presenta múltiples caminos opcionales, está escondiendo historias que deberían desarrollarse por separado.

Sexta categoría: los indicadores de excepción. Palabras como “excepto”, “a menos que”, “sin embargo”, “en caso de”. La mejor práctica es desarrollar y desplegar el caso base primero —el 80% del trabajo—, y después, en historias posteriores, añadir las excepciones y los bordes. Las excepciones son donde la mayoría de los bugs se esconden.

El genio de Eduardo en el diseño del módulo fue automatizar esto. El modulo de Eduardo que usamos en el AI Mercadona User Story Framework escanea la descripción de la historia buscando exactamente estas palabras y estructuras lingüísticas. Cuando las encuentra, levanta una bandera. No para rechazar la historia, sino para alertar al equipo de que aquí hay complejidad oculta que merece atención consciente.

El segundo paso: Transformar la detección en acción

Detectar que una historia es demasiado grande es solo el primer paso. El verdadero valor está en saber cómo dividirla. Eduardo Ferro, basándose en años de experiencia con equipos en entrega continua, destiló nueve heurísticas específicas de splitting que transforman las historias monolíticas en historias pequeñas, seguras, y todavía valiosas.

Heurística 1: Comenzar por los outputs. Los outputs son entidades discretas. Si estás construyendo un reporte, puedes entregar primero la versión más simple: el resumen en texto plano. Después, los detalles. Después, la exportación a CSV. Cada uno puede validarse, desplegarse y usarse de forma independiente.

Heurística 2: Estrechar el segmento. Entregar funcionalidad completa para el grupo más pequeño posible. Si estás construyendo una característica para “todos los usuarios”, pregúntate: ¿Puedo entregarla primero solo para los empleados de tienda? Esta heurística reduce dramáticamente la complejidad.

Heurística 3: Extraer la utilidad básica. El MVP es lo mínimo. Lo bello puede venir después. Si estás construyendo cancelación en lotes, la primera historia es subir una lista de IDs. La segunda añade filtros. La tercera añade validación. Cada una entrega valor y cada una es pequeña.

Heurística 4: De lo dummy a lo dinámico. Los datos estáticos primero, después los datos reales. Si estás construyendo un dashboard, la primera historia muestra datos hardcodeados. La segunda conecta a una fuente real. La tercera añade auto-refresh. Divide el problema arquitectónico del problema de datos.

Heurística 5: Simplificar los outputs. Formatos más simples primero. Si estás generando un reporte, la primera historia genera CSV. La segunda genera PDF. La tercera lo auto-envía por email. La complejidad crece de forma predecible.

Heurística 6: Dividir por capacidad. Limitar el alcance por volumen. La primera historia procesa 100 artículos. La segunda 1,000. La tercera es ilimitada. Cada versión es completamente útil por sí misma.

Heurística 7: Dividir por ejemplo. Para cambios grandes, usar casos de uso concretos. Si estás construyendo comunicación post-cancelación, la primera historia es email a usuarios web. La segunda es SMS a usuarios móviles. La tercera es tickets en soporte. Cada una es un flujo completo y valioso de punta a punta.

Heurística 8: Aprender vs Ganar. Separar la investigación de la entrega. Si estás construyendo un sistema de recomendaciones con machine learning, la primera historia es un spike de investigación: 3 días máximo, que responde una pregunta específica. La segunda es una versión simple basada en reglas. La tercera, quizás 3 sprints después, es el modelo de ML. La investigación y la entrega son diferentes tipos de trabajo. Mezclarlas casi siempre hace que ambas sean malas.

Heurística 9: Ponerla en muletas. Entregar con pasos manuales o backends más simples. Si estás sincronizando inventario, la primera historia es subir manualmente un CSV y procesar cambios. La segunda es un script semi-automático. La tercera es sincronización completa y automática. Cada una es una historia valiosa que el negocio puede usar.

Lo que Eduardo Ferro entendió es que estas heurísticas no son arbitrarias. Cada una separa una dimensión diferente de la complejidad. Cada una permite que un equipo entregue, valide, aprenda, y luego avance.

El concepto que todo lo une: El experimento sobrevivible

Hay un concepto central que recorre todas las heurísticas: el “experimento sobrevivible”.

Una historia pequeña —tres días o menos— es un experimento. Si descubre que no es el enfoque correcto, el equipo puede revertir rápidamente. El costo del aprendizaje es bajo. El experimento falló, pero fue barato.

Una historia grande —dos semanas o más— no es un experimento sobrevivible. Si falla, la inversión es demasiado grande. El equipo no puede revertir. Tiene que aceptar una solución mediocre. Esto es lo opuesto a la agilidad.

Cuando divides una historia grande en historias pequeñas, cada una de ellas se convierte en un experimento sobrevivible. El equipo puede validar supuestos de forma frecuente, obtener feedback frecuente, y ajustar el rumbo. La suma de las historias pequeñas no es solo más manejable. Es fundamentalmente más segura.

La regla que muchos olvidan: Siempre vertical, nunca horizontal

Hay una regla en el framework de Eduardo Ferro que es tan importante, y tan frecuentemente violada, que merece énfasis especial: las divisiones siempre deben ser verticales, nunca horizontales.

Una división horizontal sería separar la historia en capas técnicas: “Implementar el endpoint de API”, “Implementar la lógica de negocio”, “Implementar la interfaz de usuario”. Esto parece lógico desde la perspectiva técnica. Pero es una trampa. Porque ninguno de estos “trabajos” entrega valor por sí solo.

Si algo sale mal en la lógica de negocio, has comprometido también el trabajo del endpoint y la interfaz. Las “historias” horizontales no llegan nunca a done. Se agrupan de nuevo cuando llega el momento del release. Y estás de vuelta a una historia grande.

La manera correcta es vertical. La historia debe cruzar todas las capas de tecnología y entregar valor completo de punta a punta. “Los usuarios pueden crear un pedido con los datos básicos” cruza la interfaz, la API, la lógica de negocio, la base de datos. Y entrega valor.

El marco de validación: Criterios que no son negociables

Una vez que tienes una propuesta de split, el framework de Eduardo ofrece cuatro criterios que cada split propuesto debe cumplir. Si no los cumple, el split no es válido.

Primero, la historia debe ser independientemente valiosa. El usuario o el negocio pueden obtener valor de esta historia completada, sin necesitar las otras historias que se dividieron de la original.

Segundo, la historia debe ser desplegable sola. Si la completaste, puedes desplegarla a producción sin desplegar las otras historias.

Tercero, la historia debe ser completable en tres días o menos. Esta es la línea que dibuja Eduardo. Si toma más de eso, tiene riesgo exponencial.

Cuarto, la historia debe entregar valor de punta a punta. No es un “componente de la infraestructura”. Es una capacidad completa que el usuario puede ejercer.

La tabla de decisión: Automatizar lo que puede ser automatizado

Una de las características más útiles del módulo es la tabla de decisión. Es una asignación explícita de indicadores lingüísticos a heurísticas de splitting.

Si encuentras “gestionar”, la tabla recomienda Heurística #1 (comenzar por outputs). Si encuentras “y”, sugiere dividir por conjunción. Si encuentras “para todos los usuarios”, recomienda Heurística #2 (estrechar el segmento).

Esto convierte lo que podría ser un ejercicio subjetivo en algo sistemático. Eduardo capturó la sabiduría que un experto en descomposición tendría y la empaquetó en reglas que cualquier equipo puede aplicar. La descomposición no es un arte. Requiere disciplina. Y eso es escalable.

En la práctica: Cómo cambia el trabajo

Sin el framework, un equipo recibe una historia como: “Gestionar usuarios del sistema, incluyendo creación, actualización y eliminación, además de reseteo de contraseñas, con soporte para roles y permisos, opcionalmente con autenticación de dos factores.” Es grande. Se estima en 21 puntos. Se estira a tres sprints. El usuario obtiene algo, pero no es exactamente lo que esperaba.

Con el framework de Story Splitting, la misma historia se convierte en:

Historia 1 (3 días): Los usuarios administradores pueden crear usuarios locales con nombre, email y contraseña inicial.

Historia 2 (2 días): Los usuarios administradores pueden editar el email y el nombre de usuarios existentes.

Historia 3 (2 días): Los usuarios administradores pueden eliminar usuarios.

Historia 4 (3 días): Los usuarios administradores pueden asignar roles (admin, editor, viewer). Permisos se aplican basándose en roles.

Historia 5 (3 días): Los usuarios pueden resetear sus propias contraseñas a través de un link enviado por email.

Historia 6 (spike de 3 días): Investigación de autenticación de dos factores.

Historia 7 (3 días, después del spike): Los usuarios pueden opcionalmente configurar 2FA con SMS.

7 historias pequeñas en lugar de 1 gigante. El equipo completa la primera en dos días. Obtiene feedback. Para el final de las dos primeras semanas, ha entregado cuatro historias completamente funcionales — el 70% del valor. Comparado con el escenario tradicional donde aún están lidiando con bugs de permisos, esto es un cambio radical.

Conclusiones: El cambio que cambia cómo pensamos sobre el trabajo

El módulo de Story Splitting del AI Mercadona User Story Framework, diseñado por Eduardo Ferro, representa algo más profundo que una técnica de descomposición. Representa un cambio en cómo pensamos sobre el riesgo en el desarrollo de software.

El riesgo no es una constante que aumenta linealmente con el tamaño. Aumenta exponencialmente. Una historia de tres días tiene un tipo de riesgo. Una historia de tres semanas tiene un tipo de riesgo completamente diferente. Es el riesgo de no poder revertir. De estar atrapado. De ser forzado a aceptar una solución mediocre.

Cuando divides historias grandes en pequeñas, no estás solo haciendo que sean más manejables. Estás transformando el tipo de riesgo que asumes. Cada pequeña historia es un experimento. El blast radius de cualquier error es pequeño.

El framework de Eduardo automatiza el proceso de identificar dónde el riesgo está oculto —en el lenguaje de las historias que escribimos—, y proporciona un conjunto sistemático de heurísticas para transformar esas historias en incrementos seguros y valiosos.

Hay una razón por la que Eduardo ha enfatizado la regla vertical vs horizontal tan fuertemente. Es porque es fácil fingir que estás siendo ágil mientras estás cometiendo el mismo error viejo: crear trabajo que no entrega valor a nadie hasta que está 100% completo. El framework te obliga a ser honesto. Cada historia debe entregar valor de verdad. Cada historia debe poder ser desplegada sola. Cada historia debe ser completable en tres días.

Cuando pones estas restricciones, algo interesante sucede. Los equipos comienzan a preguntarse: “¿Cuál es la pieza más pequeña que puedo hacer que todavía agregue valor?” En lugar de: “¿Cómo puedo hacer todo de una vez?”

Esta es la pregunta que cambia los equipos de buenos a grandes. Y es la pregunta que el Story Splitting de Eduardo te obliga a hacer.

Próximo Artículo (7 de 7): Story Builder — El módulo final del AI Mercadona User Story Framework que permite a los equipos construir historias desde cero, sin un DAPP como punto de partida, usando un diálogo estructurado que asegura que lo que crean es una historia bien formada desde el inicio.

• Artículo 1: La investigación de DAPP como puerta de entrada al desarrollo impulsado por evidencia

• Artículo 2: Cómo transformar brechas de investigación en hipótesis de Jobs-to-be-Done verificables

• Artículo 3: De Jobs-to-be-Done a User Stories: El puente conceptual entre investigación y ejecución

• Artículo 4: El constructor de historias de usuario: cómo escribir desde cero

En este artículo, abordaremos el desafío que enfrenta cualquier organización de tecnología con múltiples equipos: ¿cómo asegurar consistencia en la calidad de las historias de usuario cuando tienes 12 verticales, decenas de historias por sprint, y cada Product Manager trae su propia intuición sobre qué es “bueno”?

La respuesta no es delegar la evaluación completamente al framework, ni tampoco ignorar el juicio humano experto. Es, en su lugar, crear un sistema compartido de evaluación que sea simultáneamente riguroso y accesible, que eleve los estándares sin paralizar la ejecución, y que permita a los equipos aprender de los patrones que se repiten una y otra vez en el pipeline.

Bienvenidos al Entrenador de Calidad (Quality Coach).

El Problema Invisible de la Inconsistencia

Hace pocos meses, durante una reunión de revisión de backlogs, sucedió algo que probablemente reconocerás si trabajas en una organización con múltiples equipos de producto.

Un Product Manager presentó una historia de usuario que comenzaba así: “Como usuario, quiero poder ver mis pedidos previos para poder realizar compras más rápidas.” El equipo de ingeniería hizo preguntas técnicas sobre la arquitectura. El equipo de diseño preguntó sobre wireframes. Pero nadie hizo la pregunta más fundamental: ¿Sabemos realmente si esto resolverá el problema del usuario?

Cuando examinas esa historia con rigor, descubres que no hay evidencia de cuántos usuarios realmente abandonan el flujo de compra por esta razón, no se especifica cuál es el perfil exacto del usuario, la métrica de éxito es ambigua, y no hay plan para validar experimentalmente si la hipótesis era correcta.

Pero la historia fue aprobada de todas formas. Porque se veía “suficientemente buena.”

En Mercadona Tech, con 12 verticales funcionando en paralelo y decenas de historias en cada sprint, esta inconsistencia se multiplica. El equipo de Checkout trabaja con un estándar de calidad. El equipo de Tienda trabaja con otro. El equipo de Primera Milla con otro diferente. No por incompetencia, sino porque no existe un framework compartido que defina qué es realmente “una buena historia de usuario.”

El Entrenador de Calidad (Quality Coach) existe para resolver exactamente esto: crear un sistema de evaluación que sea lo suficientemente riguroso para garantizar que las historias representen experimentos reales sobre comportamiento del usuario, pero lo suficientemente flexible para respetar el contexto, la urgencia y las realidades operativas de cada equipo.

La Filosofía: Calidad como Experimento, no como Checklist

Antes de sumergirnos en las seis dimensiones de evaluación, necesitamos establecer una premisa filosófica que guía todo el trabajo del Entrenador de Calidad.

La mayoría de los equipos evalúan historias de usuario usando un checklist: ¿Tiene un usuario? Sí. ¿Tiene un beneficio? Sí. ¿Es accionable? Sí. Siguiente.

Pero esto trata la historia como un artículo para entregar, no como una hipótesis para validar.

Jobs-to-be-Done, el framework que sustenta todo el marco de historias de usuario de IA Mercadona, nos enseña que el trabajo verdadero no es la característica que entregamos. El trabajo verdadero es el cambio de comportamiento que queremos producir en el usuario. Una vez que aceptas esa premisa, la pregunta sobre calidad cambia fundamentalmente.

Ya no preguntamos: “¿Está bien escrita?”

Preguntamos: “¿Es verificable como un experimento? ¿Podemos observar si el usuario realmente cambió su comportamiento de la manera que esperamos?”

Esta perspectiva viene del libro “50 Quick Ideas to Improve Your User Stories” de Gojko Adzic y David Evans, dos de los pensadores más influyentes en evolución del movimiento ágil. Su insight central es que una buena historia de usuario no es una promesa vaga, sino una hipótesis comprobable sobre cómo el usuario se comportará diferente después de que entregues la solución.

El Entrenador de Calidad formaliza esta filosofía en seis dimensiones medibles.

Las Seis Dimensiones de Evaluación

El Entrenador de Calidad evalúa cada historia de usuario en una escala de 0 a 10 en cada una de estas dimensiones. No es un enfoque de “pasar/fallar,” sino un sistema diagnóstico que te dice exactamente dónde están las debilidades de la historia y qué se necesita para fortalecerla.

Dimensión 1: Contexto JTBD y Evidencia del Problema

¿Realmente entendemos el trabajo que el usuario necesita hacer?

Esta es la dimensión más fundamental. Una historia que no está anclada en una comprensión profunda del trabajo del usuario es, en el mejor de los casos, un disparo a ciegas. En el peor, es trabajo que nadie quería hacer en primer lugar.

Una buena puntuación en esta dimensión requiere tres tipos de evidencia:

Primero, evidencia cualitativa: Observaciones directas de usuarios diciendo que necesitan hacer este trabajo. No es una encuesta. Es alguien en el campo viendo frustración real. Idealmente, esta evidencia viene del PRD, que a su vez proviene de investigación Mom Test (ver Artículo 1).

Segundo, evidencia cuantitativa con baseline y target: Si el trabajo es importante, debería ser observable en los datos. ¿Cuántos usuarios enfrentan este problema hoy? ¿Cuál es el baseline? ¿A qué número queremos llegar? Una historia sobre “mejorar la experiencia de búsqueda” podría tener un baseline de “40% de búsquedas no producen compra” con un target de “reducir a 25%.”

Tercero, observación del terreno (Gemba): Idealmente, alguien del equipo ha visitado el contexto real donde ocurre el trabajo. Si es un trabajo de logística, alguien estuvo en el almacén. Si es un trabajo de tienda, alguien estuvo en el punto de venta. Esto no siempre es posible, pero cuando es posible, proporciona insights que ningún análisis de datos puede dar.

Una historia con puntuación 9 en esta dimensión te dice exactamente por qué el trabajo importa, con números que lo respaldan, y con observaciones de campo que lo hacen real. Una historia con puntuación 3 dice: “Creemos que los usuarios podrían querer esto” y espera que tengas fe.

Dimensión 2: Especificidad del Usuario

¿Sabemos realmente quién es el usuario de esta historia?

Aquí llegamos a uno de los antipatrones más comunes en la industria: la historia de usuario genérica. “Como usuario, quiero poder buscar productos para encontrar lo que necesito.” Este es un ejemplo de lo que llamamos una “historia fantasma.” Es tan genérica que podría aplicar a casi cualquier plataforma digital.

El framework de Jobs-to-be-Done resuelve esto a través de lo que Wendell llama las cuatro preguntas de usuario específico:

1. ¿Quién exactamente es este usuario? No “usuarios de móvil.” Específicamente: “Mujeres que compraban entre dos y tres veces a la semana en la tienda física, y están experimentando con compra online por primera vez.”

2. ¿En qué contexto está intentando hacer su trabajo? “A las 7 AM en casa mientras se prepara para el trabajo, usando 5-10 minutos para hacer un pedido rápido.”

3. ¿Qué otras alternativas está considerando? “Podría seguir yendo a la tienda físicamente, podría usar Amazon Fresh, podría pedir a través de WhatsApp.”

4. ¿Qué obstáculos enfrenta para hacer su trabajo? “No sabe qué categorías están disponibles online, tarda 20 minutos en buscar lo que necesita.”

Una historia que no puede responder estas cuatro preguntas específicamente tiene una puntuación máxima de 5 en esta dimensión. Este es un hard rule, no una sugerencia. Porque sin especificidad de usuario, no puedes medir si la solución realmente funciona para alguien.Dimensión 3: Cambio de Comportamiento Cuantificable

¿Qué hará diferente el usuario después de usar nuestra solución?

Esta es la dimensión donde muchas historias de usuario tradicionalmente fracasan. Porque la mayoría de las historias definen el “beneficio” de manera abstracta. “Como vendedor de tienda, quiero un dashboard de inventario en tiempo real para tener mejor visibilidad.” ¿Mejor visibilidad? ¿Eso qué significa?

Con la óptica de Jobs-to-be-Done y la filosofía de experimento del Entrenador de Calidad, necesitamos traducir esto a cambio de comportamiento observable:

“Como vendedor de tienda en turno de mañana, quiero recibir alertas automáticas cuando un producto se queda sin stock para que pueda reabastecer en los próximos 15 minutos en lugar de esperar a la revisión manual cada hora. Baseline: 3 horas de espera promedio. Target: 15 minutos.”

Observa lo que cambió: el usuario es específico (vendedor en turno de mañana), el comportamiento es específico (recibir alertas, actuar rápido vs. revisar manualmente), y es cuantificable (15 minutos vs. 3 horas).

Esto es una historia que puedes validar experimentalmente. Despliegas el feature, y después de dos semanas observas: ¿Los vendedores realmente están reabasteciendo en 15 minutos en lugar de 3 horas?

Una historia sin cambio de comportamiento cuantificable tiene una puntuación máxima de 5 en esta dimensión. Este es otro hard rule. Sin cambio de comportamiento cuantificado, es solo un feature backlog, no una historia de usuario.

Dimensión 4: Zona de Control

¿Está el equipo en control de lo que necesita entregar para lograr este cambio de comportamiento?

Este es un tema sutil pero crítico. Imaginemos esta historia: “Como centro de distribución, quiero que los proveedores entreguen con exactitud 99% de las unidades pedidas para que nuestro sistema de picking sea más eficiente.”

Este es un problema real. Pero el equipo de tecnología no controla a los proveedores. Una historia en esta situación tiene que redefinirse para estar dentro de la zona de control del equipo:

“Como especialista de relaciones con proveedores, quiero un dashboard que muestre exactitud de entregas por proveedor en tiempo real para poder identificar patrones y contactar proactivamente a proveedores con bajo desempeño.”

Ahora el equipo controla lo que importa: generar datos confiables, alertar, facilitar la comunicación. El cambio de comportamiento del proveedor es el segundo efecto, no el primero.

Dimensión 5: Restricciones de Tiempo

¿Es la urgencia real o artificial?

He visto esto en cientos de organizaciones: llega el final del sprint, y de repente todo es urgente. Cuando más del 50% de las historias de un sprint tienen deadlines cercanas, algo está mal. No es un problema de ejecución. Es un problema de priorización.

El Entrenador de Calidad observa las restricciones de tiempo en dos dimensiones: Primero, ¿es la urgencia real o percibida? “Perderemos 10k en ventas por día si no lo entregamos” es real. “El stakeholder quiere verlo en la review” es artificial. Segundo, ¿es síntoma de un problema sistémico? Un sprint donde cada historia tiene presión de tiempo es un patrón que necesita atención.

Dimensión 6: Experimento Sobrevivible

¿Qué haremos si nos equivocamos?

Esta es la dimensión más futurista, pero también la más importante para una organización que quiere escalar. Una buena historia de usuario debería incluir desde el principio:

1. La hipótesis explícita: Lo que creemos que va a pasar

2. La métrica de éxito: Cómo sabremos si tuvimos razón

3. El plan de rollback: Cómo revertiremos si nos equivocamos

4. El plan de validación: Cuántos usuarios, durante cuánto tiempo, antes de la entrega completa

Un ejemplo de una historia que puntúa 9 en esta dimensión: “Hipótesis: Mostrar productos frecuentemente comprados juntos en la página de detalles del producto aumentará la cesta promedio de compra en 15% para usuarios que repiten compra semanal. Métrica de éxito: AOV sube a 15% en grupo de test vs. control después de 2 semanas. Plan B: Si AOV no aumenta, revertir automáticamente a control. Validación: 10,000 usuarios en grupo de test durante 14 días.”

Una historia que puntúa 3: “Queremos mostrar productos relacionados en la página de detalles del producto.” ¿Qué hipótesis estamos validando? No se sabe. ¿Cuándo sabemos que fue exitoso? Cuando termine el sprint.

Los Siete Antipatrones de Historia Débil

A través de analizar cientos de historias de usuario en Mercadona Tech, hemos identificado patrones recurrentes de debilidad. No son errores en sí mismos, sino síntomas de historias que no han sido pensadas como experimentos verificables sobre cambio de comportamiento.

Antipatrón 1: El Usuario Fantasma

“Como usuario, quiero poder filtrar por marca para buscar más fácilmente.” El usuario aquí es tan genérico que es invisible. ¿Quién? ¿Un usuario habitual que compra dos veces a la semana? ¿Un nuevo usuario que no sabe cuáles son las marcas disponibles? La solución es incluir el proto-personaje completo, respondiendo las cuatro preguntas de especificidad de usuario de Wendell.

Antipatrón 2: El Beneficio Fantasma

“Para poder encontrar lo que necesito.” ¿Qué significa “encontrar”? ¿Menos clics? ¿Menos tiempo? ¿Resultados más relevantes? Sin una definición operacional del beneficio, no puedes validar experimentalmente si la solución funcionó.

Antipatrón 3: La Historia Falsa

“Como equipo de ingeniería, quiero refactorizar la base de datos para poder tener mejor performance.” ¿Quién es el usuario aquí? No es el equipo de ingeniería. Es el usuario final que espera una aplicación más rápida. Una historia verdadera sería: “Como usuario que hace búsquedas frecuentes de ofertas en categoría Frescos, quiero que los resultados se carguen en menos de 2 segundos (vs. los actuales 5 segundos) para poder navegar sin frustración.”

Antipatrón 4: La Solución como Necesidad

“Quiero un botón de favoritos en la página de producto.” Estamos describiendo la solución técnica, no el trabajo del usuario. ¿Por qué el usuario necesita favoritos? ¿Es para comparar productos? ¿Es para volver a productos vistos anteriormente? Cada respuesta es una historia diferente, con métricas de éxito diferentes.

Antipatrón 5: Entrega Fuera de Control

“Como gestor de centros, quiero que el sistema de proveedores externo envíe datos de inventario cada hora.” El equipo no controla el sistema externo. La historia está configurada para fracasar porque está fuera de la zona de control del equipo.

Antipatrón 6: Todo es Urgente

Si tu sprint tiene 80% de las historias con deadlines apretadas, tu priorización está rota. No es un problema de ejecución. Una historia bajo presión de tiempo real es diferente de una sprint donde todo es urgente por defecto.

Antipatrón 7: División Técnica Horizontal

“Como desarrollador frontend, quiero crear la interfaz de filtros. Como desarrollador backend, quiero implementar los endpoints de filtros.” Lo que debería ser una única historia de usuario se divide en tareas técnicas de capas. Puedes tener dos “historias” completadas y el usuario seguir sin tener la funcionalidad de punta a punta.

El Mecanismo: Evaluación Rigurosa sin Rigidez

El Entrenador de Calidad utiliza las seis dimensiones para evaluar cada historia en una escala de 0-10. Pero el mecanismo es importante: no es un juicio de “bueno” o “malo.” Es un diagnóstico.

Una historia que puntúa 32/60 (53%) no es rechazada. Se dice: “Aquí está el diagnóstico. La historia es débil en especificidad de usuario, débil en cambio de comportamiento cuantificado, fuerte en contexto JTBD. Esto significa que entiendes el problema real, pero aún necesitas clarificar exactamente quién es el usuario y qué comportamiento esperas cambiar.”

Entonces el Entrenador proporciona una reescritura sugerida de la historia, reformulada en lenguaje JTBD, que el Product Manager puede adoptar, adaptar, o descartar.

Aquí es donde la filosofía es crucial: El Entrenador respeta la autonomía de decisión del PM, pero no respeta la vaguedad. Si decides ignorar el feedback del Entrenador, puedes hacerlo. Pero hazlo con los ojos abiertos, sabiendo exactamente dónde está el riesgo.

Ejemplo Completo: Reescritura de Una Historia Débil

Vamos a tomar una historia de usuario tal como aparecería en un backlog real, y mostrar exactamente cómo el Entrenador de Calidad la diagnostica y propone una reescritura.

Historia Original:

“Como usuario de la aplicación de compra, quiero poder ver recomendaciones personalizadas de productos en mi inicio de sesión para poder descubrir productos nuevos y aumentar mis compras.”

Diagnóstico del Entrenador:

Dimensión/Puntuación/Observación

D1: Contexto JTBD 4/10 Hay un problema implícito (”descubrir productos nuevos”) pero sin evidencia cuantificada.

D2: Especificidad de Usuario 2/10 ”Usuario de la aplicación de compra” es extremadamente genérico. Hard rule: máximo 5 sin especificidad.

D3: Cambio de Comportamiento 3/10 ”Descubrir productos nuevos” y “aumentar mis compras” son beneficios abstractos. Hard rule: sin cuantificación clara, máximo 5.

D4: Zona de Control 7/10 El equipo controla la recomendación y el display. Mayormente controlable.

D5: Restricciones de Tiempo 8/10 Sin deadline urgente aparente. Puede desarrollarse con rigor adecuado.

D6: Experimento Sobrevivible 2/10 No hay hipótesis explícita, no hay plan de validación, no hay métrica de éxito clara, no hay plan B.

Puntuación Total: 26/60 (43%)

Feedback del Entrenador:

“Esta historia toca un tema legítimo (personalization aumenta valor), pero está muy poco especificada. No sabemos quién es el usuario exacto, no sabemos en qué contexto está usando recomendaciones, y no sabemos cómo mediremos el éxito. Recomendación: Reformular incluyendo proto-personaje específico, contexto, cambio de comportamiento cuantificado, y métrica de validación.”

Historia Reescrita (Sugerencia del Entrenador):

“Como cliente en categoría de Frescos que históricamente compra el mismo tipo de productos cada semana (plátanos, leche, queso), quiero recibir recomendaciones de nuevos productos en las mismas categorías al iniciar sesión para poder descubrir ofertas o variantes que se alineen con mis preferencias sin incrementar el tiempo de búsqueda. Contexto: Cliente que dedica 8-10 minutos a completar su pedido. Hipótesis: Mostrar 3-5 recomendaciones de ‘también te pueden gustar’ en la pantalla de inicio aumentará el AOV (Average Order Value) en al menos 8% en este segmento, sin aumentar el tiempo de compra (permanecerá menos de 12 minutos). Métrica: Comparar AOV grupo test vs. grupo control durante 2 semanas. Plan de validación: 5,000 usuarios en grupo test. Plan B: Si AOV no aumenta en 5 días, revertir recomendaciones a grupo de control.”

Puntuación de la Historia Reescrita:

DimensiónPuntuaciónObservación D1: Contexto JTBD7/10Hay hipótesis clara, hay segmento de usuario identificado. Falta evidencia de campo, pero es sólida. D2: Especificidad de Usuario9/10Específico: cliente de Frescos que repite compra semanal. Proto-personaje claro. D3: Cambio de Comportamiento8/10Cuantificado: AOV aumenta 8%. Contexto: sin aumentar tiempo de compra. Claramente medible. D4: Zona de Control8/10Equipo controla recomendaciones y display. AOV es métrica observable del sistema. D5: Restricciones de Tiempo9/102 semanas de test. Plan de decisión claro. No artificial. D6: Experimento Sobrevivible9/10Hipótesis explícita, métrica de éxito, plan de validación, plan B. Es un experimento real.

Puntuación Total: 50/60 (83%)

Casos de Uso: Evaluar Historias en Cualquier Momento del Pipeline

Lo que hace al Entrenador de Calidad especialmente valioso es que funciona en múltiples puntos del pipeline, no solo para nuevas historias.

Caso 1: Evaluación Temprana (PRD → Story)

Durante la fase de investigación (Artículos 1-2), el Entrenador puede evaluar los PRDs para asegurar que contienen la evidencia necesaria. Un PRD que no tiene suficiente contexto JTBD para puntuar mayor a 6 en Dimensión 1 significa que necesitas más investigación antes de escribir historias.

Caso 2: Evaluación en Escritura (Story Builder)

Mientras escribes historias de usuario (Artículo 4), el Entrenador proporciona feedback en tiempo real. “Esta versión puntúa 4 en especificidad de usuario. Intenta nombrar el segmento exacto.”

Caso 3: Evaluación en Sprint (Historias Existentes)

El Entrenador puede evaluarse directamente desde Jira, incluso historias que fueron escritas sin el framework. Un Product Manager puede correr el Entrenador contra su backlog actual, ver dónde están los problemas, y enfocarse en las historias débiles para mejoramiento.

Caso 4: Benchmarking Entre Equipos

Cuando corres el Entrenador contra historias de 12 equipos diferentes, emergen patrones. El equipo de Tienda tiende a ser fuerte en especificidad de usuario pero débil en cambio de comportamiento cuantificado. El equipo de Primera Milla tiende a ser fuerte en contexto JTBD pero débil en experimento sobrevivible.

Estos patrones son datos de coaching. Permiten que los líderes de producto identifiquen dónde entrenar al equipo, qué hacer diferente, cómo transferir mejores prácticas entre equipos.

La Paradoja de la Consistencia

Aquí está la paradoja deliciosa del Entrenador de Calidad: Proporciona consistencia sin requerir rigidez.

En organizaciones tradicionales, intentas imponer consistencia forzando un estándar. “Todas las historias DEBEN tener este formato.” El resultado es que las historias son uniformes pero vacías. Todos cumplen con el checklist. Pero nadie realmente está pensando.

El Entrenador hace lo opuesto. Proporciona un sistema de diagnóstico que es lo suficientemente flexible para respetar contextos diferentes, pero lo suficientemente riguroso para garantizar que ciertas debilidades sean transparentes.

Una historia en Checkout puede priorizar diferente que una en Tienda. Pero ambas responden las mismas preguntas fundamentales: ¿Quién exactamente es el usuario? ¿Qué comportamiento espera cambiar? ¿Cómo validaremos que nuestra hipótesis fue correcta?

Porque si estos tres puntos no están claros, entonces no es realmente una historia de usuario. Es una tarea técnica disfrazada de historia.

La Importancia de “Especificidad de Usuario” y “Cambio de Comportamiento” como Hard Rules

Es importante enfatizar dos de las seis dimensiones porque emergen como los mayores predictores de fracaso en historias de usuario tradicionales.

Dimensión 2 (Especificidad de Usuario): El cambio de comportamiento observable, medible, requiere un usuario específico. Porque diferentes usuarios tienen diferentes contextos, diferentes limitaciones, diferentes motivaciones. Una historia que dice “usuario” en lugar de “usuario que compra en Frescos dos veces a la semana” es una historia que no puedes validar experimentalmente. Por eso tiene un hard rule: máximo 5 sin especificidad.

Dimensión 3 (Cambio de Comportamiento Cuantificado): El cambio de comportamiento es lo que distingue entre un feature backlog y una hipótesis verificable. “Mejorar la experiencia” es un feature backlog. “Reducir el tiempo de búsqueda de 180 segundos a 60 segundos” es una hipótesis verificable. Por eso tiene un hard rule: máximo 5 sin cuantificación.

Estos hard rules no son arbitrarios. Son las condiciones mínimas para que una historia sea experimentable.

Antipatrones en Mercadona Tech: Aprendizajes Específicos

En los meses que el Entrenador de Calidad ha estado operacional, hemos visto patrones específicos en cómo diferentes equipos de Mercadona Tech necesitan mejorar.

Tienda (Shop): Tendencia fuerte a cometer antipatrón #1 (Usuario Fantasma) porque el usuario es “vendedor” o “cliente.” Necesidad de entrenar en diferenciación de proto-personajes por turno, por antigüedad, por tipo de tienda.

Primera Milla: Tendencia a cometer antipatrón #3 (Historia Falsa) porque a menudo las historias están escritas desde la perspectiva del equipo técnico en lugar del usuario final (repartidor, cliente, operador de logística).

Ser Humano: Mezcla de antipatrón #2 (Beneficio Fantasma) con antipatrón #6 (Todo es Urgente). Historias frecuentemente bajo presión de tiempo, lo que significa menos tiempo para especificar. Necesidad de proteger tiempo de planning.

Colmena: Tendencia a antipatrón #4 (Solución como Necesidad) porque la mayoría del trabajo es automatización/reposición. Requiere pasos explícitos para conectar la solución técnica con el cambio de comportamiento del usuario humano (reponedor, operador, gestor).

Estos patrones no son críticos. Son observaciones que permiten coaching específico.

Conclusiones: De la Intuición a la Disciplina

A lo largo de cinco artículos de esta serie, hemos construido un framework completo para transformar investigación de usuarios en historias de usuario de alta calidad que actúen como experimentos sobre cambio de comportamiento.

Primero, aprendimos a investigar PRDs con rigor científico, usando Mom Test para validar hipótesis directamente en el campo (Artículo 1).

Segundo, aprendimos a traducir esa investigación en Jobs-to-be-Done, el lens conceptual que nos permite ver el trabajo verdadero que el usuario está intentando hacer (Artículo 2).

Tercero, aprendimos a hacer puente entre Jobs-to-be-Done y User Stories, manteniendo la especificidad y rigor a través de la transición (Artículo 3).

Cuarto, aprendimos a escribir historias de usuario desde cero cuando no tenemos un PRD, usando un proceso conversacional que extrae claridad (Artículo 4).

Ahora, aprendemos a evaluar historias consistentemente usando un sistema que es simultáneamente riguroso y flexible.

Lo que emerge de estos cinco pasos es una transformación organizacional profunda. Ya no estás entregando features basado en intuición de PM. Estás ejecutando hipótesis sobre cambio de comportamiento, validadas con evidencia de investigación, escritas con especificidad, evaluadas contra estándares claros.

El Entrenador de Calidad no es un policía que rechaza historias débiles. Es un coach que dice: “Aquí está exactamente dónde tu historia es débil. Aquí está lo que necesitas hacer para reforzarla. Tienes la autonomía de decidir si quieres hacer el esfuerzo.”

Algunos equipos lo harán. Otros usarán el diagnóstico para tomar decisiones conscientes sobre riesgo. Ambas opciones son válidas. Lo que no es válido es pretender que una historia vaga es una historia de usuario simplemente porque está en el backlog.

En Mercadona Tech, con 12 verticales en paralelo, la diferencia entre intuición y disciplina en la calidad de historias de usuario es la diferencia entre ejecutar y ejecutar con confianza.

El Entrenador de Calidad existe para hacer esa diferencia tangible y medible.

Próximo Artículo (6 de 7): Síntesis e Integración — Cómo todas las piezas del Marco de Historias de Usuario de IA Mercadona trabajan juntas en un workflow real, y cómo ha cambiado la forma en que Mercadona Tech ejecuta producto.

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

Existe un momento crítico en el viaje de cualquier producto digital: el instante justo después de haber finalizado un Documento de Requerimientos de Producto (PRD). El equipo siente la satisfacción de haber articulado claramente qué se va a construir, por qué, y cuál será el impacto. Los números están en la hoja de cálculo. Las métricas de éxito definidas. Los casos de uso mapeados.

Pero hay un problema silencioso: el PRD describe el problema desde la perspectiva del negocio, pero las mejores historias de usuario se construyen desde la perspectiva del usuario. Entre esos dos universos existe un abismo lleno de suposiciones no cuestionadas, contextos incompletos, y comportamientos que nadie ha observado realmente.

En el artículo anterior exploramos cómo Quality Guard verifica que el PRD contenga información suficiente y separada (problema vs. solución) para que el producto pueda diseñar bien. Pero ahora nos enfrentamos a la pregunta siguiente: ¿Es ese problema realmente lo que el usuario experimenta?

Esta es la pieza que introduce Research Mom Test, el tercer módulo del AI Mercadona User Story Framework.

El Mom Test: La Filosofía de la Investigación Honesta

El nombre “Mom Test” viene de un concepto acreditado a Rob Fitzpatrick en su libro del mismo nombre. La idea es devastadoramente simple: si le preguntas a tu madre si tu idea de negocio es buena, te dirá que sí, porque te quiere. No porque la idea sea buena.

El Mom Test propone que las preguntas de investigación deben diseñarse para que incluso tu madre no pueda darte una respuesta falsa. Esto se logra evitando tres tipos de preguntas tóxicas:

Preguntas tóxicas que Mom Test prohíbe:

• Preguntas de opinión: “¿Te gustaría...?”, “¿Qué opinas de...?”, “¿Sería útil si...?”

• Preguntas hipotéticas: “¿Usarías X si existiera?”, “¿Cuánto pagarías por...?”, “¿Cambiarías tu proceso si...?”

• Preguntas dirigidas: “¿No crees que sería mejor si...?”, “¿El problema principal es X, verdad?”

En su lugar, Mom Test exige preguntas sobre comportamiento real, pasado, observable:

• “Cuéntame la última vez que hiciste X. ¿Qué pasó?”

• “¿Qué hiciste cuando ocurrió Y?”

• “¿Cómo resuelves Z actualmente?”

• “¿Cuánto tiempo te lleva?”

• “¿Qué intentaste antes de hacer lo que haces ahora?”

La clave es que estas preguntas revelan comportamiento real, no intención declarada. Y en Mercadona, donde cada cambio de proceso en un almacén puede impactar a 1,800 empleados, la diferencia entre intención declarada y comportamiento real puede costar millones.

Cómo Research Mom Test Transforma PRDs en Investigación de Campo

En el AI Mercadona User Story Framework, Research Mom Test recibe un PRD que ha pasado Quality Guard. El PRD contiene: métricas baseline y target, proceso AS-IS y TO-BE, actores y handoffs, y un problema limpio sin contaminación de solución.

Research Mom Test analiza este PRD y genera automáticamente:

1. Gap Detection (Detección de Huecos): Identifica qué información falta en el PRD para poder construir buenas historias de usuario. Busca: suposiciones no validadas, comportamientos asumidos pero no observados, actores mencionados pero no entrevistados, métricas que dependen de datos no recopilados, y procesos descritos teóricamente pero no verificados en campo.

2. Guía de Entrevistas Mom Test: Para cada gap detectado, genera preguntas de entrevista que cumplen estrictamente Mom Test. No preguntas de opinión. No hipotéticas. Solo preguntas sobre comportamiento real, pasado, observable.

3. Jobs-to-be-Done (JTBD) Reforzado: Después de las entrevistas, Research Mom Test procesa las notas y genera JTBDs enriquecidos con evidencia real: citas directas, patrones observados, frecuencia, contexto emocional.

Gap Detection: Encontrar lo que No Sabemos que No Sabemos

La parte más valiosa de Research Mom Test es su capacidad para detectar huecos en el conocimiento. Hay tres categorías:

Gaps de Proceso Funcional (PF): Información faltante sobre cómo funciona el proceso actual. Ejemplo: el PRD dice que “recepcionistas procesan pallets” pero no dice cuántos pallets por turno, cuánto dura cada procesamiento, o qué pasa cuando hay 3 camiones simultáneos.

Gaps de Inventario de Secciones (PI): Información faltante sobre las secciones o áreas afectadas. Ejemplo: el PRD menciona “almacén” pero no especifica si aplica a refrigerados, secos, congelados, o todos. Cada sección puede tener flujos diferentes.

Gaps de Contexto de Usuario: Falta de comprensión sobre cómo los usuarios realmente interactúan con el proceso. Qué workarounds usan, qué frustraciones tienen, qué han intentado antes.

La Guía de Entrevistas: Preguntas que Revelan Verdad

Para cada gap detectado, Research Mom Test genera preguntas de entrevista específicas. Un ejemplo real del almacén de Lleida:

Gap detectado: “El PRD asume que las discrepancias en recepción son un problema grave, pero no sabemos con qué frecuencia ocurren realmente, ni cómo las resuelven los recepcionistas.”

Preguntas Mom Test generadas:

• “Cuéntame sobre la última vez que recibiste un pallet con algo diferente a lo esperado. ¿Qué pasó exactamente?”

• “¿Cómo supiste que había una discrepancia? ¿Qué hiciste después?”

• “¿Cuántas veces esta semana te pasó algo así? ¿Es típico?”

• “Cuando encontraste la discrepancia, ¿a quién le avisaste? ¿Cuánto tardó en resolverse?”

• “¿Alguna vez inventaste una forma de resolver esto más rápido por tu cuenta? Cuéntame.”

Estas preguntas no preguntan “te gustaría un sistema mejor”. Preguntan “qué haces hoy”. La diferencia es fundamental.

Research Mom Test también genera preguntas para cada rol diferente. Para el recepcionista, para el analista de almacén, para el supervisor, para el operador logístico. Cada uno ve el proceso desde un ángulo diferente.

JTBD Reforzado: Jobs-to-be-Done con Evidencia Real

Después de las entrevistas, llega el momento más transformador: convertir las respuestas en Jobs-to-be-Done enriquecidos con evidencia.

Un JTBD tradicional dice: “Cuando [situación], quiero [motivación], para poder [resultado esperado].”

Un JTBD Reforzado en nuestro framework añade capas críticas:

• Funcional: ¿Qué tarea específica necesita completar?

• Emocional personal: ¿Cómo quiere sentirse durante y después?

• Emocional social: ¿Cómo quiere ser percibido por colegas/supervisores?

• Cambio de comportamiento: ¿Qué debería empezar (START), dejar de hacer (STOP), o hacer diferente (DIFFERENT)?

• Evidencia de entrevista: Citas directas y observaciones que soportan cada JTBD

Ejemplo real del almacén de Lleida:

JTBD Funcional: “Cuando recibo un pallet con discrepancias, necesito poder registrar la diferencia y obtener una decisión inmediata sobre qué hacer con los items sobrantes o faltantes, para no tener que parar mi flujo de trabajo esperando al analista.”

JTBD Emocional Personal: “Quiero sentir que tengo control sobre mi zona de trabajo y que puedo resolver problemas sin depender de otra persona que a veces no está disponible.”

JTBD Emocional Social: “Quiero que mi supervisor vea que manejo discrepancias de forma profesional y rápida, sin generar colas en el muelle.”

Evidencia: 3 de 5 recepcionistas entrevistados mencionaron esperar entre 15-45 min al analista. Uno dijo: “A veces resuelvo yo solo porque ya sé lo que hay que hacer, pero después me reganan por no seguir el proceso.”

Dos Modos de Operación: Discover y Validate

Research Mom Test opera en dos modos según el estado del PRD:

Modo Discover: Cuando el PRD tiene gaps significativos. La investigación es exploratoria. Se busca entender el territorio completo. Preguntas abiertas, observación en campo, seguimiento de workarounds. Resultado: mapa completo de JTBDs con evidencia.

Modo Validate: Cuando el PRD está bastante completo pero necesita confirmación. La investigación es confirmatoria. Se busca validar que lo que asumimos es correcto. Preguntas más específicas, verificación de hipótesis. Resultado: JTBDs confirmados o corregidos.

En ambos modos, Research Mom Test SIEMPRE se ejecuta. No hay camino del PRD a las historias de usuario que no pase por investigación de campo. Es un principio no negociable del framework.

El Wendel Checklist: Validando Cambio de Comportamiento

Una innovación importante de nuestro framework es integrar el Wendel Checklist (inspirado en los principios de diseño conductual de Stephen Wendel) en la validación de JTBDs.

La idea: cada JTBD implica un cambio de comportamiento. Si queremos que el recepcionista registre discrepancias en tiempo real en lugar de en papel, estamos pidiendo un cambio de hábito. Y los cambios de hábito fallan si no se diseñan bien.

El Wendel Checklist verifica cinco condiciones para cada JTBD:

1. CUE (Señal): ¿Hay un momento claro que dispara la acción? Si el recepcionista no sabe CUÁNDO usar el nuevo sistema, no lo usará.

2. REACTION (Reacción): ¿La reacción instintiva es positiva? Si el sistema parece complicado, el recepcionista volverá al papel.

3. EVALUATION (Evaluación): ¿El usuario ve el beneficio inmediato? Si el beneficio es “mejor para la empresa” pero no “mejor para mí”, la adopción será baja.

4. ABILITY (Capacidad): ¿El usuario PUEDE hacerlo? Si necesita 3 manos (una para el pallet, una para el papel, una para el dispositivo), no es factible.

5. TIMING (Momento): ¿Es el momento adecuado? Si el recepcionista tiene 5 camiones esperando, no va a pararse a aprender un sistema nuevo.

Cada JTBD que sale de Research Mom Test se evalúa contra estas cinco condiciones. Si alguna falla, el JTBD necesita ajuste antes de convertirse en historia de usuario.

El Poder del Comportamiento START/STOP/DIFFERENT

Research Mom Test introduce una clasificación de cambio de comportamiento para cada JTBD:

• START: Algo que el usuario NO hace hoy y debería empezar. Ejemplo: registrar discrepancias digitalmente.

• STOP: Algo que el usuario hace hoy y debería dejar. Ejemplo: anotar en papel, esperar al analista.

• DIFFERENT: Algo que el usuario hace hoy pero de forma diferente. Ejemplo: comunicar discrepancias por radio en vez de caminando.

Los cambios STOP son los más difíciles. Dejar de hacer algo que funciona (aunque sea ineficiente) requiere que la alternativa sea significativamente mejor. Los cambios START son los más riesgosos. Añadir un nuevo paso a un proceso ya cargado genera resistencia. Los cambios DIFFERENT son los más fáciles de adoptar. El hábito ya existe; solo cambia la herramienta.

Conclusiones: La Investigación como Puente entre Negocio y Usuario

Research Mom Test es el puente que conecta la claridad del PRD con la realidad del campo. Sin él, las historias de usuario se construyen sobre suposiciones. Con él, se construyen sobre evidencia.

Aprendizajes clave de este artículo:

El Mom Test es no negociable: No preguntar opiniones. No preguntar hipótesis. Solo comportamiento real, pasado, observable.

Gap Detection antes de entrevistar: Saber qué no sabemos antes de ir al campo es la mitad del trabajo.

JTBD Reforzado: Funcional + Emocional Personal + Emocional Social + Cambio de Comportamiento + Evidencia. No solo “qué quiere hacer” sino “cómo quiere sentirse” y “cómo quiere ser visto”.

Wendel Checklist: Cada JTBD implica un cambio de comportamiento. Si no pasa las 5 condiciones (Cue, Reaction, Evaluation, Ability, Timing), la historia de usuario que salga de ahí fracasará en adopción.

START/STOP/DIFFERENT: Clasificar el cambio de comportamiento para saber dónde está el riesgo de adopción.

En Mercadona, donde cada cambio impacta a miles de personas en cientos de ubicaciones, esta rigurosidad no es un lujo. Es una necesidad. La diferencia entre un producto exitoso y un producto abandonado a menudo no está en la calidad del código, sino en la calidad de la investigación que lo precedió.

En el próximo artículo, exploraremos cómo JTBD to Stories toma estos JTBDs reforzados y los transforma en historias de usuario de alta calidad, listas para el equipo de desarrollo.

Próximo artículo: Artículo 4 — “JTBD to Stories: La Transformación de JTBDs en User Stories de Calidad”

Serie “AI Mercadona User Story Framework” — Febrero 2026

En el artículo anterior de esta serie sobre el “AI Mercadona User Story Framework”, establecimos la visión general: un camino desde el descubrimiento profundo del problema hasta la entrega de historias de usuario que realmente resuelven el negocio. Hablamos de por qué el descubrimiento importa, de cómo la mayoría de los fracasos de producto no vienen de implementar mal la solución, sino de resolver el problema equivocado.

Hoy nos enfrentamos a una pregunta incómoda: ¿cómo sabemos cuándo un problema está realmente bien definido?

Introducción: Cuando el Problema No Es Problema

En el artículo anterior de esta serie sobre el “AI Mercadona User Story Framework”, establecimos la visión general: un camino desde el descubrimiento profundo del problema hasta la entrega de historias de usuario que realmente resuelven el negocio. Hablamos de por qué el descubrimiento importa, de cómo la mayoría de los fracasos de producto no vienen de implementar mal la solución, sino de resolver el problema equivocado.

Hoy nos enfrentamos a una pregunta incómoda: ¿cómo sabemos cuándo un problema está realmente bien definido?

La respuesta que hemos descubierto en Mercadona es que la mayoría de los equipos no lo saben. Y más preocupante aún: la mayoría de los PRDs (Documentos de Requisitos de Producto) que llegan a manos de los ingenieros no contienen suficiente información para que el producto pueda tomar decisiones inteligentes.

Esto no es culpa de nadie. Es un síntoma de una confusión estructural que existe en prácticamente todas las organizaciones tecnológicas: la falta de claridad sobre dónde termina el trabajo de entender el problema (responsabilidad del negocio) y dónde comienza el trabajo de diseñar la solución (responsabilidad del producto).

Cuando esos límites se difuminan, pasan cosas. Se mezclan responsabilidades. Se empieza a construir sin claridad. Y tres sprints después, descubrimos que nunca entendimos realmente qué estábamos tratando de resolver.

Para evitar eso, necesitamos un guardián en la puerta. Alguien (o algo) que diga: “Espera. Antes de que el producto comience a diseñar, verifiquemos que el problema esté realmente bien definido.”

Ese guardián se llama Quality Guard.

El Problema: PRDs que No Son Realmente Especificaciones

Imaginemos un escenario típico en cualquier equipo de tecnología de Mercadona:

Un gerente de tienda en Barcelona entra en una reunión con el equipo de producto de In-Store. El gerente dice: “La gente tarda mucho en hacer recuento de inventario. Necesitamos una app que lo haga más rápido.”

El PM asiente. Suena como un problema legítimo. El PM escribe un PRD:

“El equipo de In-Store debe desarrollar una herramienta de recuento rápido que permita a los empleados completar inventarios en la mitad del tiempo actual.”

¿Ves el problema? No hay métricas baseline. ¿Cuánto tiempo tarda hoy? ¿Qué significa “la mitad”? No hay observación de campo. ¿Por qué tarda tanto? ¿Es porque el proceso está mal diseñado? ¿Porque hay demasiados SKUs? ¿Porque la app actual es lenta? No hay claridad sobre restricciones. ¿Pueden trabajar en paralelo? ¿Necesitan estar online o offline? ¿Qué datos son críticos vs. secundarios?

El PM pasa este PRD al equipo de producto. El equipo de producto comienza a diseñar una interfaz moderna, optimizada, con sinc automático y dashboards en tiempo real. Bonita. Compleja.

Diez semanas después, el equipo de In-Store comienza a usar la herramienta. Descubren que el verdadero problema nunca fue la velocidad de la UI, sino que los recuentos se hacen con dos personas que se comunican verbalmente, una llamando los SKUs y otra marcándolos. La app que se diseñó es para una sola persona. El problema real era: ¿cómo hacemos que dos personas puedan trabajar juntas sin perder sincronía?

Tres semanas de ajustes. Conversación tensa entre producto e In-Store. La pregunta incómoda: “¿Por qué no preguntaron esto antes de empezar?”

La respuesta es sencilla: porque el PRD nunca pidió que preguntaran. El PRD era un deseo vagamente articulado, no una especificación de un problema.

La Teoría: Separación Estricta entre QUÉ y CÓMO

Para entender por qué Quality Guard existe, necesitamos primero entender una verdad fundamental sobre cómo se construye bien en organizaciones maduras:

La distinción entre QUÉ y CÓMO es sagrada.

El QUÉ es: ¿Cuál es el problema que existe en la realidad?

El CÓMO es: ¿Cuál es la mejor solución tecnológica para ese problema?

Estos dos espacios tienen dueños diferentes:

• El negocio es responsable de especificar el QUÉ. El negocio vive en las tiendas, en los almacenes, en los repartos. El negocio conoce los procesos, las restricciones, los usuarios finales, las métricas que importan.

• El producto es responsable de diseñar el CÓMO. El producto entiende de experiencia, arquitectura, escalabilidad, factibilidad técnica.

Cuando estos espacios están bien separados, pasan cosas buenas:

1. El negocio tiene claridad. Se enfoca en lo que importa: definir el problema, los datos, los actores.

2. El producto tiene libertad. Puede explorar soluciones creativas sin estar atado a prescripciones del negocio.

3. La comunicación es clara. Sin límites claros, todo se vuelve adivinanzas.

Pero en la mayoría de las organizaciones, estos espacios se contaminan mutuamente. El negocio pide soluciones específicas (CÓMO). El producto asume lo que quiere el negocio (QUÉ) sin preguntar.

Las Tres Dimensiones de Quality Guard

Quality Guard evalúa el PRD en tres dimensiones independientes. Cada dimensión se califica de 0 a 10. El puntaje final es el mínimo de las tres.

Dimensión 1: Completitud del Problema

Pregunta fundamental: ¿Existe suficiente información cuantitativa y cualitativa para que el producto entienda qué está siendo resuelto?

Esta dimensión verifica que el PRD contenga tres tipos de evidencia:

1.1. Métricas cuantitativas con baseline y target

Un problema sin números no es especificación, es opinión.Veamos ejemplos malos:

• ❌ “Los empleados tardan mucho tiempo en hacer recuento de inventario”

• ❌ “Queremos mejorar la experiencia de checkout”

• ❌ “La gente está frustrada con la app de rutas”

Todas son intuiciones. Ninguna es datos.

Ejemplos buenos:

• ✅ “El recuento de inventario toma 3.5 horas hoy (medido en 5 tiendas piloto, Feb 2026). Meta: 2.0 horas. Impacto: 1.5 horas × 50 tiendas × 365 días = 27,375 horas/año.”

• ✅ “En checkout, el 23% de los carritos que inician no se completan. Baseline: 23% (Oct-Dec 2025). Meta: <15%. Impacto: +180 transacciones/mes en tienda media.”

• ✅ “La app de rutas se usa 8 minutos/sesión. Competidor usa 5 minutos. Meta: <4 minutos.”

Los ejemplos buenos tienen: un estado actual medible (baseline), un estado deseado medible (target), una unidad de medida clara, una muestra o período especificado, y un impacto cuantificado.

1.2. Observaciones de campo con citas directas

Los datos sin contexto son números huérfanos. Quality Guard busca que el PRD contenga visitas a tiendas o almacenes (Gemba walk), notas verbatim, observaciones de cómo hacen las cosas hoy, y fricción observada.

Ejemplo malo: “El sistema de picking genera mucho rechazo entre los colaboradores de almacén.”

Ejemplo bueno: “Durante la Gemba walk del 10 de febrero en el almacén de Lleida, observamos a 4 preparadores. Uno comentó: ‘Esto es un show. Tengo que estar constantemente revisando si el item ya fue preparado’. Otro: ‘Los olvidos pasan porque la batería se me muere a mitad de la jornada’. Observamos que 23 de 80 preparaciones tuvieron pick errors en 2 horas. 18 de esos 23 errores fueron en las últimas 2 horas de la jornada, cuando la batería se agota.”

1.3. Impacto claro en personas, procesos, herramientas

El problema debe conectarse a: ¿Quién sufre? ¿Cómo sufre? ¿Qué herramientas están implicadas?

Scoring Dimensión 1: 9-10: Métricas baseline y target claras, observaciones de campo recientes, impacto articulado. 7-8: Métricas parciales, observaciones presentes. 5-6: Datos parciales, impacto vago. 3-4: Algún número, sin observaciones. 0-2: Sin métricas ni claridad.

Dimensión 2: Calidad del Proceso

Pregunta fundamental: ¿Está documentado cómo funciona hoy el proceso? ¿Y cómo debería funcionar idealmente?

Quality Guard busca dos documentos:

2.1. Mapa AS-IS — Cómo funciona hoy, paso a paso, con todos los actores y herramientas.

2.2. Mapa TO-BE — Cómo debería funcionar idealmente, abstrayendo de la tecnología. No dice “usa app mobile” sino “cómo debería ser la experiencia de proceso”.

2.3. Actores y Handoffs — Quiénes son, qué hacen, dónde están, cuándo interactúan.

Scoring Dimensión 2: 9-10: AS-IS detallado, TO-BE idealizado, actores claros. 7-8: AS-IS presente, TO-BE parcial. 5-6: Superficial. 3-4: Vago. 0-2: Sin descripción de proceso.

Dimensión 3: Separación QUÉ/CÓMO (Contaminación de Solución)

Pregunta fundamental: ¿Hay pistas de que alguien en el negocio está prescribiendo la solución en lugar de describir el problema?

Esta es la dimensión más peligrosa. Cuando el negocio dicta soluciones en el PRD, el producto pierde toda libertad de diseño.

Quality Guard detecta antipatrones de contaminación:

Antipattern 1: Jobs-to-be-Done en el PRD — Los JTBD son responsabilidad del producto, no del negocio. Malo: “Los preparadores necesitan visualizar la ruta de picking optimizada en tiempo real para minimizar desplazamiento.” Bueno: “El preparador tarda 45 min en completar 80 items en almacén de 8000 m². Anda ~2.3 km por ruta (datos GPS). Benchmark: almacén comparable anda ~1.2 km. Diferencia: 1.1 km × 10 min/km = 11 min/ruta × 8 rutas/día = 88 min/día/persona. Con 15 preparadores = 22 horas/día perdidas.”

Antipattern 2: Prescripciones técnicas — “Usa API REST”, “usa blockchain”, “usa inteligencia artificial”. Malo: “Se requiere integración vía REST API con SAP para sincronizar inventario en tiempo real.” Bueno: “Hoy hay retraso de 4 horas entre preparación de item y reflejo en sistema de inventario. Causa sobreventa: 8-12 devoluciones/día. Se necesita actualización dentro de 15 min del evento.”

Antipattern 3: Prescripciones de UI/UX — “Necesita un botón para...”, “La app debe tener...”. Malo: “Se requiere pantalla táctil de 10 pulgadas en cada posición de picking.” Bueno: “Hoy los preparadores cometen error en 2.3% de picks (confunden artículos similares). Con foto de referencia, error baja de 2.3% a 0.6%. El preparador necesita acceso a información visual clara.”

Antipattern 4: Lenguaje de solución — “La solución debería...”, “necesitamos software que...”. Sin contaminar: “Cuando una devolución ocurre en campo, el registro toma 6 horas. En 40% de casos, driver re-entrega a almacén equivocado. Necesitamos información en punto de devolución inmediatamente.”

Antipattern 5: Hipótesis de solución disfrazada de requerimiento — “Reducir número de clics en 50%” es hipótesis, no problema. Problema puro: “40% de usuarios abandonan carrito en paso de pago. 65% abandona después de ver opciones. Flujo actual: 7 pantallas, 45 campos. Benchmark competidor: 3 pantallas, 20 campos.”

Scoring Dimensión 3: Quality Guard comienza asumiendo 10 puntos. Por cada antipattern: crítico (-3), alto (-2), medio (-1).

La Prueba de Herramienta Alternativa

Quality Guard usa una técnica elegante para detectar contaminación de solución: el Alternative Tool Test.

La idea: si reemplazas la herramienta digital por papel/manual y la descripción SIGUE SIENDO VÁLIDA, entonces es descripción de problema legítima. Si la descripción se disuelve, era prescripción de solución.

Ejemplo: “El equipo de recepción necesita verificar que lo que llega en el pallet coincide con la orden esperada, y registrar las discrepancias.” ¿Sigue siendo válido en papel? Sí. Totalmente. De hecho, hacerlo en papel es exactamente lo que hacían antes.

Ejemplo: “En tiempo real, cada cambio en la posición de preparador debe actualizarse en un mapa.” ¿Sigue siendo válido? El problema real es “supervisor necesita visibilidad de ubicación preparadores”. La versión original prescribe “en tiempo real” y “mapa”, que son detalles de solución.

Los Tres Veredictos

Cuando Quality Guard termina de evaluar un PRD, entrega uno de tres veredictos:

PASS (≥ 7.0)

El PRD está listo. El problema está bien definido. Las tres dimensiones están en buen estado. El producto puede comenzar a diseñar con confianza.

CONDITIONAL (5.0 - 6.99)

El PRD está cerca, pero tiene agujeros específicos. Quality Guard genera un documento de handoff estructurado que le dice al negocio exactamente qué falta. No es un rechazo. Es una guía: “Vuelve, agrega esto, y estaremos listos.”

Ejemplos: “Métrica baseline clara pero falta target. ¿Cuál es el estado deseado?”, “Observaciones de campo de solo 2 personas. Necesitamos 5+ para validar patrón.”, “AS-IS documentado pero TO-BE falta.”

FAIL (< 5.0)

El PRD está muy lejos. Falta información crítica o hay tanta contaminación que no se puede confiar en que el problema esté bien entendido. Quality Guard genera un documento de escalada con: qué dimensión es más débil, qué información falta, y sugerencia de próximos pasos (Gemba walk, entrevistas, mapping de proceso).

La Filosofía detrás de Quality Guard

Quality Guard no está juzgando si el problema es importante. Lo que verifica es diferente: está verificando que la información necesaria para que el producto tome buenas decisiones esté realmente presente.

Es un check de integridad de información, no de importancia estratégica.

Imagine que está a punto de hacer cirugía. El cirujano necesita: diagnóstico claro, datos de laboratorio, comparativa, y anatomía. Si el doctor no tiene eso, no importa cuánto quiera operar. Podría operar en el lugar equivocado.

Quality Guard es el enfermera que dice: “Doctor, ¿tenemos todos los datos que necesita antes de entrar al quirófano?”

Un Caso Real: Recepción en Almacén de Lleida

El equipo de Supply trae un PRD: “Mejorar eficiencia de recepción de merchandise en almacenes mediante modernización del proceso.”

Análisis D1 (Completitud): No hay métrica baseline. Dice “recepción lenta” sin decir qué tan lenta. Hay nota de una visita a Lleida con una persona. Impacto vago. Score: 4/10.

Análisis D2 (Proceso): Diagrama vago sin actores ni herramientas. TO-BE falta. Actores mencionados sin claridad. Score: 3/10.

Análisis D3 (Separación): “Sistema digital que integre escaneo de código de barras, sincronización automática con inventario central, y reportes automáticos.” Esto prescribe arquitectura completa sin especificar el problema. Score: 7/10 (10 - 3 por antipattern crítico).

Score final (mínimo): 3/10. Veredicto: FAIL.

Quality Guard genera documento de handoff con qué falta: datos baseline, observación de campo (Gemba walk 4 horas en Lleida, 20+ recepciones), entrevistas a 5+ recepcionistas, mapeo de proceso AS-IS/TO-BE, y limpieza de prescripciones técnicas.

El equipo de Supply hace la Gemba walk. Descubre: recepción toma 12 min/pallet, 1800 pallets/mes = 360 horas/mes. 18% de pallets tienen discrepancias. Investigar discrepancia toma 8 min/pallet en papel + sistema. 4 recepcionistas (turno 6-14h), 1 analista (turno 8-16h) — recepcionistas esperan al analista. Operador logístico recibe reporte por email 2 horas después, cuando ya se fue.

Supply trae PRD v2: D1: 9/10 (métricas, observaciones, impacto). D2: 8/10 (AS-IS y TO-BE claros). D3: 8/10 (sin prescripciones). Score final: 8/10. Veredicto: PASS.

Por Qué Quality Guard Importa: Separar Descubrimiento de Entrega

La idea central de Agile era correcta: no esperes a tener todo especificado, comienza a construir, itera. Pero una generación de gestores lo mal-interpretó como: “No necesitamos especificación de problemas.”

Lo que una organización madura necesita es diferente:

Fase 1: Descubrimiento (semanas o meses) — Negocio entiende el problema profundamente. Producto investiga alternativas. Resultado: PRD que PASS Quality Guard.

Fase 2: Entrega (semanas) — Producto diseña y construye. Negocio responde preguntas tácticas. Resultado: incremento completado.

Quality Guard es el guardián que separa estas dos fases. Para Mercadona, esto significa: menos sorpresas en sprints, mejor productividad del equipo de producto, y mejor velocidad general. Es una inversión de 1-2 semanas extra en descubrimiento para ahorrar 6-8 semanas en re-trabajo.

Conclusiones: El Guardián de la Claridad

La calidad de un PRD no se mide por cuánto detalle tiene, sino por cuánta CLARIDAD tiene sobre el problema, separado de la solución.

Aprendizajes clave: La separación QUÉ/CÓMO es sagrada. Tres dimensiones de evaluación (Completitud, Proceso, Separación). Tres veredictos claros (PASS, CONDITIONAL, FAIL). El Alternative Tool Test. La filosofía de integridad de información. Y el costo de no hacerlo: re-hacer cuesta 6-8 semanas; hacer bien desde el inicio cuesta 1-2 semanas extra.

La pregunta final: ¿Cuál es el costo de comenzar a construir sin saber realmente qué se está construyendo? En Mercadona, donde los cambios pueden afectar a 250 puntos de venta y miles de empleados, ese costo es extremadamente alto. Quality Guard existe para reducirlo.

En el siguiente artículo de esta serie, exploraremos cómo Research Mom Test toma estos PRDs claros y extrae de ellos las verdaderas necesidades del usuario, contrastadas contra la realidad. Porque “problema bien definido” no es lo mismo que “problema realmente entendido”.

Próximo artículo: Artículo 3 — “Research Mom Test: Validación de Problemas contra la Realidad del Campo”

Serie “AI Mercadona User Story Framework” — Febrero 2026

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.

Una versión que pasa de beta a live, una nota de prensa, un “ya está disponible”.

Pero con los productos impulsados por inteligencia artificial, esa lógica deja de funcionar. Porque la IA no termina de lanzarse nunca. Su valor no está en el día en que se publica, sino en cómo aprende y mejora con el tiempo.

El Go-To-Market de un producto con IA no es una línea de meta, es el inicio de una evolución permanente.

De la foto al proceso

Cuando lanzas un producto tradicional, entregas una promesa cerrada: esto hace X, cuesta Y, y funciona así.

En cambio, al lanzar un producto con IA, entregas una promesa viva: esto hoy hace X, pero mañana lo hará mejor.

El problema es que esa promesa viva también es un riesgo. Porque cuando la mejora depende del aprendizaje del modelo, el usuario puede percibir que el producto aún no está “maduro”.

Por eso, los equipos de producto que trabajan con IA tienen que repensar por completo su estrategia de Go-To-Market: no solo cómo lanzar, sino cómo comunicar la evolución, cómo gestionar la incertidumbre y cómo crear confianza en lo imperfecto.

Un nuevo tipo de lanzamiento

Lanzar un producto de IA no se parece a lanzar una app o un SaaS.

Hay tres grandes diferencias que cambian las reglas del juego:

1. La versión 1.0 nunca es definitiva

   Los modelos necesitan datos reales para mejorar. El producto que se lanza no es “final”, sino una base que se entrena con cada usuario.

2. El producto no se comporta igual para todos

   Dos personas pueden tener experiencias completamente distintas. El mensaje deja de ser “funciona igual para todos” y pasa a ser “se adapta a cada uno”.

3. La propuesta de valor evoluciona en público:

   Los fallos o sesgos del modelo se corrigen con exposición real. El Go-To-Market también es un ejercicio de humildad: reconocer que la versión inicial no es perfecta, pero que está diseñada para aprender rápido.

Caso: el lanzamiento de Copilot

Cuando GitHub presentó Copilot, el producto estaba lejos de ser infalible. A menudo generaba código incorrecto o sugerencias poco útiles. Pero el equipo fue transparente desde el principio:

“Copilot no reemplaza al desarrollador; es un asistente que aprende contigo.”

Esa frase cambió las reglas del juego. Ya no se esperaba precisión absoluta, sino colaboración progresiva. El lanzamiento fue un éxito, no porque el modelo fuera perfecto, sino porque se comunicó como un proceso vivo, no como un producto acabado.

La comunicación como diseño

En los productos con IA, comunicar el lanzamiento es parte del diseño del producto.

No es solo marketing, es diseño de expectativas.

Tres principios clave:

1. Comunicar el aprendizaje, no solo la funcionalidad

   El usuario debe entender que el producto va a mejorar con su uso.

   Ejemplo: Notion AI muestra claramente “Esta función aprende de cómo la usas”.

2. Mostrar límites con transparencia

   “Puede contener errores” o “Generado automáticamente” no restan confianza. La aumentan.

3. Celebrar la mejora continua

   Cada iteración del modelo es parte de la narrativa del producto. “Ahora entiende mejor el contexto” no es una nota técnica, es una historia de progreso.

Estrategias de GTM adaptadas a IA

Un Go-To-Market efectivo para productos con IA es una conversación continua, no una campaña puntual.

Algunas estrategias que están funcionando:

• Lanzamientos iterativos públicos

  Fases progresivas, betas por invitación, comunidades piloto.

  Ejemplo: Midjourney creció dentro de Discord antes de abrirse al público.

• Comunidad como canal de mejora

  Los usuarios no son audiencia, son co-entrenadores. Feedback, ejemplos, y sugerencias nutren el modelo.

• Métricas narradas

  No basta con decir “el modelo mejora”: hay que mostrarlo. Comparativas, ejemplos, cambios visuales. Cada mejora debe sentirse tangible.

• Feedback como feature

  El botón “Esto fue útil / no fue útil” es parte del producto, no un elemento decorativo.

GTM de productos internos: el cliente es tu propio equipo

No todos los productos con IA se lanzan al mercado. Algunos se lanzan dentro de las propias organizaciones, para optimizar flujos, automatizar procesos o asistir a equipos internos. Y aquí el Go-To-Market cambia completamente.

El reto ya no es captar atención, sino ganar confianza y adopción. Porque dentro de una empresa, la resistencia al cambio puede ser mayor que fuera.

1. Vender la utilidad, no la tecnología

Los usuarios internos no quieren saber qué modelo usas, sino cómo les ahorra tiempo o errores. La narrativa del GTM debe centrarse en valor tangible: tiempo, claridad, reducción de carga manual.

2. Integrar con lo que ya existe

Nadie quiere abrir otra herramienta. El éxito de un GTM interno depende de integrarse en los flujos actuales: Slack, Jira, Notion, correos, dashboards.

Cuanto más invisible, más adoptado.

3. Apoyarse en embajadores internos

Antes que una campaña, crea una red de early adopters dentro del equipo.

Son los que validan el valor real y ayudan a evangelizar el producto desde dentro.

4. Medir adopción como aprendizaje, no como éxito

Si una feature no se usa, no significa que haya fracasado. Significa que aún no resolvió un problema real o que el equipo no la entiende. En IA, el usage gap es feedback, no derrota.

5. Comunicar la evolución con transparencia

En entornos internos, la comunicación es aún más crítica. La confianza se gana mostrando avances concretos: ejemplos de mejora, comparativas, correcciones de errores.

El mensaje clave: “esto no es magia, es mejora continua”.

Gestionar la incertidumbre: el arte de la confianza imperfecta

El mayor obstáculo de los productos con IA no es técnico: es psicológico.

El usuario —interno o externo— debe aceptar que el producto está aprendiendo.

Y eso solo ocurre si hay transparencia y coherencia.

El caso de ChatGPT lo ilustra bien:

“El modelo no siempre tiene razón, pero siempre está aprendiendo.”

Esa frase define una relación basada en confianza imperfecta. Y esa confianza es lo que mantiene al usuario en el ciclo de mejora.

El rol del PM en el Go-To-Market de IA

El product manager ya no gestiona un “día de lanzamiento”. Gestiona un viaje de aprendizaje compartido. Su trabajo no termina cuando el producto sale, empieza ahí.

Debe diseñar el GTM como una narrativa que evoluciona: cómo cambia el producto, qué aprende de los usuarios, y cómo comunicar cada paso con claridad y coherencia.

El takeaway

Los productos impulsados por IA no se lanzan para ser perfectos. Se lanzan para aprender en público. El éxito del Go-To-Market no está en la campaña ni en el hype, sino en la capacidad de construir confianza, comunidad y continuidad.

En la era de la IA, el lanzamiento no es un evento. Es el comienzo de una conversación entre el producto, el modelo y las personas que lo hacen crecer.

¿quién está realmente al mando?

Cuando un algoritmo sugiere una canción, completa una frase o elige qué noticia aparece primero en nuestro feed, parece que seguimos decidiendo nosotros.

Pero la realidad es más ambigua: la IA ya está influyendo —sutilmente— en nuestras decisiones, preferencias y hábitos.

Y a medida que los modelos se vuelven más sofisticados, el equilibrio entre asistencia y autonomía se vuelve más frágil.

El gran reto del diseño de producto en esta era no es crear sistemas que piensen por nosotros, sino diseñar formas de colaboración donde humanos e inteligencia artificial trabajen juntos sin que uno borre al otro.

De la automatización al acompañamiento

Durante mucho tiempo, la tecnología se diseñó con un objetivo claro: automatizar tareas repetitivas.

Hacer las cosas más rápido, con menos intervención humana. Pero la IA moderna no se limita a ejecutar; interpreta. Analiza contexto, anticipa intenciones, sugiere caminos. Y eso cambia por completo la naturaleza del producto.

Un ejemplo claro es el salto entre los pilotos automáticos de los aviones y los sistemas de conducción asistida de Tesla. El piloto automático sigue reglas claras; el sistema de Tesla “aprende” de la experiencia colectiva.

Ya no obedece, colabora.

Y ese pequeño matiz —colaborar— es el que marca el inicio de una nueva era de diseño de producto: la era del human-in-the-loop.

Qué significa realmente

human-in-the-loop

El término nació en entornos industriales y militares, pero hoy es fundamental para diseñar experiencias con IA.

Un sistema human-in-the-loop es aquel donde el humano sigue en el circuito de decisión.

Supervisa, corrige, enseña. Y, sobre todo, puede intervenir antes de que algo salga mal.

En otras palabras: no se trata de evitar la automatización, sino de asegurarse de que la responsabilidad última sigue siendo humana.

Tres niveles de intervención humana

Podemos pensar en tres niveles donde el usuario participa en un sistema con IA:

1. Antes de la decisión (human-in-command)

El usuario establece los límites, los objetivos o las reglas del sistema.

Por ejemplo, al configurar ChatGPT para responder con un tono profesional o educativo.

2. Durante la decisión (human-in-the-loop)

El usuario colabora en tiempo real con la IA.

Un diseñador revisando las propuestas que genera Figma, o un médico validando un diagnóstico sugerido por un modelo.

3. Después de la decisión (human-on-the-loop)

El humano no participa directamente, pero supervisa el rendimiento y los resultados del sistema, interviniendo cuando detecta errores o sesgos.

El desafío está en elegir el nivel adecuado para cada contexto: más automatización no siempre significa más valor.

Ejemplo: el caso de Duolingo Max

Cuando Duolingo introdujo su versión con IA generativa —Duolingo Max—, la empresa tuvo claro que el sistema debía ayudar al usuario a aprender, no solo a acertar.

Por eso, en lugar de mostrar simplemente si una respuesta era correcta o no, la IA explica por qué está bien o mal.

El usuario puede pedir una aclaración, repetir la frase, o incluso “hablar” con el personaje que la corrigió.

Esa interacción —guiada pero abierta— es human-in-the-loop en estado puro:

el sistema automatiza la práctica, pero mantiene al humano en el centro del aprendizaje. La magia está en que la IA no sustituye al profesor, sino que amplifica su presencia.

Patrones de diseño para mantener el control humano

Diseñar productos que equilibren autonomía y supervisión no es fácil, pero hay patrones que están demostrando funcionar:

1. El modelo propone, el usuario decide

La IA nunca ejecuta sin aprobación.

Ejemplo: Gmail sugiere respuestas rápidas, pero tú eliges si las envías o no.

2. Transparencia contextual

El usuario debe saber cuándo está interactuando con una IA y cómo esa intervención afecta el resultado.

Ejemplo: Photoshop ahora etiqueta automáticamente las imágenes generadas con IA generativa.

3. Corrección reversible

Todo sistema inteligente debe permitir deshacer y enseñar.

Cuando corriges una recomendación de Spotify o rechazas una sugerencia de Copilot, no solo ajustas tu experiencia; ayudas al modelo a mejorar.

4. Confianza ganada, no asumida

La autonomía no se concede por defecto, se gana con el tiempo.

Tesla, por ejemplo, exige al conductor mantener las manos en el volante: la automatización se amplía solo si el sistema demuestra fiabilidad.

5. Explicabilidad sin fricción

Los mejores sistemas comunican sus límites sin romper la experiencia.

Un mensaje como “esta respuesta puede contener errores” puede parecer trivial, pero genera un efecto psicológico de control y honestidad.

Cuando la IA se pasa de lista

Hay un momento peligroso en todo producto con IA: cuando intenta anticipar demasiado. Piénsalo: cuando tu teléfono corrige una palabra que no querías cambiar, cuando un recomendador insiste en ofrecerte algo que ya has rechazado, cuando un sistema “decide” por ti con exceso de confianza.

Ese tipo de automatismo rompe la sensación de control, y lo que era mágico se convierte en frustrante.

Uno de los mejores ejemplos fue Microsoft Tay, el chatbot lanzado en Twitter en 2016.

Aprendía de las conversaciones con los usuarios, pero sin filtros ni supervisión humana.

En menos de 24 horas, el sistema empezó a emitir mensajes ofensivos y racistas.

El experimento fue un fracaso técnico, pero una lección de diseño: sin control humano, los sistemas aprenden lo peor de nosotros.

Ética, responsabilidad y producto

El human-in-the-loop no es solo una decisión de diseño; es una posición ética.

Porque toda automatización lleva implícita una transferencia de poder.

Y cada vez que un producto decide por nosotros, le estamos delegando una parte de nuestro juicio.

El trabajo del PM es asegurarse de que esa delegación sea consciente, reversible y explicable.

No se trata de desconfiar de la IA, sino de diseñar los límites de su autonomía con criterio y propósito.

El takeaway

El futuro del diseño de producto no será 100% automatizado, ni 100% humano.

Será colaborativo.

El desafío del control humano consiste en construir tecnología que amplifique nuestras capacidades sin apropiarse de ellas.

👉 Diseñar human-in-the-loop no es frenar la innovación; es darle dirección.

Porque si los humanos salimos del circuito, la inteligencia deja de ser realmente inteligente.

Durante años, en los equipos de producto hemos perseguido la velocidad como una virtud en sí misma. La velocidad como símbolo de agilidad, de foco, de ejecución. “Entrega rápido, aprende rápido”.

Pero de repente, la IA generativa ha cambiado el significado de esa palabra.

Ahora, “entregar rápido” puede significar algo radicalmente distinto: escribir un prompt, y en segundos tener un PRD, un wireframe o un test de usuario.

El cuello de botella ya no está en producir, sino en pensar. Y eso lo cambia todo.

1. Discovery: cuando entender lleva más tiempo que preguntar

Antes, el discovery era una carrera de resistencia. Recolectar datos, hacer entrevistas, sintetizar aprendizajes. El reto era procesar.

Hoy, un modelo puede leer cien entrevistas en diez segundos y devolverte un mapa de insights perfectamente redactado.

Y sin embargo, lo que no puede hacer es distinguir lo que es importante de lo que solo suena bien.

Ahí nace la paradoja: la IA te ahorra tiempo analizando, pero te obliga a invertir más tiempo en formular las preguntas correctas.

Cuando todo puede responderse en segundos, el verdadero trabajo es decidir qué merece la pena preguntar.

Un ejemplo sencillo: imagina que analizas feedback de clientes que abandonan el carrito.

El LLM te dirá que “la mayoría abandonan por los gastos de envío o la fricción en el pago”.

Perfecto, pero eso no es nuevo. El descubrimiento empieza cuando preguntas por qué ese problema sigue existiendo pese a que todos lo conocen.

Esa pregunta —más que la síntesis automática— es la que lleva al aprendizaje real.

La IA convierte el discovery en un proceso más rápido, sí, pero también más frágil: puedes moverte a toda velocidad… en la dirección equivocada.

Por eso, el valor está en la curiosidad bien dirigida, no en la rapidez de los análisis.

2. Prototipado: del arte de diseñar al arte de editar

Diseñar ya no es dibujar, es conversar.

Hoy puedes pedirle a un modelo: “hazme una app para comparar planes de energía con un tono confiable y claro” y tendrás un mockup convincente en segundos.

Pero esa facilidad tiene un efecto sutil: cuando el coste de producir baja a cero, sube el riesgo de conformarse con lo primero que parece “suficiente”.

El prototipado ya no sirve para construir algo que no existe, sino para pensar con las manos.

La diferencia es que antes necesitabas un diseñador para hacerlo tangible, y ahora puedes hacerlo tú mismo, pero la calidad del resultado depende de tu criterio.

La IA te da velocidad, pero no te da gusto, ni conocimiento del contexto, ni sensibilidad por los matices.

El diseñador del futuro —y el product manager también— tendrá que dominar algo que hasta ahora no se enseñaba: saber editar.

No generar más, sino discernir mejor.

Porque cuando todo el mundo puede producir, la ventaja pasa a estar en saber qué descartar.

3. Validación: más datos, menos comprensión

La IA también promete revolucionar la validación: puedes crear tests automáticos, sintetizar feedback y hasta simular usuarios reales.

Y sin embargo, nada de eso sustituye el contacto con la realidad.

Cuando validas con datos generados, lo que obtienes es una coherencia estadística, no una señal humana.

El peligro es validar una ilusión: una hipótesis que parece sólida porque los datos la confirman… pero que no ha pasado por la prueba del comportamiento real.

Por eso, en esta era, la validación debería ser menos sobre cantidad de tests y más sobre calidad del aprendizaje.

Un buen test no es el que se ejecuta rápido, sino el que te obliga a cambiar de opinión.

Un ejemplo: lanzar una nueva experiencia de checkout y ver un +2% en conversión puede parecer éxito.

Pero si al mes bajan los pedidos recurrentes, o suben las incidencias, el experimento rápido solo te ha enseñado a optimizar un síntoma.

La IA te acelera el corto plazo; el criterio es el que protege el largo.

4. El dilema del ritmo

La velocidad ha sido siempre una ventaja competitiva, pero en la era de la IA deja de ser un diferencial: es una commodity.

Todos pueden moverse rápido. Lo difícil es saber cuándo no hacerlo.

La pregunta clave ya no es “¿cómo vamos más rápido?”, sino “¿cuál es el ritmo adecuado para aprender sin romper lo importante?”.

El discovery, el prototipado y la validación son ahora más cortos, más iterativos, más baratos.

Pero si los haces sin pausa para pensar, solo habrás cambiado tiempo por superficialidad.

La IA nos enfrenta a un tipo distinto de presión: no la de hacer más, sino la de decidir mejor qué merece la pena hacer.

Y eso requiere algo que ningún modelo puede generar: criterio colectivo.

5. De la eficiencia al sentido

La eficiencia siempre ha sido el lenguaje del producto. Menos fricción, menos coste, menos ciclos.

Pero la IA lleva la eficiencia a un nivel tan alto que amenaza con vaciarla de propósito.

¿De qué sirve ser ultrarrápido, si no tienes claro hacia dónde te diriges?

Los equipos que mejor usen la IA no serán los que generen más entregables, sino los que logren aprender con intención.

Acelerar para explorar, no para cerrar. Prototipar para pensar, no para justificar. Validar para entender, no para confirmar.

La IA no hace que el oficio de producto desaparezca. Lo vuelve más filosófico.

Nos obliga a preguntarnos qué significa realmente “hacer progreso” cuando cualquier cosa puede producirse en segundos.

6. En resumen

• La IA acelera el ciclo de entrega, pero el límite real está en nuestra capacidad de aprender.

• Discovery se convierte en el arte de preguntar bien.

• Prototipado se transforma en el arte de editar y tener criterio.

• Validación exige más humildad que nunca: no todo lo que parece funcionar, funciona de verdad.

• Y la velocidad deja de ser el fin: pasa a ser una herramienta al servicio del sentido.

Porque en el fondo, construir producto siempre fue una conversación entre lo que el negocio puede, lo que el usuario necesita y lo que el equipo entiende.

La IA solo hace que esa conversación ocurra más rápido.

Pero el valor sigue estando, como siempre, en lo que decidimos escuchar.

El product manager vivía cómodo entre tasas de conversión, embudos y cohortes. Pero con la llegada de la inteligencia artificial, esa claridad empezó a desvanecerse. Porque, ¿cómo mides el éxito de algo que aprende, cambia y genera resultados diferentes cada vez? ¿Cómo sabes si el producto “funciona” cuando ni siquiera hay una única respuesta correcta?

Bienvenido a la nueva frontera del product management: las métricas vivas de los productos con IA.

Cuando las métricas clásicas ya no bastan

Las métricas de toda la vida —DAU, retención, conversión— siguen siendo útiles, pero cuentan solo una parte de la historia. Un chatbot puede tener miles de usuarios diarios, pero si la mayoría lo abandona frustrado después de tres respuestas, esa métrica deja de significar éxito. La IA introduce una capa de complejidad: no solo hay que medir lo que el usuario hace, sino cómo se siente y qué aprende el sistema.

Un producto inteligente no se mide solo por lo que entrega hoy, sino por qué tan bien mejora con el tiempo.

Dos tipos de aprendizaje: el humano y el del sistema

Un buen producto de IA evoluciona en dos direcciones:

1. El usuario aprende a usar el sistema.

   Por ejemplo, en ChatGPT o Midjourney, el usuario mejora sus prompts y obtiene resultados más precisos. La experiencia se vuelve más valiosa con la práctica.

2. El sistema aprende del usuario.

   Sus respuestas, recomendaciones o predicciones mejoran con cada interacción.

Medir estos dos aprendizajes —el del usuario y el del sistema— es el nuevo reto del PM. Porque el valor real no está en una acción puntual, sino en la relación dinámica entre ambos.

Nuevas métricas para una nueva era

Aquí tienes algunas métricas emergentes que los equipos más avanzados están usando para medir productos con IA:

1. Tasa de éxito percibido (Perceived Success Rate)

No mide si la IA “acertó” técnicamente, sino si el usuario sintió que la respuesta fue útil. En IA generativa, esa percepción es más importante que la precisión.

2. Confianza del usuario (User Trust Index)

Una métrica subjetiva, pero medible con feedback continuo: ¿qué tan dispuesto está el usuario a delegar tareas al sistema? ¿cuándo deja de revisar o corregir lo que la IA sugiere?

3. Reducción de esfuerzo (Effort Reduction Rate)

Mide cuánto trabajo ahorra el producto al usuario. Si antes necesitaba cinco pasos y ahora solo uno, el valor de la IA está ahí, aunque el flujo total sea más corto.

4. Tasa de aprendizaje del modelo (Model Learning Rate)

Indica cuánto mejora el modelo con cada nueva interacción. Por ejemplo, si el porcentaje de respuestas “satisfactorias” aumenta sin intervención humana, el sistema está aprendiendo bien.

5. Tasa de corrección humana (Human Correction Rate)

Cuántas veces el usuario necesita corregir o reintroducir una respuesta. Una IA con baja tasa de corrección inspira confianza; una con alta tasa genera frustración o desconfianza.

6. Calidad emergente

Mide cómo evoluciona la experiencia cuando el producto se usa en contextos distintos. Por ejemplo, ¿responde igual de bien un asistente de IA en inglés que en español? ¿mantiene consistencia entre usuarios expertos y novatos?

El cambio de mentalidad: de métricas absolutas a métricas evolutivas

El PM clásico medía estados: cuántos usuarios tengo, cuántos compran, cuántos se quedan. El PM de productos con IA mide trayectorias: cuánto aprende el sistema, cuánto confía el usuario, cuánto se reduce la fricción con el tiempo. El foco pasa de la foto al vídeo. No importa solo el resultado puntual, sino la curva de aprendizaje entre el usuario y la IA.

Métricas que también pueden engañar

No todo lo que se puede medir tiene sentido.

Algunos errores comunes:

• Confundir engagement con valor. Que el usuario interactúe mucho no significa que esté satisfecho. A veces, la alta interacción es síntoma de que la IA falla y el usuario insiste.

• Celebrar mejoras locales sin ver el sistema completo. Un modelo que reduce errores en un área puede generar nuevos sesgos en otra.

• Optimizar para la precisión, ignorando la percepción. Un asistente ultra preciso pero frío y robótico puede ser peor que uno algo menos exacto, pero más empático.

En IA, medir bien significa entender el contexto del error tanto como el acierto.

El rol del PM: diseñar la conversación con los datos

El PM ya no solo define qué construir, sino qué medir y por qué. Y, sobre todo, cómo conectar esas métricas con la experiencia real del usuario. Debe convertirse en traductor entre datos y significado. No basta con tener dashboards: hay que saber qué historia cuentan y qué historia ocultan. En productos con IA, las métricas no son solo indicadores de rendimiento; son parte del diseño del sistema. Lo que decides medir, termina moldeando lo que la IA aprende.

El takeaway

Los productos con IA no se evalúan solo por cuántos los usan, sino por qué tan bien aprenden, ayudan y generan confianza.

El éxito ya no está en las conversiones o los clics, sino en el grado de entendimiento mutuo entre el usuario y el sistema.

👉 En esta nueva era, el product manager no persigue métricas estáticas, sino señales vivas de aprendizaje, mejora y confianza.

El reto no es medir más, sino medir mejor.

La primera vez que usaste ChatGPT y te devolvió una respuesta perfectamente redactada, o cuando Spotify te descubrió una canción que parecía escrita para ti, sentiste esa mezcla de asombro y gratitud que solo generan los productos “mágicos”.

Pero esa misma magia tiene un lado oscuro: en cuanto el usuario no entiende por qué el sistema hace lo que hace, la confianza se resquebraja.

La línea entre el “esto es increíble” y el “esto da miedo” es más fina de lo que parece.

La paradoja de la IA: cuanto más acierta, menos entendemos cómo

La IA tiene una cualidad curiosa: cuanto más sofisticada es, más opaca se vuelve.

Los sistemas basados en reglas clásicas eran fáciles de explicar —si pasa X, haz Y—.

Pero los modelos modernos aprenden de millones de ejemplos, ajustan pesos invisibles y generan resultados imposibles de rastrear por completo.

Para un product manager, esto plantea un dilema nuevo:

• Si simplificas demasiado la experiencia, pierdes credibilidad.

• Si la haces demasiado transparente, pierdes fluidez y magia.

Diseñar con IA ya no es solo una cuestión de UX, sino de psicología de la confianza.

La magia bien dosificada

El usuario quiere sentirse entendido, pero no engañado.

Cuando un producto acierta de forma tan precisa que parece leer la mente, la reacción inicial es de asombro… y la siguiente, de sospecha.

Netflix lo aprendió pronto.

En los primeros años de su sistema de recomendaciones, cuando la interfaz explicaba en exceso (“te recomendamos esto porque viste aquello”), la gente desconfiaba del algoritmo.

Hoy, el enfoque es más sutil: te muestran afinidades (“basado en tu historial”) pero sin entrar en detalles que rompan la ilusión.

Por el contrario, Google Photos ofrece una transparencia funcional: “te hemos agrupado estas fotos porque reconocimos caras similares”.

No quita magia, pero añade contexto y control.

El secreto está ahí: mostrar la lógica sin desvelar el truco.

Explicabilidad como experiencia, no como disclaimer

Muchos equipos tratan la explicabilidad como una obligación legal o ética, cuando en realidad es una oportunidad de diseño.

No se trata de añadir un texto que diga “esta respuesta fue generada por IA”, sino de integrar señales que transmitan control.

Ejemplos:

• ChatGPT añade la frase “puede contener errores” como recordatorio sutil de incertidumbre.

• Midjourney permite ajustar el nivel de aleatoriedad de las imágenes generadas, dándole al usuario sensación de agencia.

• YouTube Music o TikTok dejan claro cuándo una recomendación es automática, sin romper el flujo.

La explicabilidad no tiene que restar fluidez; puede convertirse en parte de la confianza emocional del producto.

Diseñar con grados de opacidad

No todos los usuarios necesitan el mismo nivel de explicación.

El reto está en adaptar la transparencia al contexto y al perfil:

• En tareas de entretenimiento, la magia pesa más.

  Nadie quiere un análisis técnico de por qué Netflix cree que te gustará Succession.

• En tareas críticas —salud, finanzas, educación— la transparencia debe ser total.

  El usuario no quiere magia; quiere garantías.

Por eso, los mejores productos de IA no son completamente transparentes ni totalmente opacos. Son gradualmente explicables: ofrecen más contexto cuando el usuario lo necesita, no antes.

De la interfaz a la “interconfianza”

Durante años diseñamos interfaces: pantallas, botones, interacciones.

La IA nos obliga a diseñar algo nuevo: la interconfianza.

Ya no basta con que el usuario sepa qué hacer; debe creer que el sistema hará lo correcto.

Esa confianza se construye con señales sutiles:

• Feedback inmediato y coherente.

• Coherencia entre lo que el sistema dice y lo que hace.

• Capacidad de corrección cuando el modelo falla.

Un sistema de IA sin posibilidad de corrección es una caja negra; con corrección, se convierte en un compañero.

El rol del PM: guardianes de la confianza

En productos impulsados por IA, el PM no solo define qué hace el sistema, sino también cómo explica sus decisiones.

Debe asegurar que cada predicción, recomendación o acción tiene un nivel adecuado de claridad para su impacto.

No se trata de elegir entre magia o transparencia, sino de encontrar el punto exacto donde el usuario puede decir:

“No sé exactamente cómo lo hace, pero sé que puedo confiar en él.”

Esa es la frontera donde ocurre el verdadero valor de la IA.

El takeaway

Diseñar experiencias con IA no es un ejercicio de mostrar poder técnico, sino de construir confianza emocional.

El usuario debe sentir que el sistema le entiende,

pero también que él sigue al mando.

👉 La magia sin explicabilidad se vuelve sospechosa.

La explicabilidad sin magia se vuelve aburrida.

El equilibrio entre ambas es, probablemente,

la nueva frontera del diseño de producto.

Hoy esa visión se queda corta. Con la llegada de la inteligencia artificial, los productos han dejado de ser un catálogo cerrado de funciones para convertirse en ecosistemas vivos, donde la experiencia de usuario depende tanto de lo que el equipo diseña como de lo que el modelo aprende en cada interacción.

El PM ya no gestiona solo funcionalidades; gestiona comportamientos emergentes.

Del botón al comportamiento emergente

En un producto tradicional, el PM podía prever con exactitud lo que ocurriría tras cada acción del usuario.

• Si el usuario hacía clic en “añadir al carrito”, el sistema añadía un ítem.

• Si pulsaba “guardar”, el sistema guardaba.

Era una lógica determinista: input definido → output esperado.

Con IA, esto cambia radicalmente.

• Una misma acción puede generar resultados distintos según contexto y datos.

• La calidad ya no depende solo del código, sino también del dataset de entrenamiento, el modelo, y la situación particular del usuario.

• El producto evoluciona con el uso: cada interacción entrena al sistema, ajusta respuestas, mejora (o empeora).

Ejemplo claro: GitHub Copilot.

No es un simple “autocomplete” avanzado; es un copiloto que propone soluciones basadas en millones de repositorios y en el estilo concreto de cada desarrollador. El valor no está en un botón, sino en un ecosistema de datos y aprendizaje continuo.

Nuevos retos para el PM

Este cambio obliga a los product managers a repensar su rol en profundidad:

1. Diseñar experiencias, no outputs

Ya no puedes prometer un resultado fijo. Lo que diseñas son márgenes de confianza: qué es aceptable, cómo corregir errores y cómo comunicar incertidumbre al usuario. Un ejemplo es Google Translate, que hoy muestra alternativas a una traducción, reconociendo que puede haber más de una respuesta válida.

2. Gestionar datos como producto

Los datos dejan de ser un “input técnico” para convertirse en materia prima estratégica. El PM debe hacerse preguntas:

• ¿De dónde vienen nuestros datos?

• ¿Qué sesgos contienen?

• ¿Con qué frecuencia deben actualizarse?

  Sin buenos datos, no hay buen producto de IA, y ese es un terreno donde el PM ya no puede ser un invitado pasivo.

3. Equilibrar magia y control

El gran atractivo de la IA es su efecto “wow”: un sistema que parece entenderte. Pero demasiada magia puede romper la confianza si el usuario no entiende qué ocurre. Los mejores productos buscan equilibrio: sorprenden, pero también ofrecen explicabilidad y opciones de corrección.

4. Pensar en ecosistemas, no features

La IA rara vez es autosuficiente. Requiere integraciones, partners, APIs, comunidades. El rol del PM pasa de priorizar funcionalidades a orquestar un ecosistema.

Casos reales que lo ilustran

• ChatGPT Plugins: OpenAI no añadió “una feature” más; abrió un ecosistema de extensiones donde terceros aportan valor. El PM aquí diseña un marco, no un catálogo.

• Spotify + IA: su función de “DJ con inteligencia artificial” combina datos de escucha, modelos generativos y curación editorial. No es un botón nuevo; es una capa de inteligencia sobre todo su ecosistema de contenido.

• Tesla Autopilot: la conducción asistida no depende de una funcionalidad fija, sino de un sistema que aprende de millones de kilómetros recorridos. Cada coche alimenta al ecosistema.

En todos los casos, el PM deja de ser gestor de tareas para convertirse en arquitecto de sistemas complejos.

Qué cambia en la práctica del día a día

1. Discovery

   Ya no basta con entrevistas y encuestas. El PM debe considerar la disponibilidad y calidad de datos como parte del discovery.

2. Roadmap

   No se planifica solo en términos de funcionalidades, sino también de mejora de modelos, pipelines de datos e integraciones.

3. Validación

   El éxito no es binario (funciona / no funciona). Hay grados de precisión, confianza y satisfacción del usuario.

4. Iteración

   El aprendizaje continuo del modelo requiere pensar en ciclos de mejora diferentes a los de un producto de software clásico.

El nuevo toolkit del PM

El PM en la era de la IA no necesita ser ingeniero de machine learning, pero sí incorporar nuevas competencias:

• Entender lo básico de cómo funciona un modelo (inputs, outputs, limitaciones).

• Saber evaluar datasets: tamaño, representatividad, sesgos.

• Manejar métricas nuevas: confianza del usuario, tasa de error aceptable, impacto del feedback en la mejora del modelo.

• Diseñar flujos con “human-in-the-loop”: cuándo interviene la IA y cuándo debe decidir la persona.

El takeaway

La inteligencia artificial ha transformado la gestión de producto. Ya no se trata de añadir features, sino de orquestar ecosistemas donde datos, modelos, usuarios y partners conviven.

El PM deja de ser un gestor de funcionalidades para convertirse en un arquitecto de experiencias emergentes.

Su reto ya no es solo priorizar qué construir, sino también decidir cómo habilitar un sistema vivo que evolucione con cada interacción.

👉 En la era de la IA, el producto ya no es un catálogo de funcionalidades.

Es un organismo en constante aprendizaje.

Y el PM, más que nunca, es el responsable de que ese organismo crezca sano, útil y confiable.

Eso es onboarding invisible: un diseño de producto que enseña mientras se usa, sin interrumpir al usuario con explicaciones ni forzarle a aprender de manera artificial.

Del tutorial obligatorio al aprendizaje natural

En los primeros años de las apps móviles, lo normal era encontrarse con un tour inicial. Pantallas con flechas que te señalaban botones, mensajes explicativos (“Aquí puedes subir fotos”, “Aquí puedes invitar amigos”), o incluso pequeños juegos que te obligaban a “simular” el uso.

El problema era obvio:

• La mitad de los usuarios cerraba el tutorial antes de acabarlo.

• La otra mitad lo olvidaba en cuanto empezaba a usar el producto.

• Y lo más grave: muchas veces la primera experiencia real de valor llegaba demasiado tarde.

Un producto que exige explicación está trasladando un coste al usuario. Y en un mundo donde la fricción mínima es la regla, ese coste se traduce en abandono.

Qué significa “invisible”

El onboarding invisible no es ausencia de onboarding. Es integrarlo en la experiencia de uso.

Un ejemplo clásico es WhatsApp:

Nadie necesitó un tutorial para entender cómo enviar un mensaje de voz. El icono del micrófono estaba en el lugar adecuado, con el diseño correcto, y el comportamiento era intuitivo: mantener pulsado para hablar. Aprendiste haciéndolo.

Lo mismo ocurre con Notion: en el momento en que creas tu primera nota, ya estás entendiendo cómo funciona el editor de bloques. Nadie interrumpe tu flujo con un checklist, porque la interfaz en sí es el tutorial.

Y piensa en Apple Pay: no te explica todo en un manual. Te guía justo en el momento de pagar, cuando más lo necesitas, sin exigir un esfuerzo previo.

En todos los casos, el aprendizaje ocurre en contexto, no en una sala de espera antes de entrar al producto.

Por qué importa (más que nunca)

El onboarding invisible se ha vuelto crítico por tres razones:

1. Atención fragmentada: si tu usuario tarda más de unos segundos en encontrar valor, se va.

2. Competencia feroz: siempre hay otra app esperando captar ese mismo tiempo de uso.

3. Evolución de expectativas: los usuarios ya no toleran tutoriales largos porque están acostumbrados a experiencias que “simplemente funcionan”.

Un buen onboarding invisible se traduce en:

• Mayor activación: más usuarios llegan al “aha moment” inicial.

• Mejor retención temprana: menos abandonos en los primeros días.

• Una curva de aprendizaje más suave y personalizada: el usuario descubre funciones avanzadas a su ritmo.

Estrategias detrás del onboarding invisible

Diseñar este tipo de experiencias requiere intención. No ocurre por accidente. Algunas de las técnicas más efectivas:

1. Defaults inteligentes

   Configuraciones iniciales que funcionan bien para la mayoría de usuarios.

   Ejemplo: abrir la cámara del móvil y que ya esté ajustada a la luz, el enfoque y el formato correctos.

2. Micro-pistas contextuales

   Pequeños mensajes o señales que aparecen en el momento exacto.

   Ejemplo: Gmail detectando que escribiste “adjunto” y preguntándote si olvidaste añadir un archivo.

3. Progresión escalonada

   Mostrar funciones avanzadas solo cuando el usuario ya domina lo básico.

   Ejemplo: Figma, que empieza con las herramientas más simples, y solo después te sugiere atajos o plugins.

4. Contenido precargado o de ejemplo

   Enseñar a través de plantillas o demos ya listas.

   Ejemplo: Miro y Notion, que te muestran tableros o páginas de ejemplo para que explores.

5. Interacciones familiares

   Usar patrones de uso que el usuario ya conoce de otros productos.

   Ejemplo: deslizar para archivar en apps de correo, heredado de la metáfora física de mover algo fuera de la vista.

Riesgos y límites

El onboarding invisible no es una solución mágica. Tiene trade-offs:

• Ocultar demasiado: si todo se basa en descubrimiento, algunos usuarios nunca llegarán a usar funciones clave.

• Exceso de automatización: cuando el producto toma demasiadas decisiones por ti, puedes sentir pérdida de control.

• Medición compleja: el éxito del onboarding invisible no se mide en clicks a un tutorial, sino en métricas más sutiles:

  • Tiempo hasta la primera acción valiosa.

  • Porcentaje de usuarios que descubren una función sin ayuda externa.

  • Retención tras el primer uso.

En definitiva, la dificultad está en equilibrar simplicidad inicial con potencia avanzada.

Historias que inspiran

• Instagram en sus inicios: cuando la app salió, lo único que podías hacer era sacar una foto, aplicarle un filtro y publicarla. No necesitaba explicación. El resto de funcionalidades llegaron después, sin entorpecer la experiencia inicial.

• Spotify: te pide que elijas algunos artistas al inicio, y en segundos ya tienes playlists personalizadas. Ese gesto simple actúa como onboarding, sin tutorial, y a la vez alimenta su motor de recomendación.

• Duolingo: podrías pensar que un curso de idiomas necesita mucha explicación, pero la app te lanza directamente a practicar. Aprendes mientras juegas, sin sentir que estás en clase.

Lecciones para equipos de producto

1. El mejor tutorial es usar el producto: si necesitas demasiadas pantallas de explicación, quizás el diseño no es lo suficientemente claro.

2. La primera acción importa más que la primera sesión: enfoca el onboarding en llevar al usuario a realizar algo valioso rápidamente.

3. El onboarding nunca acaba: incluso usuarios avanzados necesitan descubrir nuevas funcionalidades.

4. Diseña para descubrir, no solo para explicar: piensa en cómo guiar al usuario a lo largo del tiempo, no solo en el minuto uno.

El takeaway

El onboarding invisible no es solo un truco de UX, es una filosofía de producto: el aprendizaje ocurre en el flujo, no en el manual.

Los productos que logran esto no solo reducen fricción, sino que crean la sensación de que “funcionan solos”. Y eso, en un mercado saturado, es oro.

👉 Si tu producto necesita un manual, probablemente el problema no sea el usuario.

Cuando asumí la responsabilidad del equipo, la situación era complicada. No se nos veía como un equipo con rumbo ni con una estrategia clara. Incluso dentro del propio management había dudas de si valía la pena mantenerlo o si era mejor disolverlo y repartir sus servicios entre otros equipos. En términos de percepción, no éramos fuertes ni en ingeniería ni en producto, y esa sombra nos acompañaba en cada conversación.

El diagnóstico

Pronto entendí que los problemas eran múltiples y, como suele ocurrir, no se reducían a una sola persona. Cada trimestre nos fijábamos objetivos pequeños, dispersos, que parecían más una lista de tareas inconexas que una dirección clara hacia un usuario o un impacto real. No había sensación de avance ni de logro.

En el ámbito técnico, el equipo se apoyaba mucho en su Tech Lead. Su conocimiento profundo del dominio era un activo importante, pero esa misma concentración de expertise derivaba en una dinámica donde los demás no alcanzaban toda la autonomía deseada. Esto no era tanto un fallo individual como un síntoma de cómo estaba configurada la responsabilidad dentro del equipo.

Mirando atrás, creo que el mayor error fue mío. Como Engineering Manager no fui lo suficientemente claro ni contundente en trasladar la urgencia de la situación. No di a tiempo el feedback honesto que podía haber ayudado a acelerar el cambio. En cierto modo, fui demasiado tolerante con una dinámica que ya mostraba señales de estancamiento. Esta falta de claridad inicial contribuyó a que el equipo siguiera en un ecosistema en el que nos costaba mostrar tracción y generar confianza.

Decisiones difíciles

La primera decisión vino acompañada de una circunstancia inesperada. El Tech Lead decidió moverse lateralmente y volver a un rol de backend, donde se sentía más cómodo y podía aportar con más foco. Vi en ese movimiento una oportunidad: quedarme yo de forma temporal al frente del equipo como Tech Lead. De esa manera podía asegurar estabilidad técnica y, al mismo tiempo, tomar el control de la dinámica general.

Al mismo tiempo, introduje nuevos perfiles en el equipo. Incorporé a un senior interno con experiencia consolidada dentro de la empresa. Su llegada me permitió liberarme espacio para dedicarme a lo que realmente necesitaba atención: el cuarteto formado por Tech Lead, Product Manager, Process Owner y Product Designer, cuyas relaciones estaban tensionadas. Mientras él se ocupaba de elevar la calidad y las prácticas de ingeniería, yo podía enfocarme en desatascar esas dinámicas. También sumé a un perfil senior externo, alguien que venía de fuera de la organización y que aportaba una mirada fresca y distinta, rompiendo inercias que nos anclaban al pasado.

En conjunto, estas decisiones representaron un reset controlado: crear condiciones para reconstruir sobre bases más sólidas, tanto en lo técnico como en lo relacional.

El proceso de reconstrucción

Mi foco inicial estuvo en el área de ingeniería, donde tenía libertad total para actuar. Ajusté los rituales: las dailies pasaron a ser breves, concisas, sin historias largas ni rodeos innecesarios. Las retrospectivas dejaron de ser sesiones para lamentarse y se transformaron en espacios para aprender de lo que había funcionado o no en el sprint y decidir qué cambiar en el siguiente. Y sobre todo, fui constante en el feedback. A cada persona le compartí de forma cruda y transparente cómo era percibido, dónde estaba parado y qué camino de mejora debía recorrer. La claridad era mi mejor herramienta.

El proceso no fue fácil. Al principio hubo resistencias y dudas legítimas sobre si realmente algo iba a cambiar. Pero poco a poco, gracias a la constancia y al compromiso, la dinámica empezó a transformarse. El ambiente fue mejorando, las entregas empezaron a ser más claras y la percepción externa, lentamente, se movió en la dirección correcta.

Los resultados

El resultado no se alcanzó de un día para otro. Se fue construyendo paso a paso durante un año completo. El progreso se reflejó sobre todo en la manera en que empezamos a plantear y alcanzar los objetivos trimestrales. Dejamos atrás la dinámica de pequeñas tareas inconexas y comenzamos a trabajar con dirección, con un plan más estructurado y con una visión de mayor recorrido.

En el primer trimestre abordamos un gran refactor del backend. Entendíamos que una parte de nuestra lentitud y frustración provenía de un sistema con demasiado legacy, que nos condicionaba y frenaba. Fue un esfuerzo exigente, pero necesario para liberar al equipo y sentar bases sólidas.

A partir de ahí, trimestre a trimestre, fuimos moviéndonos hacia un trabajo mucho más centrado en el usuario y en la entrega de valor. Cada objetivo ya no era una pieza aislada, sino que respondía a un plan coherente y a una narrativa clara de impacto. Esa transición fue clave: nos dio confianza, nos permitió mostrar avances tangibles y, poco a poco, cambiar la percepción externa sobre lo que el equipo era capaz de lograr.

También se notó fuera del equipo. A lo largo del año, en cada quarter la percepción del upper management fue mejorando: los objetivos definidos tras el refactor fueron bien recibidos y muy valorados por su coherencia y tracción. La conversación pasó de cuestionar nuestra continuidad a respaldar el rumbo y a preguntarnos cómo acelerar. Ese cambio de tendencia fue, en sí mismo, una señal de que el plan estaba funcionando.

Aprendizajes

De esta experiencia me quedo con varias lecciones. La primera, que los cambios profundos tardan mucho más de lo que uno imagina al comienzo. No basta con introducir un par de ajustes: se requiere constancia, paciencia y la disposición a mantener el rumbo durante meses.

También aprendí que el feedback honesto y directo es irremplazable. Si uno suaviza demasiado el mensaje o evita la incomodidad, lo que consigue es retrasar la mejora. En mi caso, el mayor error fue no haber sido claro desde el principio; esa falta de contundencia permitió que se consolidaran dinámicas poco sanas.

Aprendí también que para provocar un cambio real en un equipo no basta con ajustar procesos o discursos: hay que introducir cambios tangibles. Cambiar personas de equipo, moverlas a otros contextos o incorporar gente nueva con ojos frescos son medidas que ayudan a romper hábitos y dinámicas enquistadas con mayor rapidez. Son decisiones difíciles, pero aceleran la transformación y envían una señal clara de que el cambio va en serio.

Otra lección clave es que los problemas de un equipo nunca se deben a una sola persona: son una combinación de contexto, relaciones, expectativas y liderazgo. Eso me enseñó a mirar con una lente más amplia antes de señalar causas.

Finalmente, confirmé dos cosas esenciales: la importancia de no rendirse —mantener una visión clara del destino y confianza en que se puede llegar— y la humildad de reconocer que no se puede hacer todo en solitario. Pedir ayuda al upper management en momentos críticos fue lo que nos permitió seguir avanzando cuando el camino se atascaba.

Durante este año he usado mucho una metáfora que me ayudaba a transmitir esta idea. Los jugadores de fútbol de los equipos top suelen tener las piernas cansadas porque juegan varias competiciones al mismo tiempo. Si quieres estar en todas las competiciones y optar a la victoria, el tradeoff es asumir un esfuerzo extra. Con los equipos pasa lo mismo: aspirar a más exige aceptar que habrá momentos de desgaste, y es precisamente ahí donde la resiliencia y el apoyo mutuo marcan la diferencia.

Al final, esta no es solo la historia de un equipo que salió adelante. Es también un recordatorio de que, con honestidad, autocrítica, decisiones valientes y perseverancia, incluso las crisis más profundas pueden convertirse en historias de éxito.

La aventura comienza en 2004, cuando Jason Hoffman, un investigador en cáncer que decidió dar un giro hacia el emprendimiento, fundó Joyent. Mientras Amazon apenas estaba tanteando la idea de AWS, Joyent ya alojaba a las startups más prometedoras de Internet. Twitter confió sus primeros pasos a su infraestructura, LinkedIn escaló gracias a sus servidores, y cuando Facebook abrió su ecosistema a aplicaciones de terceros en 2007, Joyent se alió con Dell para alojarlas todas. Algunos relatos aseguran incluso que fue clave en el desarrollo del chat de Facebook. Estaban en todas partes, aunque casi nadie lo sabía.

Pero lo más impresionante de Joyent no eran sus clientes, sino su tecnología. En 2005 lanzaron SmartOS, un sistema operativo que introducía el concepto de container virtualization a través de Solaris Zones. Era 2005: Docker no aparecería hasta 2013. La eficiencia era tal que un solo servidor de Joyent podía manejar lo que en Amazon requería varias instancias EC2. En el sector, algunos expertos llegaron a decir que era mucho mejor que AWS. Y, sin embargo, cometieron un error fatal: lo construyeron sobre Solaris en lugar de Linux, justo lo contrario de lo que los desarrolladores querían. La innovación era brillante, pero el ecosistema no estaba preparado para adoptarla.

En 2010 Joyent fichó a Ryan Dahl, el creador de Node.js, y se convirtió en el guardián de lo que pronto sería una de las plataformas de desarrollo más importantes del mundo. Hoy Node.js está en todas partes: la NASA lo utiliza, Netflix también, igual que LinkedIn, Uber o PayPal. El valor era incalculable, pero Joyent tampoco supo transformar ese activo en una ventaja competitiva sostenible. Tener la mejor tecnología no bastó.

Mientras tanto, Amazon desplegaba una estrategia implacable, guiada por una filosofía simple de Jeff Bezos: “Your margin is my opportunity”. AWS reducía precios sin descanso, abría centros de datos en todo el mundo y gastaba miles de millones en construir una infraestructura global. Joyent intentaba seguir el ritmo, bajando precios también, pero era inútil: luchaba contra una empresa con recursos prácticamente infinitos. Y más allá del músculo financiero, Amazon entendió algo que Joyent nunca supo ver: la clave no estaba en la tecnología, sino en conquistar a los desarrolladores. AWS ofreció capas gratuitas para startups, documentación exhaustiva, conferencias globales como re:Invent y un ecosistema que se convirtió en la ventanilla única para todo lo que un programador pudiera necesitar. Joyent, en cambio, se quedó como un proveedor de élite, respetado, pero demasiado nicho como para escalar.

En 2010, “cloud” ya significaba AWS. Joyent había perdido la batalla por la mente de los clientes. El final era cuestión de tiempo. En 2016 Samsung la compró por apenas 125 millones de dólares. Para entender lo que eso significaba basta recordar que ese mismo año AWS ya estaba valorada en más de 100.000 millones. La compañía que había inventado los contenedores y poseía Node.js se vendió por poco más que calderilla.

La adquisición tampoco fue el principio de una nueva etapa. Más bien todo lo contrario. Bajo la gestión de Samsung, Joyent sobrevivió tres años más hasta que en 2019 cerró definitivamente su nube pública. La ironía fue cruel: la empresa que había alimentado los primeros años de Twitter, LinkedIn y Facebook acabó dedicándose a ayudar a sus clientes a migrar… a AWS.

Y, sin embargo, Joyent no desapareció del todo. Su ADN sigue vivo en cada aplicación construida en Node.js, en cada contenedor de Docker y en cada clúster de Kubernetes. Las tecnologías que salieron de Joyent han influido en más de un billón de dólares en valor de mercado. Mientras tanto, AWS vale hoy más de 100.000 millones, Docker llegó a alcanzar los 2.000 millones y el ecosistema Node.js genera miles de millones anuales. Joyent, en cambio, no capturó nada de ese valor.

La lección es dura pero clara. En tecnología, no importa ser el primero. Ni siquiera importa ser el mejor. Lo que de verdad importa es la escala, la distribución, la estrategia de precios y la construcción de un ecosistema. Joyent tuvo la tecnología para cambiar el mundo. Amazon tuvo todo lo demás.

La historia de Joyent es un recordatorio incómodo para cualquiera que trabaje en producto y tecnología. La innovación técnica por sí sola no basta. Puedes estar ocho años adelantado, construir sistemas más eficientes y ser admirado por los expertos, y aun así fracasar si no encuentras cómo hacer que esa innovación llegue a millones. Amazon lo entendió mejor que nadie: no se trataba solo de infraestructura, sino de comunidad, accesibilidad y distribución global.

Por eso hoy AWS es sinónimo de cloud, y Joyent apenas sobrevive en la memoria de quienes conocen la historia de la computación moderna. Un fantasma con un legado inmenso, presente en cada Node.js, en cada Docker y en cada Kubernetes, pero invisible en términos de valor capturado. La enseñanza, en definitiva, es brutal: en tecnología no gana quien inventa lo mejor, sino quien sabe cómo escalarlo, distribuirlo y convertirlo en plataforma global.

¿Cómo llegó hasta aquí la que fue la compañía más valiosa del mundo entre 2021 y 2023? La historia no empieza este año, sino en 2011, cuando Steve Jobs dejó el mando y entregó el timón a Tim Cook.

Dos visiones, dos modelos de éxito

Cuando se despidió, Jobs le dijo algo esencial a Cook: “No te preguntes qué haría Steve, solo haz lo correcto”. Y para Jobs lo correcto era claro: grandes productos generan grandes resultados financieros.

Cook, en cambio, apostó por la ruta opuesta. Jobs, en 2010, tenía 27.000 millones de dólares en efectivo y rechazó usarlos en dividendos o recompras de acciones. Su razonamiento era simple: “Nuestro objetivo es aumentar el valor de la empresa”. En su visión, ese valor provenía de la innovación.

Seis meses después de la muerte de Jobs, Cook lanzó lo que este se había negado a hacer durante 14 años: el primer programa de dividendos y recompra de acciones. El plan inicial era de 45.000 millones, pero Apple terminó gastando 80.000 millones.

No es casualidad que Warren Buffett, que siempre evitó invertir en tecnológicas, invirtiera 1.000 millones de dólares en el Apple de Cook. Nunca había puesto un centavo en el Apple de Jobs. El mensaje era claro: la empresa ya no era un templo de innovación, sino una máquina financiera.

El impacto en el diseño y la cultura

El cambio cultural fue brutal. Jobs visitaba el estudio de diseño cada día; Cook, apenas una vez al mes. Jonathan Ive, el genio detrás del iPhone, perdió poder frente al área financiera.

Cuando Ive pidió un desfile de moda de 25 millones de dólares para presentar el Apple Watch, Finanzas lo tachó de “innecesario”. Por primera vez, las ideas de diseño empezaron a enfrentarse a los ejecutivos financieros. Ive se desmotivó, empezó a trabajar desde casa y llegaba tarde. La innovación comenzaba a morir.

El reflejo en los productos

La falta de ambición se notó pronto. Los iPhone 6, 6s, 7 y 8 (2014-2017) eran prácticamente idénticos. El cambio no vino por innovación, sino por subidas de precio:

• Bajo Jobs, el iPhone costó 650 dólares durante 7 años.

• En 2017, Cook lanzó el iPhone X a 1.000 dólares, un 30% más caro.

• En 2023, el modelo más caro alcanzó los 1.200 dólares.

• Incluso el modelo “económico” subió un 40% en un solo año.

• Precio medio del iPhone: 657 dólares en 2016 → 974 dólares en 2024.

Cook encontró la gallina de los huevos de oro: subir precios. Pero esa estrategia tenía un límite.

El verdadero desastre: la IA

Apple fue pionera en asistentes de voz con Siri en 2011. Pero en 2017, Siri tenía solo un 62% de precisión, frente al 90% de Google Assistant. Y cuando ChatGPT salió en 2022, Apple estaba años atrás.

En 2023, el equipo de IA de Apple pidió 50.000 GPUs (unos 10.000 millones de dólares) para ponerse al día. Cook aprobó la inversión, pero el área financiera la bloqueó con un argumento demoledor: “Hagan los chips existentes más eficientes”.

Ese mismo año, Apple gastó 77.000 millones de dólares en recompras de acciones. Y en 2024, la cifra ascendió a 110.000 millones, liderando el mundo en esta práctica.

La comparación es dura:

• Amazon gastó 85.000 millones en I+D.

• Google, 45.000 millones.

• Meta, 39.000 millones.

El resultado es obvio: todos tienen mejor IA que Apple. Justo lo que Jobs temía.

La gran lección de Apple

La pérdida de 1,1 billones de dólares es la prueba más clara de que Steve Jobs tenía razón en algo:

👉 Cuando priorizas a los accionistas por encima de los productos, terminas perdiendo ambos.

Cook multiplicó por 10 la capitalización de Apple, sí. Pero a costa de erosionar el motor que la hizo única: la innovación. Hoy, una empresa que modernizó industrias enteras es incapaz de tener un asistente de voz competitivo.

Reflexión final

De esta historia hay dos aprendizajes clave para cualquier empresa o líder:

1. La orientación a producto no es opcional

   Una compañía tecnológica puede disfrazar durante un tiempo la falta de innovación con ingeniería financiera o subidas de precios, pero tarde o temprano el mercado ajusta cuentas. El único camino sostenible es poner el producto y al usuario en el centro.

2. Nunca olvides tu modelo de éxito

   Apple creció gracias a su obsesión por el diseño y la innovación disruptiva. Ese era su modelo de éxito. Cambiarlo por la lógica de recompensar accionistas fue minar su propio futuro. Toda empresa debería preguntarse: ¿qué nos hizo relevantes? ¿y cómo protegemos eso por encima de todo?

Porque la relevancia no se compra con recompras de acciones. Se gana, cada día, con productos que cambian la vida de las personas.