Investigación de Clientes
Jobs to Be Done: Construye lo que Necesitan
Entiende para qué contratan realmente tu producto los usuarios — y construye funcionalidades que cumplan esos trabajos.
TL;DR
- Las personas no compran productos — los contratan para realizar un trabajo.
- Un "trabajo" combina dimensiones funcionales, emocionales y sociales.
- Los job statements siguen: "Cuando [situación], quiero [motivación], para poder [resultado]."
- JTBD cambia el foco de la demografía a las circunstancias y el progreso deseado.
- SuperProduct te ayuda a conectar trabajos de usuario con funcionalidades y medir resultados.
Conceptos Clave
Entendiendo JTBD
El Trabajo
El progreso que un cliente intenta hacer en una circunstancia particular. No es una tarea o actividad, sino el objetivo subyacente.
Dimensión Funcional
La tarea práctica que el usuario quiere realizar — ej: "organizar las tareas de mi proyecto por prioridad."
Dimensión Emocional
Cómo quiere sentirse el usuario — ej: "sentirme seguro de que nada se me escapa."
Dimensión Social
Cómo quiere ser percibido el usuario — ej: "ser visto como organizado y al día por mi equipo."
Contratar y Despedir
Los usuarios "contratan" productos que cumplen sus trabajos y "despiden" los que no. Cada cambio es una decisión de contratación.
Soluciones Competidoras
Tu competencia no son solo productos similares — es cualquier cosa que el usuario hace para realizar el trabajo, incluyendo hojas de cálculo, post-its, o nada.
Job Statements
Cómo Escribir Job Statements
Un job statement bien elaborado captura la situación, motivación y resultado deseado. Usa este formato: "Cuando [situación], quiero [motivación], para poder [resultado]."
Seguir el progreso del equipo en OKRs
Situation
Cuando me preparo para una revisión trimestral
Motivation
Quiero ver progreso en tiempo real de todos los key results
Outcome
Para poder identificar goals desviados antes de que sea tarde
Priorizar las funcionalidades correctas
Situation
Cuando tengo más ideas que capacidad de ingeniería
Motivation
Quiero comparar funcionalidades por impacto esperado
Outcome
Para poder defender decisiones de roadmap ante stakeholders con confianza
Alinear producto e ingeniería
Situation
Cuando planifico el siguiente sprint
Motivation
Quiero una vista compartida de prioridades y dependencias
Outcome
Para poder reducir desalineación y esfuerzo desperdiciado
Comunicar la estrategia de producto
Situation
Cuando presento ante liderazgo
Motivation
Quiero una historia clara conectando goals con iniciativas
Outcome
Para poder obtener aprobación sin largos intercambios
Aplicación
Cómo Aplicar JTBD
Realiza entrevistas de cambio
Entrevista a clientes que recientemente empezaron o dejaron de usar tu producto. Pregunta sobre la línea de tiempo, detonantes y alternativas que consideraron.
Mapea el mapa del trabajo
Divide cada trabajo en etapas: definir, localizar, preparar, confirmar, ejecutar, monitorear, modificar, concluir. Encuentra puntos de dolor en cada etapa.
Identifica necesidades no cubiertas
¿Dónde están los usuarios sobre-servidos (pagando por funcionalidades innecesarias) o sub-servidos (luchando con soluciones alternativas)? Construye para trabajos sub-servidos.
Conecta trabajos con métricas
Cada trabajo debería mapearse a un resultado medible. Rastrea si tus funcionalidades realmente ayudan a los usuarios a progresar en sus trabajos.
Valida con experimentos
Antes de construir, ejecuta experimentos para confirmar que el trabajo es real y que tu solución propuesta realmente ayuda a los usuarios.
Organiza por trabajos, no por personas
En lugar de construir para "admin enterprise" o "fundador de startup", construye para el trabajo. Diferentes personas suelen compartir los mismos trabajos.
De trabajos a funcionalidades enviadas.
SuperProduct conecta necesidades de usuario con OKRs, mapas de impacto y funcionalidades — para que cada línea de código sirva a un trabajo real del cliente.
Preguntas Frecuentes
¿Quién creó el framework Jobs to Be Done?
JTBD tiene raíces en el trabajo de Clayton Christensen sobre innovación disruptiva y fue desarrollado por Tony Ulwick (Outcome-Driven Innovation) y Bob Moesta (entrevistas de cambio).
¿En qué se diferencia JTBD de las user stories?
Las user stories describen qué construir ("Como usuario, quiero X"). JTBD describe por qué los usuarios necesitan progreso ("Cuando [situación], quiero [motivación], para [resultado]"). JTBD va antes que las user stories.
¿Puede JTBD funcionar junto con personas?
Sí, pero JTBD sugiere que los trabajos son más estables que las personas. Múltiples personas pueden compartir el mismo trabajo, y una persona puede tener muchos trabajos.
¿Cuántos job statements debería tener?
La mayoría de los productos sirven 3-8 trabajos principales. Tener demasiados sugiere que necesitas estrechar tu enfoque o agrupar trabajos relacionados.
¿Cómo valido que identifiqué los trabajos correctos?
Realiza entrevistas de cambio con clientes recientes. Si sus historias mencionan consistentemente las mismas situaciones, motivaciones y resultados, has encontrado un trabajo real.
Construye para el trabajo, no para la funcionalidad.
SuperProduct te ayuda a conectar cada funcionalidad con una necesidad real del usuario — y medir si realmente la satisface.
Gratis para siempre. Sin tarjeta de crédito.