Una keyword muestra qué escribió alguien. No explica, por sí sola, qué cambió en su situación, qué progreso busca, qué alternativas considera ni qué riesgo percibe al cambiar. Esa diferencia es el punto de partida de Jobs to Be Done (JTBD): investigar la demanda más allá de la consulta, del perfil demográfico y de las características del producto.
JTBD no es una plantilla para reemplazar buyer personas, mapas de empatía o análisis de intención de búsqueda. Es una forma de reconstruir por qué una persona incorpora —o “contrata”— una solución en una circunstancia concreta. Cuando esa evidencia se trabaja bien, permite coordinar decisiones de producto, marketing y contenidos sin confundir señales con certezas.
Qué es Jobs to Be Done y cuál es su unidad de análisis
Jobs to Be Done estudia el progreso que una persona intenta lograr en determinadas circunstancias. El producto no es el job: es una de las soluciones posibles que la persona puede elegir para avanzar. El Christensen Institute describe el enfoque como una lente para entender las fuerzas que acercan o alejan a personas y organizaciones de una decisión.[1]
La idea de “contratar” una solución es útil porque amplía la competencia real. Una planilla, un proceso manual, otro proveedor, pedir ayuda a un colega o no hacer nada pueden competir entre sí aunque no pertenezcan a la misma categoría comercial. Si el análisis empieza y termina en “qué funciones debería tener nuestro software”, ya quedó encerrado en el producto.
El job tampoco es puramente funcional. La formulación difundida por Clayton Christensen y sus coautores contempla dimensiones funcionales, sociales y emocionales: qué necesita resolver la persona, cómo quiere sentirse y cómo quiere ser percibida. El artículo de Harvard Business Review subraya además que las circunstancias pueden explicar mejor una elección que las características del comprador tomadas de forma aislada.[2]
No existe una única práctica homogénea bajo la etiqueta JTBD. Una tradición reconstruye historias de cambio: qué empujó a abandonar la situación anterior, qué atrajo de la nueva alternativa y qué ansiedades o hábitos frenaron la decisión. Otra, asociada con Outcome-Driven Innovation (ODI), define el job funcional y busca expresar resultados deseados y criterios de éxito. Strategyn es una fuente primaria para comprender su propia metodología, pero también es la consultora que la comercializa; por eso conviene describir el enfoque sin adoptar como evidencia neutral sus promesas de rendimiento.[3]
JTBD no reemplaza al buyer persona, el mapa de empatía ni la intención de búsqueda
Estas herramientas miran partes distintas del problema. Hacerlas competir produce diagnósticos pobres; usarlas con un límite claro permite que se complementen.
| Herramienta | Pregunta principal | Límite |
|---|---|---|
| Buyer persona | ¿Con qué tipo de persona o rol trabajamos? | Un perfil no demuestra por qué alguien cambia de solución en una situación concreta. |
| Mapa de empatía | ¿Qué sabemos, inferimos y todavía desconocemos sobre su experiencia? | Ordena evidencia e hipótesis, pero no reemplaza la investigación de una decisión. |
| Customer journey | ¿Qué sucede a lo largo del recorrido? | Representa etapas y puntos de contacto; el job explica el progreso que organiza ese recorrido. |
| Intención de búsqueda | ¿Qué parece querer resolver la persona con esta consulta ahora? | Una query no revela toda la historia, las alternativas ni la motivación. |
| Jobs to Be Done | ¿Qué progreso busca en esta circunstancia y por qué cambiaría? | No define por sí solo el mensaje final, el producto ni la página que hay que crear. |
| Propuesta de valor | ¿Cómo prometemos ayudar mejor que las alternativas? | Es una decisión de posicionamiento alimentada por la investigación, no la investigación misma. |
La diferencia con intención de búsqueda merece especial cuidado en SEO. Google explica que sus sistemas intentan establecer la intención detrás de una consulta y consideran, entre otras señales, sus palabras, la relevancia y usabilidad de las páginas, las fuentes y el contexto.[4] Eso describe cómo Search interpreta una query; no convierte cinco palabras en una entrevista. La consulta es evidencia de lenguaje y comportamiento de búsqueda. El job es una hipótesis más amplia que debe contrastarse con historias de decisión, tickets, llamadas de ventas, reseñas, uso y datos propios.
Cómo investigar un job sin inventarlo
Un buen trabajo de JTBD no empieza con una lluvia de ideas sobre deseos del “usuario ideal”. Empieza con personas que atravesaron una decisión relevante y pueden reconstruirla con suficiente detalle.
- Delimitá una situación y una decisión. “Mejorar el marketing” es demasiado abstracto. “Cambiar de CRM después de perder trazabilidad entre ventas y soporte” permite investigar un episodio.
- Reclutá experiencias recientes. Compradores, usuarios que abandonaron, personas que eligieron otra alternativa o que decidieron postergar aportan contrastes útiles.
- Reconstruí la línea de tiempo. Preguntá por el primer momento de incomodidad, los disparadores posteriores, la búsqueda, la comparación, la elección y el uso. Pedí hechos antes que opiniones generales.
- Registrá las alternativas reales. Incluí soluciones improvisadas, procesos manuales y no-consumo. La competencia no se limita a productos parecidos.
- Separá evidencia, interpretación e hipótesis. Una frase textual no equivale automáticamente a una necesidad estable. Un mapa de empatía basado en evidencia puede ayudar a hacer visible esa separación.
- Buscá patrones y contradicciones. Una entrevista puede descubrir una posibilidad, pero no alcanza para segmentar un mercado. Contrastá con más historias y otras fuentes antes de cuantificar.
El material Jobs to Be Done: A Toolbox, de Harvard Business School, recorre precisamente el reclutamiento, las entrevistas, el análisis y la transferencia de hallazgos hacia producto y marketing.[5] La transferencia importa tanto como la entrevista: acumular citas de clientes sin cambiar una decisión produce un informe atractivo, no un insight accionable.
La literatura sobre customer insights refuerza ese punto. Una revisión publicada en el Journal of the Academy of Marketing Science define un proceso que incluye generar, difundir y aplicar insights, y advierte que el campo mantiene definiciones fragmentadas.[6] En otras palabras, escuchar al cliente no garantiza que una organización aprenda ni que aplique bien lo aprendido.
Del job a decisiones de producto, marketing y búsqueda
Producto: criterios de éxito antes que una lista de features
Traducir una entrevista directamente a una funcionalidad es un salto peligroso. Primero conviene formular qué resultado espera la persona, qué fricción encuentra y cómo reconoce que avanzó. Después se evalúan soluciones. Un producto en marketing es el vehículo para entregar valor, no la necesidad ni el job.
Para priorizar, compará la importancia del resultado, la dificultad actual para conseguirlo y la evidencia disponible. El caso aplicado de Stepstone documentado en 2024 combinó investigación cualitativa, una encuesta y capacitación interna para integrar JTBD al desarrollo de producto.[7] Es un caso organizacional útil, no una prueba de que repetir el proceso garantice el mismo resultado en otra empresa.
Marketing: del progreso a una promesa específica
El job puede mejorar el posicionamiento porque revela contra qué situación compite la oferta y qué ansiedad debe reducir. Pero el lenguaje del cliente no se copia sin criterio: se interpreta, se contrasta y se transforma en una propuesta de valor clara. Una promesa sólida explica el progreso, muestra para quién y en qué contexto resulta relevante, y responde objeciones reales sin fabricar miedo.
Search: usar queries como señales, no como lectura mental
En contenidos, el job ayuda a conectar familias de consultas con tareas, comparaciones, dudas y criterios de decisión. Search Console puede mostrar cómo llegan usuarios al sitio; la SERP permite observar qué formatos interpreta Google como relevantes. Ninguna de esas fuentes confirma por sí sola por qué una persona empezó a buscar.
La secuencia razonable es: formular una hipótesis de job con investigación cualitativa, mapear el lenguaje de búsqueda, revisar la intención y elegir el tipo de página adecuado. Según el caso, puede ser una guía, herramienta, checklist, comparación, página de servicio, caso de uso o documentación. No hace falta crear una URL para cada variante verbal del mismo problema.
Ejemplo hipotético: migrar una web sin perder negocio
Ejemplo hipotético. Una empresa opera sobre una plataforma que limita integraciones, ralentiza cambios y obliga a sostener procesos manuales. Dirección aprueba evaluar una migración, pero el equipo teme perder indexación, ventas y medición. No hay clientes, métricas ni resultados reales detrás de este caso: sirve únicamente para mostrar el razonamiento.
El job no sería “contratar una migración WordPress” ni “comprar una nueva plataforma”. Una formulación inicial podría ser: cuando la plataforma actual frena cambios críticos, necesitamos trasladar la operación a una base sostenible sin perder visibilidad, ingresos ni capacidad de medir, para poder crecer con un riesgo controlado.
- Progreso funcional: mover contenidos, plantillas, datos e integraciones preservando URLs, indexación, analítica y conversiones.
- Progreso emocional: reducir incertidumbre y evitar una salida a producción difícil de revertir.
- Progreso social: poder explicar ante dirección qué se controló, qué riesgo queda y cómo se responderá.
- Alternativas: postergar, corregir la plataforma actual, migrar por etapas, hacerlo internamente o contratar un proveedor.
- Ansiedades: caída orgánica, pérdida de datos, costos ocultos, dependencia técnica y falta de responsables claros.
Las búsquedas posibles aparecerían en distintos momentos: “checklist migración SEO”, “comparar plataformas ecommerce”, “cómo mantener URLs al migrar” o “consultoría migración web”. Esas queries sugieren necesidades informativas, comparativas o transaccionales, pero todavía habría que validar quién decide, qué disparó el proyecto, qué se intentó antes y qué significa “migración segura” para esa organización.
La arquitectura resultante podría incluir una checklist, una guía para evaluar plataformas, documentación técnica y una página de servicio. La decisión final dependería del solapamiento entre intenciones y de la capacidad de cada página para resolver una tarea distinta, no de multiplicar URLs.
Matriz JTBD para convertir evidencia en decisiones
Esta matriz funciona como puente entre investigación y ejecución. Cada fila obliga a explicitar qué evidencia existe, qué pregunta queda abierta y qué decisión podría cambiar.

| Evidencia | Pregunta de investigación | Decisión posible |
|---|---|---|
| Circunstancia y disparador | ¿Qué cambió para que la persona empezara a buscar? | Segmentar por situación, no solo por demografía. |
| Progreso buscado | ¿Qué resultado intenta conseguir? | Priorizar resultados de producto y mensajes. |
| Alternativas y no hacer nada | ¿Qué usa hoy para resolverlo? | Definir competencia real y comparaciones útiles. |
| Fricciones y ansiedades | ¿Qué impide o demora el cambio? | Resolver objeciones, onboarding y contenido de evaluación. |
| Criterios de éxito | ¿Cómo sabe que el job quedó mejor resuelto? | Definir outcomes, casos de uso y medición. |
| Queries y SERP | ¿Cómo expresa una parte del problema al buscar? | Elegir keyword map, formato y tipo de página. |
| Validación | ¿Qué confirma o contradice la hipótesis? | Combinar entrevistas, CRM, tickets, uso, GSC y pruebas. |
Mini-template reutilizable
- Cuando… describí la circunstancia y el disparador, sin nombrar tu producto.
- Quiero… expresá el progreso o resultado, no una funcionalidad.
- Para poder… explicitá por qué ese progreso importa.
- Hoy resuelvo esto con… listá alternativas, atajos y no-consumo.
- Sabré que mejoró cuando… definí criterios observables de éxito.
- Necesito validar… separá lo comprobado de las hipótesis pendientes.
Errores que vuelven inútil el framework
- Redactar el job alrededor de la solución. “Usar nuestro dashboard” no explica el progreso y excluye alternativas antes de investigarlas.
- Confundir preferencia con historia. Que alguien diga que valora la velocidad no prueba que haya elegido, usado o abandonado una solución por ese motivo.
- Eliminar la circunstancia. “Necesito organizarme” es tan amplio que difícilmente oriente una decisión.
- Inferir emociones desde una keyword. Una consulta puede expresar una tarea; ansiedad, urgencia o confianza requieren más evidencia.
- Convertir cada job en una página. Primero hay que revisar intención, formato, solapamiento y capacidad real de aportar una respuesta diferenciada.
- Generalizar desde una entrevista. Un relato abre una hipótesis; los patrones necesitan contraste.
- Medir actividad en lugar de progreso. Más clics dentro de un producto no implican que la persona resuelva mejor su problema.
La prueba final es concreta: si el job no modifica una prioridad de producto, una promesa, una página o una prueba que el equipo va a ejecutar, todavía es una descripción interesante. La utilidad de Jobs to Be Done aparece cuando la evidencia conecta circunstancias y progreso con decisiones que pueden discutirse, implementarse y medirse.
Fuentes consultadas
- Christensen Institute, “Jobs to Be Done Theory”. Definición, circunstancias y dimensiones funcionales, sociales y emocionales.
- Clayton M. Christensen, Taddy Hall, Karen Dillon y David S. Duncan, “Know Your Customers’ ‘Jobs to Be Done’”, Harvard Business Review, 2016.
- Strategyn, “Jobs-to-be-Done: The Theory & Methodology”. Fuente primaria comercial para Outcome-Driven Innovation.
- Google Search, “How Search systems work”. Señales e interpretación de la intención detrás de una query.
- Derek C. M. van Bever, Bob Moesta, Iuliana Mogosanu, Shaye Roseman y Katie Zandbergen, “Jobs to Be Done: A Toolbox”, Harvard Business School, 2021.
- Stefan Stremersch y coautores, “Customer insights for innovation: A framework and research agenda for marketing”, Journal of the Academy of Marketing Science, 2025.
- Jim Kalbach, Yann Wermuth, Sabrina Duda y Florin Ciontu, “Jobs-to-be-done at scale: Disrupting the status quo with customer focus”, Journal of Digital & Social Media Marketing, 2024.
- André Devaux y coautores, “The Quest for Innovation: Addressing User Needs and Value Creation”, Springer, 2020.

