Jobs-To-Be-Done: poniendo el foco en la motivación y la situación del cliente (1)
¿Cuál es el problema que tus clientes quieren resolver cuando compran tus productos? El enfoque JTBD pone foco en las motivaciones del comprador como factor causal de la compra y propone usar el problema que el usuario tiene en cada circunstancia como medida del mercado y eje de nuestro negocio.
La teoría de Jobs-To-Be-Done (JTBD), que en este blog hemos tratado repetidamente (ver aquí y aquí) parece estar experimentando un renacimiento, con su difusión por sus nuevos practicantes y la reciente publicación de libros por algunos de sus primeros evangelistas: Clayton Christensen (“Competing Against Luck”) y Tony Ulwick (“Jobs to be Done: Theory to Practice”).
El enfoque Jobs-To-Be-Done surgió a principios de los pasados años 90 como una manera de considerar las motivaciones de los clientes como la esencia de un mercado, en lugar de los atributos de dichos clientes o las características de los productos.
Durante los últimos años las empresas han desarrollado la capacidad de amasar ingentes cantidades de datos sobre sus clientes. Y sin embargo, el desarrollo de nuevos productos -que se ha convertido en un proceso disciplinado alimentado por esos datos- sigue siendo una actividad habitualmente condenada al fracaso. El problema está en que todos esos datos que las empresas recogen están estructurados para mostrar correlaciones (“con un 60% de probabilidad, los clientes en este segmento compran el producto”) y los directivos toman decisiones basadas en dichas correlaciones, no en la causalidad de las compras de los clientes.
JTBD: problemas y situaciones
El marco Jobs-To-Be-Done es una herramienta para evaluar las motivaciones y circunstancias que aparecen en la vida de los clientes. Estos raramente toman decisiones de compra en función de sus características demográficas o psicográficas o alrededor de lo que haría el consumidor medio en su categoría, sino que a menudo compran cosas porque se encuentran con un problema que les gustaría resolver.
Un “trabajo” (Job-To-Be-Done) es el problema esencial con el que un cliente se encuentra en una situación determinada, o el progreso que quiere hacer en una circunstancia dada. Por ejemplo, “pasar el rato mientras hago cola” o “preparar un desayuno nutritivo para que nuestra hija se lleve al colegio”.
Cuando compramos un producto esencialmente lo “contratamos” para que nos ayude a realizar un trabajo. Y si hace el trabajo bien, la próxima vez que nos enfrentemos a ese trabajo tenderemos a contratar ese producto nuevamente.
El enfoque JTBD tuvo sus primeros practicantes en Bob Moesta de The ReWired Group y a Tony Ulwick, de Strategyn, y fue popularizado por Clayton Christensen en “The Innovator’s Solution” (ver también su famoso video sobre milkshakes).
En general, los trabajos son multifacetados y tienen no sólo componentes funcionales (qué queremos hacer), sino también emocionales (cómo nos queremos sentir) y, dentro de estos, aspectos tanto personales como sociales. Como proveedores, no podemos olvidar ninguna de estas facetas si queremos que nuestro producto haga bien su trabajo.
JTBD describe el “por qué” (la motivación), no el “cómo” (la funcionalidad). Los productos no se ajustan a la gente, se ajustan a los problemas. Con una comprensión del trabajo para el cual los clientes contratan un producto o servicio, las empresas pueden desarrollar y comercializar más exactamente productos adaptados a lo que los clientes están tratando de hacer.
Cómo se expresa un Job-To-Be-Done
Hay muchas maneras de expresar un JTBD, pero en general esas expresiones tienen tres componentes:
- Situación: el contexto en el que aparece el problema
- Motivación: problema u objetivo que hay que resolver/alcanzar
- Resultado: cómo mejora la vida del usuario cuando el problema se ha resuelto
Algunos autores proponen el uso de job stories (de manera análoga a las user stories de Agile) con el formato
Cuando <SITUACIÓN> quiero <MOTIVACIÓN> de manera que <RESULTADO>
Por ejemplo: “cuando un nuevo cliente importante se registra quiero que se me notifique, de modo que pueda iniciar una conversación con él”.
Vemos que, a diferencia de las user stories, en las job stories no aparece una persona/rol ni una acción ya que no se trata de definir una tarea o función sino un problema. Volveremos sobre este tema en un próximo post, cuando hablemos de artefactos para definir requisitos y especificaciones de un producto.
Algunas implicaciones de Job-To-Be-Done
La teoría de Jobs-To-Be-Done tiene importantes implicaciones sobre cómo definimos nuestro mercado y diseñamos nuestro negocio:
Define tu mercado alrededor del JTBD. Mientras que la mayoría de las empresas tiende a definir un mercado alrededor de un producto, una tecnología, una solución o un segmento de clientes, cuando se aplica la teoría de Jobs-To-Be-Done un mercado se define como el trabajo que un ejecutor está tratando de que se realice. Si seguimos definiendo el mercado alrededor de unos segmentos que no tienen en cuenta las motivaciones de los clientes o de unas determinadas categorías de productos que no son las únicas que los clientes pueden estar considerando para realizar el trabajo podemos caer en una “miopía” estratégica. Sólo cuando hacemos que el trabajo sea la “unidad de medida” del mercado podemos entender a quién le podemos vender y contra qué alternativas competimos realmente.
Diseña tu negocio alrededor del JTBD. En lugar de diseñar un negocio alrededor de un producto o solución que con toda seguridad se va a quedar obsoleto las empresas deberían diseñarlo alrededor de un trabajo. De este modo la empresa va a estar siempre enfocada en crear las soluciones que mejor hagan ese trabajo y esto dará como resultado que será la propia empresa la que con mayor probabilidad se cause disrupción a sí misma (en lugar de que lo hagan otras empresas) y que, como consecuencia, tenga una vida más larga.
En la segunda parte de este post seguiremos hablando de JTBD, de las oportunidades que crea para la innovación y de sus diferencias reales con otros enfoques.
El post “Jobs-To-Be-Done: poniendo el foco en la motivación y la situación del cliente (1)” se publicó primero en “Marketing & Innovación”.
[¿Quieres aprender a aplicar estas ideas en tu empresa? Nuestros talleres sobre Marketing estratégico para empresas tecnológicas y Product Management de productos tecnológicos te pueden ayudar.]

n esta segunda parte del post (ver la primera
Bendle y Bagga hablan en su artículo de una manera de medir el valor de un “me gusta”, calculando el valor medio de los clientes que son fans de una marca en medios sociales (o hacen “me gusta” o son seguidores) y restándole el valor medio de los clientes que no son fans. Sin embargo, los mismos autores reconocen que es difícil atribuir esta causalidad: que tal vez la diferencia de valor no es consecuencia del “me gusta” y que los fans son inicialmente más favorables hacia la marca que los no fans.
El principal aspecto a tener en cuenta en el cálculo es que los beneficios deben ser incrementales, es decir, atribuibles directamente a la inversión, y que deben excluir los que se habrían producido si la inversión no se hubiera llevado a cabo (“caso base”). Esto añade complejidad al trabajo de los evaluadores, que en muchas ocasiones incorporan equivocadamente al cálculo todos los beneficios, no sólo los incrementales.
En un estudio realizado por Neil Bendle y Charan Bagga y cuyos resultados se analizan en su artículo
Durante algún tiempo el NPS se ha vendido como
No existe ningún producto cuyos requisitos no cambien durante el proyecto de desarrollo. Bien sea debido a que nuestra comprensión de las necesidades de los clientes va evolucionando o a cambios en la tecnología o el entorno competitivo, estos cambios son inevitables. Y sin embargo muchas empresas ponen una extraordinaria fe en sus planes, hasta el punto de monitorizar cada fase en relación a ciertos objetivos e hitos intermedios y de atribuir cualquier desviación a una mala gestión y ejecución. Pero este pensamiento, que puede resultar adecuado en entornos conocidos actividades repetitivas, lleva a resultados pobres en la innovación de producto, donde cada día se generan nuevos insights y las condiciones cambian continuamente.
Mito 2: Procesar el trabajo en lotes grandes mejora las economías del proceso de desarrollo
De ese impulso surgieron métodos como
Si se comete el error de no respetar estas diferencias críticas se puede socavar la planificación, ejecución y evaluación de los proyectos de desarrollo de productos. En su artículo
No todos los productos son aptos para un modelo freemium. Este modelo es tanto más viable cuanto mayor es el grado de cumplimiento de las siguientes circunstancias:
Esencialmente en el modelo freemium los usuarios pueden obtener gratis una versión básica del producto y tienen que pagar para acceder a otra versión (o un conjunto de versiones) más funcional y potente.
