Jobs to Be Done
El marco fue desarrollado principalmente por Clayton Christensen (Competing Against Luck, 2016) y Tony Ulwick. La frase que encapsula el concepto es de Theodore Levitt: "Los clientes no quieren un taladro de un cuarto de pulgada; quieren un agujero de un cuarto de pulgada."
La metáfora del "contrato"
Cuando una persona "contrata" un producto, lo hace para que le ayude a completar un trabajo en un contexto específico. Ese trabajo tiene:
- Dimensión funcional: quiero que la transacción sea rápida.
- Dimensión emocional: quiero sentirme seguro.
- Dimensión social: quiero parecer organizado ante mi equipo.
Un mismo trabajo puede satisfacerse con soluciones muy diferentes: WhatsApp, el correo electrónico y una reunión presencial compiten por el mismo trabajo de "mantenerme coordinado con mi equipo".
La job story, el formato más usado
La plantilla más usada en equipos de producto para enunciar un trabajo es la job story:
Cuando [situación o contexto], quiero [motivación o objetivo], para [resultado esperado o beneficio].
La ideó Paul Adams en Intercom y le dio nombre Alan Klement en 2013. Conviene completarla con la alternativa con que la persona resuelve hoy ese trabajo, porque marca el listón que cualquier solución tiene que superar.
Ejemplo: "Cuando estoy revisando el sprint backlog antes de la planificación, quiero ver qué historias tienen criterios de aceptación incompletos, para no llegar a la reunión con trabajo que no podemos comprometer."
Dos escuelas
Bajo el nombre de JTBD conviven dos escuelas que no usan las mismas herramientas.
- La de Clayton Christensen y Bob Moesta entiende el trabajo como el progreso que una persona intenta hacer en una circunstancia concreta y lo explora reconstruyendo cómo llegó a cambiar de solución.
- La de Tony Ulwick, con su método Outcome-Driven Innovation (ODI), formula el trabajo como un verbo con su objeto y mide los resultados que el cliente desea. La plantilla de la job story pertenece a la primera tradición.
JTBD en el product discovery
En el product discovery, JTBD es la herramienta para enmarcar el problema correctamente:
- Ayuda a separar el síntoma (lo que el usuario pide) de la causa raíz (el trabajo que necesita hacer).
- Abre el espacio de soluciones: una vez definido el trabajo, múltiples soluciones pueden abordarlo.
- Permite comparar competidores en términos de qué trabajo resuelven, no de qué funcionalidades tienen.
Error frecuente
Redactar un JTBD que ya prescribe la solución. "Cuando reviso el backlog, quiero un filtro por estado de criterios de aceptación" no es un JTBD: es un requisito técnico disfrazado de trabajo. El trabajo debe describir la motivación sin imponer la implementación. Si la formulación ya especifica cómo resolverse, se pierde la oportunidad de explorar alternativas mejores.
Recursos
🏦 Skill Design ThinkingState of the art y guía de desarrollo · Skill Arena
🏦 Descubrimiento de producto y validación con clientesState of the art y guía de desarrollo · Skill Arena
Referencias
- Christensen, Clayton M.; Hall, Taddy; Dillon, Karen; Duncan, David S. (2016). Competing Against Luck: The Story of Innovation and Customer Choice. Harper Business.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.