Jobs to Be Done: qué significa realmente y cómo usarlo
Jobs to Be Done es uno de esos frameworks que todos en producto escucharon y casi nadie usa correctamente. La mayoría de los resúmenes que vas a encontrar abren con la historia del milkshake de Clayton Christensen, explican que los clientes "contratan" productos para hacer trabajos, y ahí se quedan. Es una metáfora limpia. También deja afuera la parte que realmente cambia cómo trabajás.
La versión útil de JTBD no es una metáfora. Es una forma específica de reestructurar las conversaciones con clientes, una unidad de análisis distinta para pensar la competencia, y una lente más filosa para decidir qué construir después. Internalizarlo tiene menos que ver con entender una teoría y más con aprender a hacer una pregunta diferente.
¿Querés correr tu idea por un discovery con lógica JTBD? Probala con Scoutr →
La idea central, sin el milkshake
La premisa es directa: cuando alguien usa un producto, no está expresando lealtad a la categoría de producto. Está tratando de hacer un trabajo específico. El producto es la herramienta que casualmente contrató para ese trabajo. Si aparece algo que hace el trabajo mejor, va a cambiar.
Eso suena obvio. Lo que hace útil a JTBD es la implicación operativa: tenés que dejar de pensar en tu cliente en términos de demografía, personas o categorías de producto, y empezar a pensarlos en términos del trabajo que están tratando de hacer en el momento en que deciden usar algo.
La misma persona va a contratar productos completamente diferentes para trabajos diferentes. Un padre ocupado contrata una cafetería a las 7am ("ayudame a despertarme rápido camino al trabajo") y contrata la misma cafetería a las 3pm ("dame una excusa para levantarme del escritorio por quince minutos"). Mismo cliente. Misma ubicación. Trabajos distintos. Las features que importan son distintas en cada caso.
Este replanteo es por qué JTBD es difícil de usar bien. Te pide abandonar categorías que se sienten naturales y reemplazarlas por algo menos tangible — pero más predictivo.
Por qué la historia del milkshake es una trampa
La historia, brevemente: McDonald's estudió quién compraba milkshakes a la mañana y encontró que no eran familias ni adolescentes. Eran personas yendo al trabajo, a menudo hombres, comprando milkshakes como desayuno durante el trayecto. El shake no competía con otros postres. Competía con bananas, bagels y donuts — cosas que podés comer con una mano en el tráfico. Una vez que McDonald's entendió ese trabajo, pudieron hacer el shake más espeso (tarda más en tomarse, llena todo el trayecto) y vendieron más.
La historia es memorable. Pero también es un poco engañosa sobre cómo JTBD realmente ayuda, porque implica que solo necesitás mejor investigación observacional. En la práctica, JTBD no es principalmente sobre observar patrones de uso. Es sobre hacer mejores preguntas en las entrevistas.
El insight del milkshake podría haber venido de ver el comportamiento en el drive-through. Pero la mayoría de los insights de JTBD vienen de preguntarle a alguien por qué compró lo que compró, y qué habría comprado si lo que compró no existiera. Esas dos preguntas hacen más trabajo que cualquier estudio observacional.
Las tres dimensiones de un trabajo
Un job statement útil tiene tres dimensiones, y ninguna debería mencionar tu categoría de producto.
Dimensión funcional. ¿Qué cosa práctica están tratando de lograr? "Atravesar el trayecto matutino sin pasar hambre". "Hacer seguimiento al progreso del proyecto sin mandar un email de update". "Saber si este candidato es técnicamente competente".
Dimensión emocional. ¿Cómo quieren sentirse? ¿O qué sentimiento quieren evitar? "Sentirme en control de mi agenda". "Evitar parecer tonto frente a mi equipo". "Sentir que tomé una decisión reflexiva".
Dimensión social. ¿Cómo quieren ser percibidos? Esto importa más de lo que la gente admite. "Que me vean como alguien organizado". "Que me vean como alguien que hizo due diligence". "Que no me vean como la persona que frenó el proyecto".
La mayoría de los productos se enfoca exclusivamente en la dimensión funcional. Los que ganan — y a los que los usuarios se mantienen leales — abordan las tres, a menudo sin que el usuario lo note conscientemente. La dimensión social en particular es donde viven muchas compras B2B: el miedo del comprador a que lo culpen si la herramienta no funciona suele ser la fuerza dominante en la decisión.
Cómo JTBD cambia las entrevistas con clientes
Lo más útil que hace JTBD es cambiar las preguntas que hacés en investigación con clientes.
La mayoría de los frameworks de entrevista empiezan con "¿quién sos?" — demografía, rol, tamaño del equipo, contexto. JTBD empieza con "¿qué estabas tratando de hacer?". La primera pregunta recolecta atributos. La segunda recolecta una situación específica, que es donde vive toda la información útil.
Compará dos versiones de la misma entrevista:
Basada en personas: "Sos marketing manager en una empresa mediana. Contame sobre tu flujo diario con herramientas de analytics."
Basada en JTBD: "Llevame a la última vez que trataste de responder una pregunta específica usando una herramienta de analytics. ¿Qué estabas tratando de averiguar? ¿Qué hiciste primero? ¿Dónde te trabaste?"
La primera versión produce un resumen prolijo que podría aplicar a cualquier marketing manager. La segunda versión produce un relato específico sobre un momento, que es donde viven las decisiones de diseño. Lo que hicieron primero te dice sobre su modelo mental. Dónde se trabaron te dice sobre el gap en las herramientas actuales. Por qué empezaron a buscar te dice sobre el evento disparador que los hizo estar dispuestos a pagar.
Por esto JTBD se empareja naturalmente con el Mom Test — ambos frameworks te alejan de preguntas genéricas y te acercan a preguntas específicas, en pasado, basadas en situaciones.
Cómo escribir un job statement
Un job statement limpio tiene esta forma: Cuando [situación], quiero [motivación], para [resultado esperado].
Malo: "Quiero ser más productivo".
Mejor: "Cuando estoy empezando un proyecto nuevo y no sé por dónde empezar, quiero ver cómo abordaron otros equipos proyectos similares, para evitar errores obvios y sentirme seguro sobre mis primeras decisiones".
La segunda versión es un trabajo real. Tiene un disparador (empezar un proyecto nuevo), una motivación (ver cómo lo abordaron otros) y un resultado que incluye dimensiones funcionales (evitar errores) y emocionales (sentirme seguro).
Cuando escribís job statements para tu usuario objetivo, los statements deberían ser lo suficientemente específicos como para que pudieras identificar el momento en que el trabajo se activa. "Quiero ser productivo" no tiene momento. "Cuando estoy empezando un proyecto nuevo y me siento paralizado por la página en blanco" tiene un momento que podés apuntar con un producto, un mensaje, una notificación.
Si tus job statements son vagos, tu producto va a ser vago. Si son específicos, tu producto tiene una razón clara para existir.
La pregunta sobre competencia que JTBD responde
Preguntar "¿quiénes son nuestros competidores?" en términos de categoría de producto casi siempre te confunde. JTBD replantea la competencia: tus competidores reales son lo que el usuario haría en su lugar si tu producto no existiera. Eso puede ser un competidor en tu categoría. También puede ser una hoja de cálculo. Un mensaje de Slack a un colega. No hacer nada. Pagarle a alguien para que lo haga manualmente.
El competidor de Figma no es solo Sketch. Son slides de PowerPoint haciéndose pasar por mockups, screenshots anotadas en Preview, y diseñadores mandándose PDFs por email. Cuando entendés eso, entendés por qué el roadmap de Figma se ve como se ve — está diseñado para reemplazar esos workarounds, no solo para ganarle a Sketch en features.
Por esto también "nadie está haciendo esto" rara vez es una señal verde para founders. Si no existe un producto para un trabajo, los usuarios casi con certeza están haciendo el trabajo con algo — un workaround, un proceso manual, una combinación de herramientas. Ese workaround es tu competidor real. Entenderlo lo suficiente como para ganarle suele ser el trabajo real. Es el mismo patrón que señales de demanda desde workarounds: el workaround es el mercado diciéndote cómo se ve el trabajo desde adentro.
Cuándo JTBD no funciona
JTBD es excelente para productos que resuelven trabajos identificables y discretos. Funciona menos bien para productos donde el trabajo es ambiental, de baja intención o principalmente estético.
Los productos de entretenimiento son los más difíciles. El trabajo "entretenerme por veinte minutos" es tan amplio que JTBD no te ayuda a tomar decisiones de diseño como lo haría para una herramienta de productividad. De forma similar, productos impulsados por gusto, identidad o comunidad — moda, ciertas marcas de consumo, redes sociales — tienen trabajos que son reales pero difíciles de fijar en un statement.
Para la mayoría de software B2B, herramientas de productividad, utilidades y servicios, JTBD es tan útil como cualquier framework existente. Para productos de consumo en categorías impulsadas por emoción e identidad, es un suplemento útil, no una lente primaria.
Usar JTBD junto con el resto de tu trabajo de discovery
JTBD es una herramienta afilada para una parte del discovery: entender qué está tratando de lograr el usuario. No es un framework completo. Todavía necesitás validar que el trabajo es común, que es lo suficientemente doloroso como para que la gente pague por resolverlo, y que tu solución específica es mejor que los workarounds que están usando actualmente.
Un proceso de validación estructurado corre JTBD como una de varias lentes. Identificás el trabajo (JTBD), confirmás el workaround (señales de demanda), confirmás disposición a pagar (willingness to pay), y evaluás si podés alcanzar a suficientes usuarios a un precio que tenga sentido. El framework de discovery de seis preguntas teje todo eso junto.
Lo que JTBD aporta específicamente es que dejás de construir para una persona abstracta y empezás a construir para un momento en el día de alguien en que necesita que algo pase. Eso es un objetivo de diseño mucho más útil que "nuestro usuario objetivo es marketing manager en una empresa mediana".
Si querés una forma estructurada de descubrir el trabajo para el que tu idea está siendo contratada — incluyendo el mapeo JTBD y los workarounds competitivos que ya están sirviendo ese trabajo — Scoutr corre eso como parte de su análisis de discovery. El resultado es un job statement claro, las alternativas actuales que los usuarios contratan para ese trabajo, y una lectura sobre si tu solución representa una mejora significativa. No va a reemplazar las entrevistas. Pero te da un mapa inicial antes de agendarlas.