Jun 15 • Daniel Naranjo

Jobs, Fricciones y Activos: La Guía Definitiva

Jobs, Fricciones y Activos

¿De qué estamos hablando? 

Seguramente te han dicho que tienes que encargarte de los activos digitales que corresponden a tus Jobs to Be Done (JTBD), y pusiste cara de «hmmm no entendí», o tienes un requerimiento para identificar los JTBD del sistema para tu proceso particular, y todo te pareció tan enredado que solo te dieron ganas de llorar.
Este artículo es una pieza de fundamentación diseñada para aclarar esas dudas, para entender estos conceptos, con ejemplos reales del Sistema Operativo Potencia Pragma: SOPP.

De comprar a contratar,
o el cambio de Mindset

Para entender el SOPP primero hay que aceptar un principio fundamental:
Las personas no compran productos, compran cosas para satisfacer sus necesidades. En otras palabras, compran lo que el producto hace por ellos:
  • Taladro:
    No compramos la herramienta, sino ALGO que hace huecos en la pared.
  • Tiquete de metro:
    No compramos el tiquete, sino ALGO para ir del punto A al B.
  • Agua:
    No compramos el elemento, sino ALGO que nos quita la sed.
En la teoría de negocios moderna, sustituimos "comprar" por "contratar". Las personas contratan formas de satisfacer sus necesidades: ese enfoque da origen al Job to Be Done (JTBD).

El arte de redactar un JTBD

Un JTBD es aquello que debe lograrse —la condición— para resolver un problema. Es la respuesta a ¿Qué tiene que ser verdad para que el usuario sienta que su necesidad está satisfecha?.
Importante: El JTBD no es una acción, ni una tarea, ni una funcionalidad. Si usas verbos como "hacer", "construir" o "calcular", estás describiendo la solución, no el Job. 

Estructura JTBD

Para redactar correctamente un JTBD usamos la fórmula: 
Sujeto Verbo estado Objeto condición Contexto JTBD
  • Sujeto:
    Quién experimenta la condición (el usuario, el sistema).
  • Verbo:
    Suele ser "cuenta con", "tiene disponible", "está" o "existe".
  • Objeto:
    Lo que debe estar presente o ser verdad.
  • Contexto:
    Dónde y cuándo debe cumplirse.
UN TRUCO CLAVE: 
Un JTBD debe ser tan válido hoy como hace 20 años, independiente de su tecnología. Si tu JTBD incluye marcas, tecnologías o acciones concretas, entonces estás describiendo una funcionalidad, no un Job.

Tres dimensiones: Job Stories

Las personas normalmente tienen necesidades que dependen de situaciones particulares más que funcionales, que sirven para configurar la solución.

En la mayoría de casos, los JTBD suelen tener 3 dimensiones:

 Ejemplo para "Ir del punto A al B":

Dimensión

Funcional

Condición que se debe cumplir. 
EJM: El pasajero llega a su destino.
Dimensión

Emocional

Cómo se siente el usuario.
EJM: El pasajero se siente tranquilo en todo el viaje.
Dimensión

Social

Cómo quiere ser percibido.
EJM: Lo perciben como alguien seguro y preparado.

La metodología de "Job Stories" es una declaración que alinea el problema con el contexto y se redacta así: 

Cuando
(situación) quiero
(motivación) para poder
(resultado esperado)

 Ejemplo "Ir del punto A al B":

Cuando tengo reunión al otro lado de la ciudad, quiero un transporte que utilice la ruta más rápida, para poder llegar puntual y preparado.

Traducción Cliente vs Proveedor

Sabiendo que el JTBD es una condición que debe ser verdad, existe una sutileza importante: Los JTBD de cliente NO son los mismos de quien contrata, o el proveedor.

Ocurre todos los días: los clientes necesitan cosas, pero cuando nos contratan, nosotros necesitamos otras, lo que quiere decir:
JTBD Cliente    JTBD del proveedor
¿Por qué la diferencia? Porque no vemos lo mismo...
Un cliente puede decir "quiero la cena lista a tiempo", pero quien se encarga entiende que detrás de esta condición, hay más condiciones que deben cumplirse: Para cumplir un JTBD de cliente, pueden existir muchos JTBD del proveedor, como vemos en este ejemplo:

JTBD cliente vs JTBD proveedor:

🥘 🍽️ 🍰

JTBD Cliente

Los comensales (sujeto) disfrutan (verbo) de una cena impecable (objeto) servida a la hora acordada (contexto).
🍖🔥🥩

JTBD Proveedor

El cocinero (sujeto) cuenta (verbo) con los ingredientes frescos y picados (objeto) antes de empezar a cocinar (contexto).
El cocinero (sujeto) tiene acceso (verbo) a la receta (objeto) sin necesidad de buscarla en el momento (contexto).
El cocinero (sujeto) tiene (verbo) el orden de preparación (objeto) para que los platos salgan en el orden correcto (contexto).

Fricciones del JTBD

 Resolver es más que simplemente "hacer".
En toda operación existen fricciones específicas: situaciones o cosas que impiden enfocarnos en resolver el problema. Una fricción es el ruido y cargas operativas que detiene el flujo de trabajo.

Las fricciones son muy importantes, pues permiten identificar condiciones habilitadoras de progreso a construir, o qué debe ser verdad en el entorno para poder dedicarnos al JTBD sin distracciones.
Para descubrir las fricciones, se aplican estas 3 preguntas en orden:

¿Dónde invierte más tiempo el proveedor para completar su Job?

Identifica el peso real del trabajo. Es clave para identificar el verdadero reto a resolver internamente.

¿Qué debe estar disponible para que la fricción no exista?

La respuesta es el JTBD del Sistema, es decir, la forma en que el sistema debe funcionar para lo que queremos hacer.

¿Cómo saber si resolvimos el JTBD correctamente?

Busca la evidencia de verificación: ¿qué tiene que pasar para que la condición realmente existe?

Ejemplo práctico

Situación + Aplicación

Tu pareja te avisa de repente que viene el jefe a almorzar...

JTBD Cliente >> Tu pareja
El jefe (sujeto) experimenta (verbo) un ambiente lleno de hospitalidad y excelencia (objeto) que valida la gestión de mi pareja (contexto).
JTBD Proveedor >> tú como cocinero
El cocinero (sujeto) tiene (verbo) los cuatro platos listos y servidos (objeto) en el momento requerido (contexto).

Ahora, identificar las fricciones:

#1 — ¿Dónde inviertes más tiempo?
20 minutos revisando qué hay en la nevera y alacena.
 15 minutos picando cebolla de manera repetitiva.
20 minutos buscando una receta que se ajuste a lo que tienes.
#2 — ¿Qué debe estar disponible para que no exista? (JTBD sistema)
El cocinero cuenta con inventario de ingredientes actualizado al instante.
La cebolla está previamente picada y lista para usar.
La receta (según ingredientes) está disponible sin tener que buscarla.
#3 — ¿Cómo saber si resolvimos el JTBD correctamente?
El cocinero revisa una (lista, pantalla) y ve el inventario sin abrir la nevera.
El cocinero toma la cebolla picada de un recipiente.
El cocinero recibe la receta automáticamente al declarar los ingredientes.

Si lees con atención, no hablamos de "app", "robot" o "asistente de voz", solo describimos condiciones.

Los activos digitales y las respuestas específicas, vienen después.

Ejemplos JTBD Pragma

Aprende con ejemplos concretos de áreas de sostenimiento y de chapters.
Todos con la estructura: Fricción, tres preguntas, y JTBD del sistema.

Nómina

Proyectos

Backend

UX

Fricción observada:

La nómina se procesa sin que toda la información del período esté consolidada a tiempo.
Cambios contractuales, ausencias y horas adicionales llegan tarde, incompletos o por canales manuales.

#1 — ¿Dónde invierte más tiempo el área?
Solicitando novedades manualmente, persiguiendo información que llega fuera de tiempo, corrigiendo errores después del pago.
#2 — ¿Qué debe estar disponible para que no exista? (JTBD sistema)
El área cuenta con un flujo que consolida automáticamente todas las novedades del período — cambios, ausencias, horas adicionales — antes de procesar la nómina, con alertas para casos que requieren revisión humana.
#3 — ¿Cómo saber si resolvimos el JTBD correctamente?
El área procesa la nómina con información completa y validada sin solicitar novedades manualmente, y no hay errores después del pago.
Fricción observada:

La asignación ocurre cuando la necesidad ya es urgente. El área reacciona buscando disponibilidad, coordinando con el chapter y negociando tiempos. El pragmático se entera tarde.

#1 — ¿Dónde invierte más tiempo el área?
Reaccionando a solicitudes de último minuto, negociando perfiles bajo presión, haciendo seguimiento manual.
#2 — ¿Qué debe estar disponible para que no exista? (JTBD sistema)
El área cuenta con visibilidad anticipada de la demanda — proyectos que van a iniciar, perfiles que se van a necesitar, tiempos de preparación — y gestiona asignaciones con anticipación.
#3 — ¿Cómo saber si resolvimos el JTBD correctamente?
El área confirma asignación con al menos una semana de anticipación, al inicio del proyecto en 90% de los casos, el pragmático recibe la notificación sin que nadie tenga que perseguir el proceso.
Fricción observada:

El desarrollador escribe código nuevo sin saber si rompe contratos existentes. Solo lo descubre cuando otro servicio falla — en revisión de código o en producción.

#1 — ¿Dónde invierte más tiempo el área?
Esperando pipelines de CI para descubrir incompatibilidades, corrigiendo errores después de que fallaron integraciones, revisando manualmente contratos.
#2 — ¿Qué debe estar disponible para que no exista? (JTBD sistema)
El desarrollador cuenta con validación automática de contratos disponible en su entorno local antes de hacer push.
#3 — ¿Cómo saber si resolvimos el JTBD correctamente?
El desarrollador detecta y corrige una violación de contrato en su entorno local antes de que el código llegue a revisión o a producción.
Fricción observada:

El pragmático dedica tiempo significativo a construir flows y guías de experiencia que ya existen en proyectos anteriores de Pragma — solo que nadie los encontró a tiempo.

#1 — ¿Dónde invierte más tiempo el área?
Buscando en carpetas, preguntando a colegas, rediseñando desde cero algo que ya existía.
#2 — ¿Qué debe estar disponible para que no exista? (JTBD sistema)
El pragmático cuenta con los patterns de experiencia validados — flows, heurísticas, componentes — disponibles y aplicables en el momento en que diseña.
#3 — ¿Cómo saber si resolvimos el JTBD correctamente?
El pragmático adapta un pattern existente y lo aplica en el mismo día, sin tener que reconstruir lo que Pragma ya validó en otro proyecto.

Los 3 niveles del JTBD

El pensamiento se organiza en tres niveles o capas, tipo "muñecas rusas" –matrioskas– para no perder el foco: El JTBD del cliente es la muñeca más grande. El del proveedor es una más pequeña dentro de esta. Y a veces, dentro de esa, hay otra aún más pequeña que es la que podemos diseñar.
Nivel 1 JTBD

Beneficiario Final

Condición para que Pragma opere, el pragmático prospere o el cliente reciba valor. Es el "cliente" de más alto nivel.
Nivel 2 JTBD

Sistema, área o SOPP

Condición para cumplir Job de forma consistente, anticipada, sin intervención manual. Es donde diseñas, construyes y tienes control directo.
Nivel 3 JTBD

Interfaz

Punto de contacto donde la fricción es observable.
Este nivel no se diseña — es la consecuencia del nivel 2,  o donde el sistema funciona bien o no.

¿Y esto cómo se conecta esto con todo lo demás?

Muy fácil: El "JTBD del cliente" puede ser cualquiera de los tres niveles, y depende de a quién le estamos resolviendo. Las tres preguntas se aplican igual en cualquier nivel. Lo único que cambia es quién es el beneficiario y qué control tenemos sobre la condición.

Activos digitales:
Consecuencia del JTBD

Los activos digitales (agentes, copilotos, prompts, herramientas) son los medios necesarios para que las condiciones del sistema se hagan realidad.

El JTBD nunca nombra el activo. El activo es consecuencia.
Si el JTBD del sistema es
"El cocinero cuenta con el inventario actualizado al instante":
un activo puede ser un escáner inteligente de nevera, o puede ser una lista que se actualiza en grupo manualmente.
El JTBD no cambia.
Si el JTBD del sistema es
"La cebolla está previamente picada y lista para usar":
el activo puede ser un picatodo, o un servicio que entregue vegetales picados.
El JTBD sigue siendo el mismo.

¿Cómo medimos el éxito?

El éxito se mide cuando la condición se cumple. En la cena del jefe, se cumple cuando los cuatro platos están listos y servidos a tiempo (JTBD proveedor).
Si eso ocurre, el sistema funcionó.
IMPORTANTE: 
Formular bien el Job no es lo mismo que tener el sistema. El Job define qué condición debe existir. Crear esa condición requiere rediseño de procesos, tecnología, datos y cultura — no solo automatizar lo que ya existe. Automatizar sin rediseñar es agregar una capa encima de la fricción, no solucionarla.

JTBD

Preguntas frecuentes

¿Qué es un JTBD?

JTBD  Condición que debe ser verdad para satisfacer una necesidad. No es una acción ni una funcionalidad.

¿Cómo se redacta un JTBD?

Se redacta como un estado, con la estructura:
Sujeto + verbo de estado o posesión + objeto de la condición + contexto.
EJM: "El sujeto cuenta con X disponible en contexto Y" o "El sujeto está en condición Z".

¿Cuáles son sus dimensiones?

Tiene tres dimensiones: Funcional, Emocional, Social, y las Job Stories ayudan a explorarlas: "Cuando... quiero... para poder...". Pragma tiende a usar sólo la funcional para nuestro nivel de JTBD

¿Cómo funciona en proveedores?

Debemos traducir el JTBD del cliente al JTBD del proveedor (lo que debemos lograr).

¿Qué fricciones tiene un JTBD de sistema?

Para descubrir fricciones y llegar al JTBD del sistema, usamos tres preguntas en orden:
#1: ¿Dónde invierte más tiempo el proveedor para completar su Job?
#2: ¿Qué debe estar disponible para que la fricción no exista? (JTBD del sistema)
#3: ¿Cómo saber si resolvimos el JTBD correctamente?

¿Qué niveles tiene un JTBD?

En Pragma, a veces usamos tres subniveles para afinar: beneficiario final (nivel 1), sistema del área o SOPP (nivel 2), e interfaz (nivel 3). El método de las tres preguntas se aplica igual en cualquier nivel. Diseñas desde el nivel 2, el destino es el nivel 1, y verificas en el nivel 3.

¿Qué son activos digitales del JTBD?

Los activos digitales (agentes, copilotos, prompts, herramientas) son los medios que construimos para hacer verdad el JTBD del sistema. El éxito se mide si la condición se cumple, no por las características del activo.