Jobs to be Done aplicado a producto: del "qué quieren los usuarios" al "qué progreso intentan lograr"

Theodore Levitt, profesor de Harvard Business School, lo formuló con una claridad que sigue vigente más de sesenta años después: la gente no quiere comprar un taladro de un cuarto de pulgada; quiere un agujero de un cuarto de pulgada. Esta idea, aparentemente sencilla, contiene un desplazamiento conceptual enorme para quienes gestionan productos: el foco deja de estar en lo que construimos y se traslada al progreso que el usuario intenta lograr.

La teoría de Jobs to be Done (JTBD) formaliza esta intuición. En esencia, propone que las personas no compran productos ni servicios: los "contratan" para realizar un trabajo específico en sus vidas. Ese trabajo —el job— tiene dimensiones funcionales, pero también emocionales y sociales. Y comprender esas dimensiones cambia radicalmente lo que entendemos por "necesidad del cliente" y, en consecuencia, las decisiones que tomamos sobre nuestro producto.

Conviene, antes de profundizar, situar las voces principales detrás del concepto. Aunque la idea tiene raíces en el pensamiento de Peter Drucker y el propio Levitt, fue Tony Ulwick quien en 1990 desarrolló el enfoque sistemático que denominó Outcome-Driven Innovation (ODI), aplicándolo con éxito en Cordis Corporation en 1992. Clayton Christensen, profesor de Harvard Business School, popularizó la teoría a partir de 2003 en The Innovator's Solution y la desarrolló en profundidad en Competing Against Luck (2016). Y Bob Moesta, co-arquitecto del enfoque junto a Christensen, aportó la dimensión práctica de las entrevistas de cambio (switch interviews) y las fuerzas del progreso, recogidas en Demand-Side Sales 101 (2020).

¿Tres perspectivas o una sola? En realidad, son interpretaciones complementarias de la misma idea central, con diferencias de énfasis que resultan relevantes según el contexto de aplicación. Christensen ofrece la lente conceptual —un modo de pensar—, Ulwick aporta un proceso cuantitativo y estructurado, y Moesta se centra en las dinámicas cualitativas de la decisión de compra. Para un equipo de producto, las tres son útiles en momentos distintos del ciclo de discovery.

Más allá de las features: entender el trabajo real

Uno de los problemas más frecuentes en la gestión de producto es confundir lo que los usuarios dicen que quieren con lo que realmente necesitan. Las encuestas de satisfacción, las peticiones de features y los análisis de uso pueden ofrecer datos valiosos, pero rara vez revelan la motivación profunda que lleva a alguien a "contratar" un producto.

El caso clásico del milkshake, documentado por Christensen y Moesta, ilustra bien esta brecha. Una cadena de restauración rápida quería incrementar las ventas de batidos. Habían probado cambios de sabor, textura y tamaño basándose en las preferencias declaradas de sus clientes, sin resultados significativos. Solo cuando el equipo investigador observó y entrevistó a los compradores con la lente de JTBD, descubrieron que el batido matutino cumplía un trabajo completamente distinto al de la tarde: por la mañana, los conductores lo "contrataban" para hacer el trayecto al trabajo menos aburrido, mantener la saciedad hasta el almuerzo y poder consumirlo con una sola mano; por la tarde, los padres lo compraban como un pequeño capricho para sus hijos. Los competidores del batido matutino no eran otros batidos: eran los plátanos, los bagels y el aburrimiento del trayecto. Los de la tarde competían con helados y golosinas.

¿Qué tiene que ver esto con las decisiones de un equipo de producto de software? Más de lo que parece. Cuando priorizamos features basándonos en quién las pide y con qué frecuencia, estamos operando desde la misma lógica que la cadena de restauración cuando preguntaba a sus clientes si querían batidos más espesos. Estamos recogiendo preferencias, no entendiendo trabajos.

Un equipo de producto que aplica JTBD se pregunta: ¿qué progreso intenta lograr esta persona cuando utiliza nuestro producto? ¿En qué circunstancia concreta se encuentra? ¿Qué alternativas —incluyendo no hacer nada— está valorando? Estas preguntas desplazan la conversación del terreno de las funcionalidades al terreno de los resultados, y ese desplazamiento tiene consecuencias directas sobre qué construimos y qué dejamos fuera.

Las tres dimensiones del job: funcional, emocional y social

Uno de los errores más comunes al aplicar JTBD es reducir el "trabajo" a su componente funcional. Christensen insistía en que un job tiene siempre tres dimensiones que operan simultáneamente.

La dimensión funcional es la más evidente: la tarea concreta que la persona intenta completar. Gestionar mis gastos mensuales, preparar una presentación para el comité, encontrar un vuelo compatible con mi agenda. Es la dimensión que los equipos de producto suelen capturar bien, porque encaja con la lógica de las historias de usuario.

Pero la dimensión emocional —cómo quiere sentirse la persona al completar el trabajo— y la dimensión social —cómo quiere ser percibida por los demás— son igualmente determinantes en la decisión de "contratar" un producto. Un profesional que busca una herramienta de gestión de proyectos no solo quiere organizar tareas (funcional): quiere sentir que tiene el control de su trabajo (emocional) y proyectar ante su equipo y sus superiores que gestiona de forma competente (social).

¿Por qué esto importa para las decisiones de producto? Porque dos soluciones funcionalmente equivalentes pueden diferir enormemente en su capacidad de satisfacer las dimensiones emocional y social del job. Y la dimensión que un equipo ignora suele ser la que explica por qué los usuarios abandonan el producto o no lo adoptan a pesar de que "sobre el papel" resuelve su problema.

En el contexto actual, donde la inteligencia artificial permite construir funcionalidades con una velocidad inédita, esta reflexión cobra especial relevancia. Como señala la guía de Scrum en equipos con IA de Scrum Manager, la pregunta estratégica ya no es "¿podemos construirlo?" sino "¿deberíamos construirlo, y por qué?". JTBD ofrece precisamente el marco para responder a ese "por qué" desde la perspectiva del usuario, no desde la capacidad técnica del equipo.

Las cuatro fuerzas del progreso: por qué los usuarios cambian (o no)

Bob Moesta desarrolló un modelo que resulta especialmente útil para equipos de producto que necesitan entender la dinámica de adopción: las cuatro fuerzas del progreso. Este modelo describe las tensiones que operan cuando alguien considera cambiar de una solución actual a una nueva.

Dos fuerzas empujan hacia el cambio: la insatisfacción con la situación actual (lo que Moesta denomina push) y la atracción de la nueva solución (pull). Y dos fuerzas generan resistencia: la ansiedad ante lo nuevo (anxiety of the new) y el hábito de lo presente (habit of the present).

Para que un usuario "contrate" un nuevo producto, las fuerzas impulsoras deben superar a las de resistencia. Y aquí hay una paradoja que muchos equipos de producto ignoran: añadir más funcionalidades no necesariamente aumenta la atracción; de hecho, puede incrementar la ansiedad. Un producto con demasiadas capacidades genera incertidumbre: ¿seré capaz de aprender a usarlo? ¿Justifica la inversión de tiempo la migración desde mi herramienta actual?

Esta perspectiva tiene implicaciones prácticas directas. Cuando un equipo de producto se pregunta "¿por qué los usuarios no adoptan nuestra nueva funcionalidad?", la respuesta rara vez está solo en la funcionalidad en sí. Puede estar en la ansiedad que genera la curva de aprendizaje, en el hábito de usar una hoja de cálculo que "funciona suficientemente bien", o en el temor a quedar expuesto ante colegas si la nueva herramienta no da los resultados esperados.

Reducir la fricción —la ansiedad y el hábito— suele ser más eficaz que añadir más atractivo. En palabras del propio Moesta, "el dinero se hace en el lado de la ansiedad de la ecuación". Si puedes identificar qué frena a las personas, puedes acortar el camino hacia la adopción de forma más efectiva que añadiendo otra feature al roadmap.

JTBD y el ecosistema de discovery: cómo integrar el enfoque en la práctica

¿Dónde encaja JTBD en el flujo de trabajo de un equipo de producto? No es una metodología que sustituya al discovery continuo, a las historias de usuario o al product backlog. Es una lente que enriquece cada uno de estos elementos.

JTBD y las historias de usuario

El formato clásico "Como [rol], quiero [funcionalidad], para [beneficio]" captura bien la intención, pero puede quedarse en la superficie del job real. Una historia como "Como usuario registrado, quiero filtrar los resultados por fecha, para encontrar lo que busco más rápido" describe una interacción, pero no el trabajo subyacente. ¿Qué está intentando lograr esa persona? ¿Preparar un informe urgente para una reunión que tiene en una hora? ¿Verificar si un dato que recordaba sigue siendo vigente? Cada uno de esos contextos implica prioridades de diseño distintas.

JTBD no sustituye las historias de usuario; las complementa aportando el contexto circunstancial que les da sentido. Como señala la guía de historias de usuario de Scrum Manager, todo epic e historia es, en el fondo, una hipótesis a validar: hasta que el usuario la vea o la utilice y nos dé feedback, no sabremos si es la solución adecuada. JTBD ayuda a formular hipótesis más precisas porque parte de una comprensión más profunda del problema.

JTBD y los Opportunity Solution Trees

Teresa Torres, en Continuous Discovery Habits (2021), propone los Opportunity Solution Trees como herramienta para conectar los outcomes deseados con las soluciones a través de las oportunidades identificadas en la investigación con usuarios. JTBD encaja de forma natural en la capa de oportunidades de este modelo: cada job mal resuelto, cada fricción en el progreso del usuario, es una oportunidad que el equipo puede explorar.

La combinación es poderosa. El Opportunity Solution Tree parte de un outcome de negocio (la raíz), se ramifica en oportunidades (necesidades y dolores del usuario), luego en soluciones posibles y finalmente en tests de supuestos. JTBD aporta precisamente la profundidad que necesita la capa de oportunidades: en lugar de listar "los usuarios quieren una búsqueda más rápida", un equipo que ha hecho entrevistas de JTBD puede identificar que "los usuarios que preparan informes bajo presión de tiempo necesitan localizar datos específicos sin tener que recordar dónde los guardaron". La oportunidad es más concreta, más accionable y más difícil de confundir con una solución disfrazada.

JTBD y la priorización del backlog

La priorización sigue siendo uno de los desafíos más persistentes en la gestión de producto. Técnicas como MoSCoW, WSJF o el cálculo de ROI aportan estructura, pero todas dependen de la calidad de la información sobre el valor que cada ítem aportaría al usuario. Y ahí es donde JTBD marca una diferencia.

Cuando un equipo conoce los jobs principales que sus usuarios intentan resolver —y sabe cuáles están bien servidos y cuáles no—, la conversación de priorización cambia de naturaleza. Ya no se trata de "¿qué feature piden más?" sino de "¿qué trabajo importante está peor resuelto?". Ulwick formalizó esto con su Opportunity Algorithm, que combina la importancia que el usuario otorga a un resultado con su nivel de satisfacción actual: las oportunidades más valiosas son aquellas donde la importancia es alta y la satisfacción, baja.

No es necesario implementar el proceso completo de Outcome-Driven Innovation para beneficiarse de esta lógica. Basta con incorporar al refinamiento del backlog la pregunta: "¿Qué job del usuario mejoraría esto, y cómo de mal resuelto está ese job actualmente?". La respuesta, incluso informal, introduce un criterio de priorización basado en el progreso del usuario, no en la conveniencia interna.

Lo que JTBD no resuelve (y la honestidad de reconocerlo)

Sería deshonesto presentar JTBD como una solución completa para las decisiones de producto. Como toda lente teórica, tiene puntos ciegos y limitaciones que conviene nombrar.

En primer lugar, identificar el job correcto es difícil. Requiere investigación cualitativa rigurosa —entrevistas de cambio, observación contextual— que consume tiempo y habilidades que no todos los equipos tienen. Las entrevistas de JTBD no son entrevistas de usabilidad ni sesiones de feedback: son conversaciones retrospectivas sobre decisiones de cambio que demandan una técnica específica para evitar que el entrevistado racionalice a posteriori sus motivaciones reales.

En segundo lugar, JTBD no dicta la solución. Conocer el job es necesario pero no suficiente: un equipo puede entender perfectamente que sus usuarios necesitan "sentirse preparados para una reunión importante en cinco minutos" y, sin embargo, diseñar una solución que no logre ese resultado. La distancia entre el diagnóstico y la solución sigue requiriendo creatividad, prototipado y validación iterativa. JTBD ilumina el "para qué", pero el "cómo" sigue siendo trabajo de discovery y de ingeniería.

En tercer lugar, el enfoque puede generar tensiones organizativas. Cuando un equipo empieza a pensar en jobs, descubre a menudo que la arquitectura del producto, la estructura de los equipos o los KPIs del negocio están organizados en torno a funcionalidades, no a trabajos del usuario. Reorganizar en torno a jobs implica conversaciones incómodas sobre prioridades, propiedad y métricas que no siempre encuentran receptividad en la organización. No todos los problemas se resuelven con frameworks: a veces la respuesta es reconocer que el cambio necesario es sistémico y excede la capacidad de decisión del equipo de producto.

Y en cuarto lugar, la relación entre JTBD y datos cuantitativos no siempre es directa. Los jobs se descubren típicamente mediante investigación cualitativa, pero las decisiones de producto a escala requieren también señales cuantitativas. Integrar ambos tipos de información sin que uno anule al otro es un ejercicio de equilibrio que no tiene recetas sencillas.

El job detrás del job: una capa más de profundidad

Hay un matiz que vale la pena explorar y que a menudo se pierde en las aplicaciones superficiales de JTBD: los jobs operan a diferentes niveles de abstracción, y el nivel que elijas determina el tipo de decisiones que puedes tomar.

Un usuario de una plataforma de e-learning puede decir que quiere "completar un curso de Scrum". Ese es un job funcional legítimo. Pero detrás puede haber un job de nivel superior: "demostrar a mi organización que estoy actualizado profesionalmente" o "ganar confianza para facilitar las ceremonias de mi equipo". Y detrás de ese, uno aún más profundo: "sentir que mi carrera avanza y que no me estoy quedando atrás".

Cada nivel sugiere decisiones de producto diferentes. Si el job es "completar un curso", optimizamos la experiencia de aprendizaje secuencial. Si es "demostrar actualización profesional", quizá lo que necesita el usuario es un certificado visible, un perfil público o una herramienta de diagnóstico como AgiLevel que le ayude a mapear dónde está y hacia dónde quiere ir. Si es "sentir que mi carrera avanza", tal vez el producto más relevante no es un curso, sino una comunidad de práctica donde intercambiar experiencias con pares —algo que, precisamente, busca fomentar el modelo del Club Agile—.

No hay un nivel "correcto" de job: cada uno es útil para un tipo de decisión. Pero el error más frecuente es quedarse en el nivel más superficial y construir soluciones que resuelven la tarea inmediata sin abordar la motivación profunda.

De la teoría a la conversación: cómo empezar

Para equipos que quieran incorporar el pensamiento JTBD a sus decisiones de producto sin necesidad de un proyecto de investigación a gran escala, hay algunos puntos de partida accesibles.

El primero es reformular las preguntas en las entrevistas con usuarios. En lugar de "¿qué funcionalidad te gustaría que añadiéramos?", preguntar "cuéntame la última vez que intentaste [resolver este problema]. ¿Qué hiciste? ¿Qué alternativas consideraste? ¿Qué fue lo más frustrante?". Este tipo de preguntas retrospectivas, basadas en comportamientos reales y no en preferencias hipotéticas, son la base de las entrevistas de cambio que propone Moesta.

El segundo es mapear la competencia real. ¿Contra qué compite tu producto? No solo contra otros productos similares, sino contra todas las alternativas que el usuario podría "contratar" para resolver el mismo job, incluyendo hojas de cálculo, notas en papel, preguntar a un colega o simplemente no hacer nada. Cuando amplías el marco competitivo, las decisiones de posicionamiento y diferenciación cambian.

El tercero es revisar el backlog a través de la lente del job. Antes de priorizar, preguntarse: ¿sabemos qué trabajo del usuario resolvería cada ítem? ¿Tenemos evidencia de que ese trabajo está mal resuelto actualmente? Si no podemos responder con cierta confianza, quizá necesitemos más investigación antes de construir.

Y el cuarto, quizá el más importante, es compartir los jobs descubiertos con todo el equipo. Moesta señala que uno de los mayores beneficios de entender los jobs es que reduce drásticamente la cantidad de reuniones improductivas: cuando todos comparten un entendimiento claro de qué intenta lograr el usuario, las discusiones sobre qué construir se vuelven más productivas porque parten de un terreno común.

JTBD no es una varita mágica que elimina la incertidumbre inherente a las decisiones de producto. Pero sí ofrece algo valioso: una disciplina de pensamiento que obliga a mirar más allá de las funcionalidades y a preguntarse, con honestidad, si estamos resolviendo el problema que el usuario realmente tiene o el que a nosotros nos resulta más cómodo abordar.

En un momento donde la capacidad de construir crece exponencialmente gracias a la IA y donde la tentación de añadir features porque "podemos" es más fuerte que nunca, esta disciplina es quizá más necesaria que en ningún otro momento. No se trata de construir más, sino de construir lo que importa. Y para saber qué importa, necesitamos entender el trabajo que nuestros usuarios están intentando hacer.

La invitación es a probar: en vuestra próxima sesión de refinamiento, en la próxima entrevista con un usuario, en la próxima discusión sobre el roadmap. No como una metodología que se implanta de un día para otro, sino como una pregunta que se incorpora a la conversación del equipo: ¿qué progreso está intentando lograr esta persona, y cómo podemos ayudarle mejor?

Bibliografía

Cagan, M. (2018). Inspired: How to Create Tech Products Customers Love (2.ª ed.). Wiley.

Cagan, M., Hickman, L., Jones, C., Idiodi, C. y Moore, J. (2024). Transformed: Moving to the Product Operating Model. Wiley.

Christensen, C. M., Hall, T., Dillon, K. y Duncan, D. S.

• (2003). "The Innovator's Solution: Creating and Sustaining Successful Growth". Harvard Business Review Press.
• (2016). Competing Against Luck: The Story of Innovation and Customer Choice. HarperBusiness.

Levitt, T. (1960). "Marketing Myopia". Harvard Business Review, 38(4), 45-56.

Moesta, B. y Engle, G. (2020). Demand-Side Sales 101: Stop Selling and Help Your Customers Make Progress. Lioncrest Publishing.

Scrum Manager

• (2025). Historias de usuario: guía para la práctica. Disponible en los recursos de Scrum Manager.
• (2025). Scrum en equipos con IA — Guía rápida. Disponible en los recursos de Scrum Manager.

Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.

Ulwick, A. W.

• (2002). "Turn Customer Input into Innovation". Harvard Business Review, 80(1), 91-97.
• (2005). What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services. McGraw-Hill.
• (2016). Jobs to Be Done: Theory to Practice. Idea Bite Press.