User Story Map, gobernar la IA con una buena definición
La sesión en la que, antes de tocar ninguna IA, definimos producto a la antigua usanza: cada equipo eligió una idea (calculadora de barbacoas, automatizar tareas de pymes, alimentos de km 0), definió sus buyer persona, montó la espina dorsal de actividades y acciones, escribió historias de usuario con sus criterios de aceptación y trazó la línea del MVP. Todo en un Miro compartido. La próxima clase: convertir el mapa en prototipo.
Antes de bucear en los recursos, comprueba qué se te ha quedado: recordar de forma activa fija mucho más que releer. No hay nota ni castigo, y si fallas te explico el porqué.
Repaso · Pregunta 1/5
"Configurar el evento" y "elegir la fecha de la barbacoa", ¿qué son en el mapa?
Las dos son historias de usuario.
Configurar el evento es una actividad (bloque grande) y elegir la fecha es una acción (concreta, verbo en infinitivo) que vive dentro de ella.(respuesta)
Las dos son actividades del mismo nivel.
Las actividades son los grandes bloques de la espina dorsal (registro, configuración, invitar, gestión); las acciones son cosas concretas que suelen empezar con verbo en infinitivo (elegir la fecha, seleccionar contactos, repartir tareas). La frontera es debatible y es normal que al principio salgan mezcladas: el propio diálogo para distinguirlas ya genera entendimiento compartido.
Llevas 10 minutos con una historia de usuario y no te sale el "Para". ¿Qué te está diciendo eso?
Que hay que escribirla en Gherkin, que es más fácil.
Que necesitas más tiempo: el propósito siempre acaba saliendo.
Que probablemente esa funcionalidad sobra: si no tiene propósito, no hay que construirla.(respuesta)
El Para es la parte más difícil y la más importante: dota de propósito a la funcionalidad y permite validarla después con datos. Si no eres capaz de responder para qué sirve, muy probablemente no es algo que haya que hacer. Vomitar funcionalidades sin validar el propósito es el error histórico número uno.
Si es tan fácil pedirle a la IA que "cree la app de barbacoas", ¿para qué el buyer persona y el mapa?
Por tradición; con IA ya no hacen falta.
Para gobernar la IA: le das definición y ejecuta el acuerdo del equipo, en vez de dejar que rellene huecos e invente lo que no le dijiste.(respuesta)
Solo para justificar las horas de la sesión.
La IA es tan buena que nos sorprende, pero cuando no la gobiernas rellena los huecos: se inventa emails, URLs de LinkedIn, funcionalidades. Definir usuario, mapa, historias y criterios es precisamente la manera de coger las riendas: el prototipo sale de vuestro acuerdo, no de su imaginación.
¿Cuál de estas historias de usuario está bien planteada?
"Como base de datos, quiero recibir una query para devolver los invitados en JSON."
"Como organizador de una chuletada, quiero saber los gastos a compartir entre los asistentes, para garantizar que me pagan a tiempo."(respuesta)
"Como negocio, queremos maximizar la comisión sobre la venta de carne."
El rol siempre es una persona con una necesidad, no una base de datos ni un KPI. La gracia de la historia de usuario es que tu madre la entienda y el equipo técnico también: todos debatiendo en el mismo plano. Ni jerga técnica (query, JSON) ni jerga de negocio (comisión, EBITDA).
Ya está el mapa montado. ¿Qué es la línea horizontal que lo cruza?
Separa las actividades de las acciones.
Separa el MVP (lo mínimo para lanzar sintiéndote cómodo) de las siguientes releases. Lo de abajo no se pierde: se baja, espera su turno.(respuesta)
Separa lo que hace el equipo técnico de lo que hace producto.
La línea se traza debatiendo historia a historia: ¿es esencial para lanzar? Encima queda el producto mínimo viable (tu roadmap inmediato); debajo, las siguientes releases. En clase decidimos que "compartir gastos" podía quedar fuera de la primera versión: primero validamos si la gente usa la app para organizar quién trae qué.
01
Gobernar la IA con una buena definición
~4 min
La IA es tan buena que nos sorprende, y también nos defrauda, porque no la estamos
gobernando. En la clase anterior vimos cómo rellenaba los huecos: si no le
dabas la información adecuada, se inventaba emails y URLs de LinkedIn. Hoy hicimos lo
contrario: definir producto a la antigua usanza para después usar la IA con
las riendas puestas. Y esa base sigue siendo la misma que antes de toda esta tecnología.
Por qué importa
Hoy construir es facilísimo y baratísimo: vomitar código, generar cosas, cuesta nada. Otra
cosa es construir con calidad y construir lo que el usuario
necesita. Muchos productos se perjudican generando funcionalidades sin validar
siquiera la esencia del propio producto. El User Story Map de Jeff Patton
existe para atacar las tres problemáticas de siempre cuando un equipo va a crear algo
digital:
Las tres problemáticas de siempre
01Entendimiento compartido
Que "la app tiene que comunicar a los invitados" signifique lo mismo para todo el equipo. Uno piensa en un chat, otro en un correo, otro en una videollamada, y quien desarrolla elige uno: sorpresa asegurada. Es el 80% de la entropía en cualquier organización.
02Priorizar
Separar lo urgente de lo importante, y de lo necesario. Un criterio útil: el coste del retraso. Cada minuto que la incidencia impide comprar a tus clientes, ¿cuánto dinero pierdes?
03Definir el MVP
Separar tu ego de profesional del producto. No perfecto: lo mejor posible para salir y validar sin dañar tu reputación. Es lo más difícil de todo el ejercicio.
El Tinder de mascotas (o por qué no basta con 'tener la idea')
"Nos piden crear el Tinder de mascotas." ¿Qué es? ¿Qué funcionalidades tiene? ¿Cómo hace
login el usuario, qué flujo sigue desde que se descarga la app hasta que sale de ella?
Responder a eso en un documento de 40 páginas no genera acuerdo: genera un documento que
nadie lee. El mapa pone esas mismas preguntas en la pared, con el usuario en el centro, y el
acuerdo se construye pegando post-its y debatiendo en el mismo plano.
En la vida real esta dinámica dura de uno a tres días, hasta una semana: antes de invertir
dos millones en construir algo, tómate al menos un par de semanas en definirlo.
02
De la idea al reto de acotarla
~3 min
Para arrancar hace falta una semilla: una idea. Cada uno propuso la suya en un post-it
(calculadora de barbacoas, app de tareas de administración para pymes, alimentos de granja a
la mesa, fitness con entrenadores virtuales, diagnóstico médico con IA...) y cada equipo
eligió una para trabajarla toda la tarde. Lo más difícil no fue tener ideas: fue ponerse de acuerdo y, sobre todo, acotar. Como se repitió en cada sala:
no puedes hacer algo "para todo el mundo".
Los tres casos de la sesión: el equipo Alfa cogió la calculadora de barbacoas
(o chuletada, o asadero, según la isla); el Bravo, una app para automatizar tareas de
administración de pymes; el Charlie, la entrega de alimentos de granja a mesa, kilómetro cero.
Tres líneas de negocio distintas, el mismo método para definirlas.
03
Conoce a tu usuario: cuatro preguntas
~6 min
Antes de hablar de funcionalidades, hay que saber para quién construimos. No hace falta un
buyer persona de manual: bastan cuatro preguntas. Quién es (datos
demográficos), qué desea, qué necesidad le resolvemos y cómo prefiere interactuar. Esta última se olvida siempre y condiciona la
arquitectura entera: he visto equipos construir una app de realidad aumentada para un
usuario que no puede pagar las gafas, o una app de botones para personas mayores que
preferían la voz.
El organizador
Monta la chuletada en su casa. Es quien más cosas hace en la app: el camino más desfavorable, el que conviene mapear primero.
Desea: montar la barbacoa sin cargar él solo con todo
Necesita: invitar, recoger preferencias, repartir tareas y dimensionar la compra
Interactúa: app móvil, deprisa y desde el sofá
El invitado
Recibe la invitación. Su journey es distinto: no crea nada, responde y colabora (o se escaquea).
Desea: enterarse de dónde, cuándo y qué se come
Necesita: confirmar, decir sus preferencias y coger alguna tarea
Interactúa: un enlace que abre la app; nada de rellenar formularios largos
El proveedor de carne
No es usuario intenso, pero sí grupo de interés: por él aparece la monetización (comisión sobre la venta).
Desea: vender más carne y carbón sin montar una tienda
Necesita: publicar stock y recibir pedidos dimensionados por la app
Interactúa: panel de escritorio; el reparto lo hace su negocio
Por qué importa
Fíjate en el proveedor de carne: no toca la app a diario, pero es un grupo
de interés que a lo mejor sostiene el modelo de negocio (comisión sobre la venta). Y no hay
que resolver todas las necesidades de todos los persona: con dos o tres arquetipos bien
elegidos evitas la parálisis por análisis. Tener a "el organizador" con nombre y cara
delante te deja debatir con datos en lugar de con opiniones.
04
Actividades y acciones: la espina dorsal
~6 min
El esqueleto del mapa es el flujo del usuario de punta a punta: desde que
descarga la aplicación hasta que tiene la barbacoa en su casa. Ese flujo se construye con
dos niveles, y pasar de lo general a lo concreto es exactamente el objetivo del mapa:
Actividades
Los bloques grandes
Lo que responderías si alguien pregunta "¿qué tiene tu aplicación?": registro,
configuración del evento, invitar, confirmación, gestión.
Cada actividad agrupa acciones. "Trabajamos la configuración del evento" significa
trabajar todo lo que cuelga de esa columna.
Acciones
Lo concreto, en infinitivo
Cosas específicas que suelen empezar con verbo en infinitivo: elegir la fecha,
seleccionar contactos, compartir el enlace, confirmar asistencia, repartir tareas.
¿Esto es actividad o acción? Ese debate es normal, no hay un método exacto: el propio
diálogo para decidirlo ya está generando entendimiento compartido.
Por qué importa
En el caso de la barbacoa, del caos de post-its salió el flujo del organizador: registro y
perfil, configurar el evento (fecha, sitio, número de personas, rango de precio), invitar y
compartir el enlace, confirmación por cuestionario (qué come cada uno) y gestión (reparto de
tareas y lista de la compra). El mapa no tiene por qué ser secuencial: hay actividades
paralelas. Y ojo con el actor olvidado: sin el proveedor no hay carne, y sin carne no hay
producto.
05
Historias de usuario: Como, Quiero, Para
~7 min
Para bajar el mapa a funcionalidades usamos la convención que técnica y negocio hemos
pactado: la historia de usuario. Tres palabras: Como (un
rol, siempre una persona), Quiero (la necesidad) y Para (el propósito). Una acción puede dar pie a varias historias de usuario.
La historia de los gastos compartidos
"Como organizador de una chuletada, quiero saber los gastos a compartir entre los
asistentes, para garantizar que me pagan a tiempo."
Con esa frase tu madre entiende qué vamos a construir, y el equipo técnico también.
Compárala con "una query que cruza la tabla de asistentes con el stock de carne" (tu madre
fuera) o con "aumentar la comisión de intermediación un 300%" (todos fuera). La historia de
usuario pone a todo el mundo a debatir en el mismo plano.
Nada de "como base de datos, quiero recibir una query": el rol es una persona. Es quien
tiene la necesidad.
El Para es el filtro: es la parte que más cuesta y la más importante. Si no
consigues escribir el propósito de una funcionalidad, probablemente esa funcionalidad no hay
que hacerla. "Quiero un registro de cuántos pasos dio cada invitado a la barbacoa... ¿para?"
Exacto: fuera.
06
Criterios de aceptación: natural o Gherkin
~6 min
Si solo das el Como-Quiero-Para, el equipo (o la IA) decide libremente el cómo. Cuando hay
requisitos que deben cumplirse sí o sí (branding, tiempos de respuesta, reglas de negocio),
se explicitan como criterios de aceptación. Son los mínimos: si la
funcionalidad no los cumple, no se acepta.
Lenguaje natural
Escribes la regla y listo. La mayoría de product managers lo hacen así, y es perfectamente válido.
El organizador dividirá la cuenta en porcentajes proporcionales por defecto
Podrá cambiar algún porcentaje y se recalcularán los demás
El total de porcentajes siempre debe sumar 100%
Gherkin: Dado / Cuando / Entonces
El mismo criterio como flujo estructurado. La ventaja: se puede testear y hasta generar tests automáticos.
DADO un organizador en la pantalla de división de cuentas
CUANDO modifique el porcentaje de uno de los asistentes
ENTONCES la app recalcula proporcionalmente el resto de invitados
Por qué importa
Gherkin viene del ecosistema de testing (Cucumber) y es la versión sofisticada; el lenguaje
natural es igual de válido. El Dado-Cuando-Entonces sirve para tres cosas: que un QA sepa
exactamente qué pasos probar, que la IA genere tests que garanticen que la funcionalidad no
se rompe en el futuro, y que una IA de diseño de interfaces (como Google Stitch) entienda el
flujo que tiene que dibujar. Es verboso, pero acota lo que hace la IA.
07
La línea del MVP: el mapa es el roadmap
~4 min
Último movimiento: cada historia se hace pequeñita y se cuelga debajo de la
actividad y acción que le corresponde. Con el mapa ordenado, se traza una línea
horizontal debatiendo historia a historia: ¿es esencial para lanzar? Encima queda el MVP: lo mínimo que necesitas para salir al mercado sintiéndote cómodo.
Debajo, las siguientes releases: nada se pierde, solo se baja y ocupa otro
lugar en la prioridad.
Pensamiento crítico, siempre: hoy es fácil sacar a producción algo prototipado
esa misma mañana. Perfecto para un e-commerce donde iteras rápido; muy peligroso para un
software médico que da diagnósticos. No hay fórmula única: el rol de producto es decidir cuánto
validar antes de lanzar. En clase dejamos "compartir gastos" fuera de la primera versión para
validar antes la hipótesis básica.
08
Del mapa al prototipo con IA
~5 min
El cierre moderno de la sesión: con la idea, los persona y el mapa definidos, la IA deja de
improvisar y ejecuta lo que el equipo ya acordó. El regalo de la clase es este prompt para convertir cualquier actividad o acción en una historia de usuario
completa (con título, Como-Quiero-Para, aspectos funcionales y criterios de
aceptación en Gherkin). Es más fácil corregir que escribir: pégalo, revisa lo que devuelve y
quita lo que no aplique.
El prompt de la clase · pégalo en ChatGPT, Claude, DeepSeek o la IA que uses
Crea una historia de usuario en base a:
XXXX (pega aquí la actividad/acción o la idea de funcionalidad)
PLANTILLA:
## TÍTULO: algo corto y representativo
## HISTORIA DE USUARIO
COMO
QUIERO
PARA
## ASPECTOS FUNCIONALES
## CRITERIOS DE ACEPTACIÓN
DADO un usuario que quiere entrar en la web
CUANDO haga click en el botón
ENTONCES tendrá que mostrar un pop-up
Dámelo en un codeblock
Por qué importa
Hay dos maneras de usar la IA: dejar que invente (las riendas las tiene ella, y te
"sorprende") o darle definición y que ejecute. Todo lo que hicimos en la
sesión (elegir la idea, definir personas, mapear, escribir historias, acotar con criterios)
es la manera de domar a la IA: el resultado sale de vuestro acuerdo, no de su imaginación.
Hace un año esta parte de la clase no existía; el estado del arte manda.
Recursos
WebMiro · la pizarra virtual de la sesión: post-its, ideación y el mapa colaborativo. Seguís teniendo acceso a la pizarra de clase para repasar.
WebGoogle Stitch · IA de diseño de interfaces: con la historia de usuario y el flujo Gherkin puede proponerte el diseño de las pantallas.
La técnica se aprende facilitándola. Marca lo que vayas completando; se guarda en tu navegador. La próxima clase construimos el prototipo.
0/8 completado
Glosario · toca para ampliar
User Story Map
Técnica de gestión visual de Jeff Patton: mapear el flujo del usuario en actividades y acciones, colgar debajo las historias de usuario y trazar la línea del MVP. El mapa es el roadmap visual del producto, y se puede revisitar cuando entra alguien nuevo al equipo.
Arquetipo de tu usuario construido con 4 preguntas: quién es, qué desea, qué necesidad le resolvemos y cómo prefiere interactuar. Representa a un conjunto de usuarios, no a una sola persona real. Condiciona hasta la arquitectura del producto.
Convención para definir una funcionalidad sin jerga técnica ni de negocio: Como [persona], Quiero [necesidad], Para [propósito]. Si tu madre no la entiende, está mal escrita.
Las condiciones que deben cumplirse sí o sí para dar por buena una historia de usuario: límites, reglas de negocio, requisitos de branding o experiencia. En lenguaje natural o en Gherkin.
Formato estructurado para criterios de aceptación: Dado [contexto], Cuando [evento], Entonces [resultado]. Permite testear y generar tests automáticos: si el flujo no se cumple, la funcionalidad no está terminada.
Producto mínimo viable: la versión con lo mínimo para salir al mercado y validar una hipótesis, sin esperar al roadmap completo. En el mapa, todo lo que queda por encima de la línea.
La hoja de ruta del producto. En el User Story Map no es un documento aparte: lo que queda por encima de la línea del MVP es tu roadmap, visual y debatido por todo el equipo.
Si te llevaras únicamente dos cosas de toda esta página, que sean éstas:
El Para es el filtro: una historia de usuario sin propósito
es una funcionalidad que sobra. Como [persona], Quiero [necesidad], Para [propósito], y el
rol siempre es una persona, nunca una base de datos ni un KPI.
Define antes de construir para gobernar la IA: idea acotada,
personas con las 4 preguntas, espina dorsal, historias y línea del MVP. Con eso, el prompt de la clase convierte la definición en historias de usuario
completas y, la próxima sesión, en un prototipo navegable. La IA ejecuta tu acuerdo, no su
imaginación.
Para cualquier duda, pueden escribirme a hi@alci.dev o por
LinkedIn. Y la pizarra de Miro de la sesión sigue disponible para repasar.