Jobs to Be Done
Entender qué intentan lograr los usuarios (no qué característica quieren) revela oportunidades de diseño que otros pierden.
¿Qué es Jobs to Be Done?
Jobs to Be Done (JTBD) es un marco para entender la motivación del usuario. En lugar de preguntar “¿qué quieren los usuarios en un producto?”, JTBD pregunta “¿qué intenta lograr el usuario?”
Un cliente no está comprando un taladro. Está comprando la capacidad de hacer un agujero. Un cliente no está comprando una aplicación de citas. Está intentando conocer a alguien. Un cliente no está comprando una herramienta de gestión de proyectos. Está intentando organizar el trabajo de su equipo.
El “trabajo” es el resultado que el usuario quiere. Un producto bien diseñado hace el trabajo más fácil. Un producto mal diseñado hace el trabajo más difícil, incluso si las características son impresionantes.
Una frase contundente: Las personas no quieren tu producto; quieren lograr algo, y tu producto es un medio para ese fin.
¿Por qué es importante?
- Revela Verdadera Motivación: Las características son visibles. La motivación está oculta. JTBD expone motivación. ¿Por qué los usuarios usan tu competidor? ¿Qué trabajo están logrando?
- Descubre Necesidades No Satisfechas: La mayoría de solicitudes de usuario son solicitudes de características. JTBD ignora solicitudes de características y pregunta “¿qué resultado quiere el usuario?” Emergen necesidades no satisfechas.
- Guía Roadmap de Producto: Cuando entiendes el trabajo, las prioridades de roadmap se aclaran. Las características que aceleran el trabajo tienen mayor rango que las que no lo hacen.
- Diferencia Productos: Los competidores ofrecen características similares. JTBD revela que los usuarios se preocupan por el resultado, no la característica. Un producto que entrega el resultado más rápido gana.
La Entrevista JTBD
Conducir una entrevista JTBD requiere preguntas específicas:
- Trigger — “Cuéntame sobre la última vez que [encontraste situación]. ¿Qué te impulsó?”
- Situación — “Camina conmigo a través de lo que intentabas lograr. ¿Cuál era el contexto?”
- Obstáculos — “¿Qué se interpuso? ¿Qué fue difícil?”
- Solución Actual — “¿Cómo lo resolviste? ¿Qué usaste?”
- Satisfacción — “Mirando hacia atrás, ¿estás feliz con cómo lo resolviste? ¿Qué lo haría mejor?”
- Alternativas Consideradas — “¿Qué más consideraste? ¿Por qué no elegiste eso?”
La entrevista sigue una narrativa. Deja que el usuario cuente su historia. No interrumpas. El trabajo emerge de la historia.
Trabajos en Competencia
Los usuarios no eligen tu producto en el vacío. Lo comparan con alternativas:
- Usar un competidor
- Usar un workaround manual
- No hacer nada (status quo)
JTBD pregunta: “¿Por qué el usuario cambió a tu producto? ¿Qué trabajo no estaban logrando con el status quo?”
Consejos de Mentor
- Primer consejo: Las entrevistas JTBD son conversacionales, no encuestas. Necesitas escuchar la historia. ¿Por qué lo usaron? ¿Qué llevó a este momento? Una encuesta preguntando “¿qué trabajo intentas hacer?” no funcionará. Déjalos contar la historia.
- Enfócate en ocasiones específicas, no comportamiento general. “Cuéntame sobre la última vez…” no “¿Cómo típicamente…?” Los eventos específicos recientes son más precisos que hábitos generalizados.
- Escucha decepción. Cuando los usuarios describen cambiar a tu competidor, escucha la decepción. ¿Qué no estaba funcionando? Ese es el trabajo que intentaban lograr.
- Separa wants de needs. Los usuarios dicen “Quiero mejor UI.” Eso es un want. La necesidad subyacente es “Quiero lograr mi tarea más rápido.” Diseña para necesidades, no wants.
Recursos y Herramientas
- Libros: “Competing Against Luck” de Clayton Christensen, “Jobs to Be Done” de Anthony Ulwick
- Herramientas: Miro para mapear trabajos, grabación de entrevistas con servicios de transcripción, Notion para documentación
- Artículos: Marco JTBD en el sitio de Clayton Christensen, entrevistas en UX Collective