Escribe el trabajo que el usuario quiere resolver en formato "cuando… quiero… para…", y revisa que no estés colando una solución dentro del enunciado.
Para qué sirve
Jobs to be Done cambia el sujeto: en vez de describir a un usuario arquetípico, describe la situación en que aparece una necesidad. La estructura es simple —cuando ocurre esto, quiero hacer aquello, para lograr esto otro— y su virtud es que obliga a nombrar el contexto.
Cómo se usa
- Situación: el momento concreto en que aparece la necesidad.
- Motivación: qué quiere hacer la persona en ese momento.
- Resultado esperado: para qué, qué cambia en su vida si lo logra.
- Revisa las advertencias: si aparecen palabras como botón, pantalla o app, metiste la solución.
Cuándo usarla
- Tus historias de usuario describen interfaces en vez de necesidades.
- Trabajas con un producto usado en contextos muy distintos.
- Quieres escribir requisitos sin condicionar el diseño.
El error más común
Colar la solución en la motivación. "Cuando entro, quiero ver un dashboard" no es un job: es un diseño ya decidido con otro formato.
Preguntas frecuentes
¿Diferencia con una historia de usuario?
La historia de usuario parte del rol ("como administrador…"); la job story parte de la situación ("cuando se cae el servicio a medianoche…").
Otras herramientas de descubrimiento
¿Quieres aplicar esto a tu negocio?
Estas herramientas son las mismas que usamos en los proyectos. Si prefieres que lo hagamos contigo, conversemos una hora: salimos con las prioridades claras.