Customer Success y alineación con Producto

Así es como viajan la mayoría de las solicitudes de funcionalidad en una empresa SaaS: un CSM escucha "necesitamos exportación masiva" de un cliente frustrado. El CSM lo registra en la plataforma de CS como una solicitud de funcionalidad. El PM lee "exportación masiva: 4 cuentas" en el resumen semanal de retroalimentación. Va al backlog por debajo de otras 30 solicitudes. Seis meses después, el cliente abandona. Entrevista de salida: "No podíamos sacar nuestros datos para generar los informes que necesitaba la dirección."

La solicitud de funcionalidad era real. Pero "exportación masiva" era la solución propuesta por el cliente, no el trabajo para el que estaba contratando el producto. El trabajo real era: cuando necesito informar externamente, necesito sacar los datos en un formato que mis partes interesadas puedan leer, sin tener que copiar fila por fila.

Es un problema diferente. Podría resolverse con una exportación. O con un enlace a un dashboard compartible. O con una integración nativa con Salesforce. El equipo de CS tenía la señal en bruto. Nadie la tradujo.

Jobs-to-be-Done (JTBD) es la capa de traducción. No requiere nuevos métodos de recopilación de datos. Es una disciplina de reinterpretación aplicada a los datos que CS ya tiene.

Qué es realmente JTBD (y qué no es)

El planteamiento original de Clayton Christensen era sencillo: la gente no compra productos. Contrata productos para hacer un trabajo. El artículo fundacional de Christensen en HBR sobre JTBD lo explica con claridad: el ejemplo del batido es famoso. McDonald's descubrió que los viajeros matutinos contrataban batidos para que un trayecto aburrido pasara más rápido y para estar saciados hasta el almuerzo, no porque tuvieran hambre o fueran indulgentes. El trabajo definió la estrategia del producto. Batidos más espesos, pajitas más fáciles de usar, vendidos en el carril de autoservicio.

Bob Moesta, quien operacionalizó JTBD a nivel práctico, fue más allá: los trabajos no son solo funcionales. Tienen un contexto (la situación que desencadena la necesidad), un resultado deseado (cómo se ve "hecho") y una restricción (lo que el cliente no puede o no hará). El formato de declaración de trabajo que generó su trabajo es el que los equipos de CS deberían usar:

Estructura de la declaración de trabajo:

"Cuando [situación], necesito [resultado funcional], sin [restricción]."

Este no es el formato de historia de usuario. "Como usuario, quiero exportación masiva" describe una preferencia. La declaración JTBD describe una situación, un resultado y lo que hace que el enfoque actual no funcione. Son cosas diferentes, y la diferencia importa para las decisiones de producto.

JTBD tampoco es lo mismo que "puntos de dolor". Los puntos de dolor describen fricción. Los trabajos describen intención. Un cliente que dice "los informes son lentos" está describiendo un dolor. El trabajo subyacente es "cuando estoy presentando en vivo a la dirección, necesito recuperar los datos del cliente en menos de cinco segundos, sin perder credibilidad ante una rueda giratoria de carga". Punto de dolor: mejorar el rendimiento. Declaración de trabajo: ¿qué situaciones desencadenan la necesidad y cómo se ve "bien hecho" en realidad?

Para las conversaciones entre VP CS y Head of Product, la perspectiva operativa de Moesta es más útil que la teórica de Christensen. La pregunta no es "¿qué trabajo hace nuestro producto?". Es "¿qué trabajos están contratando realmente los clientes al producto y cuáles de esos trabajos estamos fallando?". La investigación de McKinsey sobre customer success 2.0 hace un punto paralelo: los equipos de CS que aprovechan el conocimiento del cliente para identificar trabajos no satisfechos generan una retención más duradera que los centrados exclusivamente en la gestión de relaciones.

Datos clave: JTBD y calidad de la señal de CS

Según el Informe de Gestión de Producto de ProductPlan de 2024, el 72% de los equipos de producto afirma que la retroalimentación del cliente es uno de sus tres principales datos de entrada para las decisiones de hoja de ruta, pero solo el 31% tiene un proceso estructurado para interpretar esa retroalimentación a nivel de trabajo y no de funcionalidad.

Las entrevistas de abandono se consideran consistentemente la fuente de datos de CS con mayor señal para la extracción JTBD, según la investigación de referencia de Customer Success de Gainsight, pero menos del 40% de los equipos de CS realizan entrevistas de salida estructuradas que pregunten qué intentaba lograr el cliente.

Los equipos que aplican ponderación por ARR a las declaraciones de trabajo (no solo a los recuentos de solicitudes de funcionalidad) informan de una alineación 2,3 veces mayor entre la retroalimentación de CS y los elementos enviados en la hoja de ruta, según la encuesta State of Product Management de Productboard.

Dónde encajan los datos de CS en el modelo JTBD

Los datos de CS son la materia prima más rica para la extracción de trabajos en la mayoría de las empresas SaaS. El desafío es que llegan en el formato incorrecto. Así es como cada fuente se mapea a los componentes JTBD.

Las notas de llamadas como contexto de situación. Cuando un CSM escribe "el cliente dijo que el flujo de trabajo de informes es doloroso durante su reunión de planificación del lunes", eso es la cláusula de situación: "cuando estoy en la reunión de planificación del lunes". Está enterrada en una nota, pero está ahí. Los CSMs capturan el "cuándo" constantemente. Casi nunca lo presentan como un dato de entrada JTBD.

Las entrevistas de salida de abandono como la señal de fallo de trabajo más honesta. Cuando un cliente abandona, está despidiendo al producto de un trabajo. Una entrevista de salida bien ejecutada pregunta: ¿qué intentaba lograr que el producto no le ayudó a hacer? ¿Qué va a hacer en su lugar? Esto es puro oro JTBD. La cláusula de restricción casi siempre aparece en las entrevistas de abandono: "No podía hacer X sin Y", donde Y es lo que el producto no logró proporcionar. Los equipos de CS que combinan las entrevistas de salida con señales del sistema de alerta temprana a menudo pueden detectar el fallo del trabajo antes del abandono, no después.

Los verbatims de QBR como declaraciones de resultado disfrazadas. Cuando un cliente dice en un QBR "queremos que esto se convierta en nuestra única fuente de verdad para los datos de clientes", está declarando un resultado deseado. Esa es la cláusula central de la declaración de trabajo. El CSM lo escucha como una aspiración. En realidad, es una definición de trabajo.

Los picos de tickets de soporte como evidencia negativa de trabajo. Cuando 15 tickets llegan en una semana sobre el mismo flujo de trabajo, eso es evidencia de que el producto está fallando en un trabajo para suficientes clientes como para desencadenar una frustración activa. El trabajo no es "corregir el error". Es "entender qué trabajo están intentando hacer todas estas 15 cuentas cuando chocan con este muro".

Los verbatims de NPS de promotores frente a detractores. Los promotores describen trabajos que el producto hace bien. Los detractores describen trabajos que el producto está fallando. El contraste entre las dos cohortes se mapea directamente en dónde el rendimiento del trabajo es sólido y dónde está roto. Los datos de tendencia de NPS se vuelven mucho más accionables cuando se superponen con las señales de uso del producto y salud del cliente. Las cuentas con alto uso y NPS en declive son la cohorte más urgente.

La materia prima está ahí. La brecha es el proceso de extracción que la convierte en declaraciones de trabajo sobre las que Producto puede actuar.

El proceso de extracción: de señal en bruto a declaración de trabajo

Marco con nombre: La Extracción JTBD en 5 Pasos La Extracción JTBD en 5 Pasos convierte los datos brutos de CS en declaraciones de trabajo validadas mediante el etiquetado basado en situaciones, la redacción de declaraciones de trabajo, la validación de verbatims de múltiples cuentas, la ponderación por ARR y la transferencia del mapa de trabajos a Producto. El marco fue desarrollado a partir de la teoría JTBD original de Clayton Christensen y la operacionalización práctica de Bob Moesta, adaptado para equipos de CS de SaaS del segmento medio que necesitan inteligencia estructurada de trabajos sin reformar sus procesos de datos de CS existentes.

Este es un proceso de cinco pasos. No requiere una herramienta especializada. Un documento compartido funciona.

Paso 1: Extraer datos de CS por tema, no por solicitud de funcionalidad. No empiece con "¿qué pidieron los clientes?". Empiece con "¿qué situaciones siguen describiendo los clientes?". Extraiga notas de llamadas, tickets de soporte y verbatims de QBR del trimestre pasado y etiquételos por tipo de situación, no por área de producto.

Paso 2: Reescribir cada grupo como una declaración de trabajo. Tome el grupo de notas en torno a un tema y escriba una o dos declaraciones de trabajo usando el formato: "Cuando [situación], necesito [resultado deseado], sin [restricción]." No suavice la restricción. A menudo es la parte más importante.

Paso 3: Validar con tres o más verbatims de cuentas diferentes. Una declaración de trabajo que solo puede atribuirse a una cuenta es anécdota, no patrón. Se necesitan al menos tres verbatims de cuentas diferentes (idealmente de cuentas en diferentes niveles de ARR) antes de tratarla como un trabajo validado.

Paso 4: Adjuntar el peso de ARR y el recuento de cuentas a cada trabajo. "7 cuentas que representan 420.000 dólares de ARR están fallando en este trabajo" es un dato de priorización de producto. "7 cuentas" es solo un recuento. El peso por ARR convierte las declaraciones de trabajo en decisiones de negocio. La misma disciplina de cuantificación aplica aquí que en el pipeline de retroalimentación más amplio.

Paso 5: Entregar un mapa de trabajos, no una lista de funcionalidades. El resultado para Producto es un conjunto de declaraciones de trabajo con verbatims de apoyo, peso de ARR y recuento de cuentas. No una lista de solicitudes de funcionalidad. Si entrega a Producto una lista de funcionalidades, recibirá decisiones a nivel de funcionalidad. Si les entrega un mapa de trabajos, recibirá decisiones a nivel de capacidad.

Análisis de Rework: Según los benchmarks de equipos de CS, los equipos de producto que reciben mapas de trabajos en lugar de listas de funcionalidades durante las sesiones de retroalimentación trimestrales toman decisiones de hoja de ruta a nivel de capacidad en aproximadamente la mitad del tiempo de los que evalúan colas de solicitudes de funcionalidad en bruto. El formato de declaración de trabajo (situación + resultado + restricción) da a los PMs el contexto para evaluar las compensaciones sin programar entrevistas de seguimiento para cada elemento. El umbral de validación de tres verbatims filtra además la anécdota del patrón, reduciendo el porcentaje de debates de hoja de ruta consumidos por casos particulares de una sola cuenta.

Ejemplos prácticos: antes y después

Estos dos ejemplos muestran la traducción en la práctica.

Ejemplo 1:

Solicitud de funcionalidad: "Necesitamos exportación masiva."
Declaración de trabajo: "Cuando necesito presentar datos de clientes a nuestro equipo directivo trimestralmente, necesito obtener esos datos en un formato que nuestra herramienta de BI pueda leer, sin tener que copiar manualmente 300 filas en una hoja de cálculo."
Implicación para el producto: la exportación masiva podría resolver esto, pero también podría hacerlo una integración nativa de BI, un endpoint de API o una vista compartible con formato de exportación. La declaración de trabajo abre el espacio de soluciones.

Ejemplo 2:

Solicitud de funcionalidad: "¿Pueden corregir la lentitud en los informes?"
Declaración de trabajo: "Cuando estoy en una reunión en vivo con un cliente y necesito recuperar sus datos de uso para responder una pregunta, necesito que el informe se cargue en menos de cinco segundos, sin perder la atención del cliente ante una rueda giratoria de carga."
Implicación para el producto: "corregir la lentitud" es vago. La declaración de trabajo le indica a Producto que el desencadenante es una reunión en vivo, el resultado es mantener la atención del cliente y la restricción es el retraso de carga. Eso es un brief de ingeniería mucho más específico.

Ejemplo 3:

Verbatim de detractor de NPS: "No podemos gestionar los permisos de la forma que requiere nuestro equipo de seguridad de TI."
Declaración de trabajo: "Cuando incorporamos un nuevo equipo a la plataforma, necesito configurar el acceso basado en roles que coincida con nuestras políticas de seguridad internas, sin tener que pedir a su equipo de soporte que haga cambios manuales."
Implicación para el producto: la solicitud de funcionalidad implícita aquí es "permisos granulares". La declaración de trabajo revela el contexto (incorporación), el resultado deseado (cumplimiento de políticas en autoservicio) y la restricción (dependencia del soporte del proveedor).

Ejemplo 4:

Entrevista de salida de abandono: "Acabamos construyendo nuestra propia solución porque no conseguimos que el flujo de trabajo se adaptara a nuestro proceso."
Declaración de trabajo: "Cuando gestionamos [flujo de trabajo específico], necesitamos que el sistema se adapte a nuestro proceso existente, sin tener que rediseñar el proceso para que encaje en la herramienta."
Implicación para el producto: este es un fallo clásico de trabajo del tipo "el producto es demasiado rígido". El cliente contrató el producto para que se adaptara a su flujo de trabajo. El producto los contrató para que se adaptaran al suyo. Lo despidieron.

Dónde falla JTBD con los datos de CS

La extracción JTBD falla de maneras predecibles. Conocerlas de antemano previene sesiones de síntesis desperdiciadas.

CSMs que resumen en lugar de citar. Cuando un CSM escribe "el cliente quiere mejores informes", la situación, el resultado y la restricción han sido eliminados. La paráfrasis mata la extracción JTBD. La corrección de disciplina es simple: las notas de llamadas requieren una cita verbal por problema escalado, no un resumen. Este es un cambio de práctica de etiquetado, no un cambio de herramienta.

Sesgo hacia cuentas pequeñas. Diez tickets de SMB sobre la misma funcionalidad ahogarán dos verbatims enterprise en un recuento bruto. Pero si esos dos verbatims enterprise representan 800.000 dólares de ARR y los tickets de SMB representan 50.000 dólares combinados, la ponderación por ARR del Paso 4 corrige esto. No ejecute la extracción JTBD sin adjuntar cifras de ARR.

Sesgo de recencia en las notas de llamadas. Un verbatim de QBR de hace 18 meses sobre un trabajo en el que el producto fallaba sigue siendo evidencia, especialmente si el producto no lo ha abordado. Filtrar la extracción de trabajos a los últimos 90 días omite fallos de trabajo persistentes y no resueltos.

El cliente que describe síntomas, no intención. Algunos clientes pueden articular el trabajo con claridad. Otros solo describen el síntoma ("el dashboard no nos funciona"). Cuando el verbatim es solo síntoma, el paso de extracción es una hipótesis: ¿qué trabajo podría indicar este síntoma? Esta hipótesis necesita al menos tres verbatims de corroboración antes de convertirse en una declaración de trabajo validada.

Construir una práctica JTBD en la interfaz CS-Producto

Una sesión mensual de minería de trabajos es la cadencia operativa correcta para la mayoría de los equipos del segmento medio. La investigación de TSIA sobre el Estado del Customer Success encuentra consistentemente que las prácticas de retroalimentación estructuradas (no las escalaciones ad hoc) son el principal diferenciador entre los equipos de CS que influyen en la hoja de ruta y los que no. La sesión dura 90 minutos, involucra a VP CS, Head of Product y un representante de CS Ops. Esta sesión es una extensión de CS como canal de voz del cliente, la disciplina estructurada que convierte las señales de campo en inteligencia de producto. El resultado son tres a cinco declaraciones de trabajo validadas, no una lista de funcionalidades.

Lo que cubre la sesión: CS Ops extrae los datos de retroalimentación del trimestre por tema. VP CS presenta dos o tres declaraciones de trabajo candidatas con verbatims de apoyo. Producto hace preguntas aclaratorias sobre el contexto de situación y las restricciones. El grupo valida si cada candidata cumple el umbral de tres verbatims y aplica la ponderación por ARR. La sesión termina con un mapa de trabajos priorizado que alimenta la revisión trimestral de retroalimentación.

El cambio de etiquetado que lo hace posible: los CSMs necesitan etiquetar las notas de llamadas con el tipo de situación en el momento de la captura. No de forma retroactiva. Cuatro etiquetas de situación cubren el 80% de los trabajos relevantes para CS: informes ejecutivos, incorporación de equipos, flujo de trabajo entre equipos y reunión en vivo con el cliente. Estas son las situaciones desencadenantes que aparecen con mayor frecuencia en la extracción JTBD de alta señal.

Cuántos trabajos por trimestre: tres a cinco declaraciones de trabajo validadas es el volumen correcto. Más de cinco satura la conversación sobre la hoja de ruta. Menos de tres sugiere que el proceso de extracción no está extrayendo de suficientes fuentes de datos.

Integración con el resto del pipeline de VoC

JTBD se sitúa en un nivel de abstracción más alto que las solicitudes de funcionalidad. Alimenta la estrategia de la hoja de ruta, no el sprint backlog. Esta es una distinción crítica.

Las solicitudes de funcionalidad son datos de entrada para el backlog. Responden a "¿qué capacidad específica quieren los clientes?". Las declaraciones de trabajo son datos de entrada para la estrategia. Responden a "¿qué progreso intentan hacer los clientes?". Los equipos de producto necesitan ambos, pero deberían enrutarse de manera diferente. Las solicitudes de funcionalidad van al pipeline de VoC que alimenta el product backlog. Los mapas de trabajos van a la conversación de estrategia de hoja de ruta: específicamente a la revisión trimestral de retroalimentación del cliente, donde VP CS y Head of Product toman decisiones de priorización a nivel de capacidad.

Cuando CS lleva un mapa de trabajos a la revisión trimestral de retroalimentación del cliente, cambia la naturaleza de la conversación. En lugar de "¿cuál de estas 20 solicitudes de funcionalidad deberíamos construir?", la pregunta se convierte en "¿cuál de estos cinco trabajos deberíamos resolver el próximo trimestre?". Producto puede responder a las declaraciones de trabajo con una gama más amplia de soluciones. Y el paso de cuantificación de retroalimentación ponderada por ARR garantiza que la priorización de trabajos refleje la realidad comercial, no el volumen de tickets.

La distinción importa porque JTBD y las solicitudes de funcionalidad ponderadas por ARR responden a preguntas diferentes. Las solicitudes de funcionalidad responden a "¿qué quieren los clientes?". JTBD responde a "¿qué intentan lograr los clientes?". Ambas son válidas. Use JTBD cuando la decisión de producto sea sobre inversión en capacidad. Use las solicitudes de funcionalidad ponderadas por ARR cuando la decisión sea sobre funcionalidad específica.

Notas sobre herramientas

No se requiere ninguna herramienta especializada. Una plantilla estructurada en Notion, Confluence o un Google Doc compartido maneja el mapa de trabajos para la mayoría de los equipos del segmento medio. Los campos de la plantilla: situación, resultado deseado, restricción, verbatims de apoyo (mínimo tres), recuento de cuentas, peso de ARR y tipo de datos de origen (nota de llamada / entrevista de abandono / QBR / ticket de soporte).

Las transcripciones de Gong y Chorus son materiales en bruto útiles. Busque por grupos de palabras clave, no por intención, porque la búsqueda de AI en transcripciones aún no identifica la intención de trabajo de manera confiable. Busque los patrones "cuando nosotros", "necesitamos", "no podemos", "tenemos que". Estas frases aparecen con mayor frecuencia en las cláusulas de situación y restricción de las declaraciones de trabajo enterradas en las conversaciones con los clientes.

Gainsight y ChurnZero presentan retroalimentación a nivel de cuenta, lo cual es útil para la ponderación por ARR. Pero no extraen declaraciones de trabajo. Ese es un paso de síntesis humana. Lo que las plataformas de CS ayudan a hacer es extraer los verbatims asociados a un grupo de cuentas específico. Lo que oscurecen es el patrón a nivel de trabajo entre cuentas, porque están diseñadas en torno a registros de cuenta, no a categorías de trabajo.

Diagnóstico: ¿su etiquetado actual soporta la extracción JTBD?

Antes de invertir en una sesión mensual de minería de trabajos, ejecute este diagnóstico. Cinco preguntas:

¿Las notas de llamadas incluyen al menos una cita verbal por problema escalado, o solo paráfrasis del CSM?
¿Los temas de tickets de soporte se etiquetan por tipo de situación, o solo por área de producto?
¿Las entrevistas de salida de abandono preguntan explícitamente "¿qué intentaba lograr?"?
¿Los verbatims de QBR se capturan en un formato de búsqueda, o están enterrados en notas de presentaciones?
¿Se adjunta el ARR a algún registro de retroalimentación antes de que llegue a Producto?

Si responde "no" a tres o más de estas preguntas, el proceso de extracción JTBD producirá material en bruto de baja calidad. Corrija el etiquetado antes de programar la sesión de minería.

El sprint de minería de trabajos de 2 semanas

Para equipos nuevos en JTBD, esta es la forma más rápida de producir su primer mapa de trabajos validado sin reformar el proceso de datos de CS.

Semana 1, días 1-2: Extraiga las notas de entrevistas de abandono del trimestre pasado (todas ellas) y etiquete cada una por tipo de situación. Redacte una declaración de trabajo candidata para cada grupo de dos o más.

Semana 1, días 3-5: Extraiga los tres temas de escalamiento de soporte más importantes del trimestre pasado. Compruebe si cada uno se mapea a una situación ya etiquetada en las entrevistas de abandono. Si es así, fortalezca la declaración de trabajo con los verbatims de soporte.

Semana 2, días 1-2: Extraiga verbatims de QBR de los últimos dos trimestres. Etiquete cualquier declaración de resultado ("queremos usar esto para...") o declaración de restricción ("no podemos hacer esto porque..."). Añada a los grupos de trabajo relevantes.

Semana 2, días 3-5: Finalice tres a cinco declaraciones de trabajo con al menos tres verbatims cada una. Adjunte el peso de ARR y el recuento de cuentas. Preséntelas a tres PMs y pregunte: "¿Esto suena como un problema que la estrategia de nuestro producto debería estar resolviendo?" Si los PMs añaden nuevos verbatims, el trabajo es real. Si objetan con "ya lo estamos resolviendo", pídales que muestren dónde. La brecha entre su respuesta y la evidencia del cliente es donde la puntuación de impacto en el cliente para las decisiones de producto es más útil.

El sprint de 2 semanas produce su primer mapa de trabajos. El proceso de reconocimiento de patrones que se ejecuta de forma continua entre los CSMs es lo que mantiene el mapa de trabajos actualizado entre las sesiones trimestrales.

Preguntas frecuentes

¿Qué es Jobs-to-be-Done (JTBD) en el contexto de los datos de CS?

Jobs-to-be-Done es un marco, desarrollado por Clayton Christensen y operacionalizado por Bob Moesta, que reformula la retroalimentación del cliente desde preferencias declaradas ("quiero exportación masiva") hacia objetivos de progreso subyacentes ("cuando necesito presentar a la dirección, necesito sacar los datos en un formato que mi herramienta de BI pueda leer, sin copiar 300 filas manualmente"). Aplicado a los datos de CS, JTBD es una disciplina de reinterpretación. Convierte las notas de llamadas existentes, las entrevistas de abandono y los verbatims de QBR en declaraciones de trabajo que los equipos de producto pueden usar para decisiones de hoja de ruta a nivel de capacidad en lugar de adiciones a nivel de funcionalidad al backlog.

¿En qué se diferencia una declaración de trabajo JTBD de una historia de usuario?

Una historia de usuario describe una preferencia: "Como usuario, quiero exportación masiva." Una declaración de trabajo JTBD describe una situación, un resultado deseado y una restricción: "Cuando necesito presentar datos de clientes a la dirección trimestralmente, necesito obtener esos datos en un formato que nuestra herramienta de BI pueda leer, sin copiar manualmente 300 filas en una hoja de cálculo." La declaración de trabajo abre el espacio de soluciones. Podría resolverse con exportación, una integración nativa de BI, un endpoint de API o una vista compartible con formato de exportación. La historia de usuario reduce la solución a una funcionalidad específica antes de que el PM haya evaluado todo el rango de opciones.

¿Cuántos verbatims necesita una declaración de trabajo para considerarse validada?

El marco de Extracción JTBD en 5 Pasos requiere al menos tres verbatims de tres cuentas diferentes antes de tratar un trabajo candidato como un patrón validado en lugar de una anécdota de una sola cuenta. Idealmente, esas tres cuentas abarcan diferentes niveles de ARR. Un verbatim enterprise y un verbatim de SMB que describen la misma situación de trabajo tienen más peso de validación que tres cuentas de SMB. Una vez validada, la declaración de trabajo también debe llevar el peso de ARR y el recuento de cuentas antes de entrar en la conversación de producto.

¿Qué fuentes de datos de CS producen el mejor material en bruto para JTBD?

Las entrevistas de salida de abandono son la fuente JTBD de mayor señal: los clientes que despiden al producto describen el trabajo en el que falló con una claridad inusual. Los verbatims de QBR presentan declaraciones de resultado en la cláusula central del formato de trabajo ("queremos que esto sea nuestra única fuente de verdad"). Las notas de llamadas capturan el contexto de situación en la cláusula inicial ("cuando estamos en nuestra reunión de planificación del lunes"). Los picos de tickets de soporte son evidencia negativa de trabajo. Cuando 15 tickets llegan al mismo flujo de trabajo, el producto está fallando en un trabajo para suficientes clientes como para desencadenar frustración activa. Los verbatims de NPS de detractores completan el cuadro: los promotores describen trabajos que el producto hace bien, los detractores describen trabajos en los que está fallando.

¿Por qué falla la extracción JTBD en la práctica y cómo se corrige?

Los tres modos de fallo más comunes son los CSMs que resumen en lugar de citar (eliminando la situación y la restricción en la paráfrasis), el sesgo hacia cuentas pequeñas en los recuentos brutos de tickets (corregido por la ponderación por ARR en el Paso 4) y el sesgo de recencia en las extracciones de datos (corregido extendiendo la ventana de extracción a 12-18 meses, ya que los fallos de trabajo no resueltos persisten más allá de los 90 días). La corrección fundamental es un cambio de etiquetado en el momento de la captura: los CSMs etiquetan las notas de llamadas con uno de cuatro tipos de situación (informes ejecutivos, incorporación de equipos, flujo de trabajo entre equipos, reunión en vivo con el cliente) en lugar de por área de producto. Esto hace que la extracción JTBD retrospectiva sea significativamente más rápida.

¿En qué se diferencia JTBD del análisis de puntos de dolor?

Los puntos de dolor describen fricción: "los informes son lentos." JTBD describe intención: "cuando estoy presentando en vivo a la dirección, necesito recuperar los datos del cliente en menos de cinco segundos, sin perder credibilidad ante una rueda giratoria de carga." El análisis de puntos de dolor lleva a una corrección (mejorar el rendimiento). JTBD lleva a un brief de producto: qué desencadena la necesidad, cómo se ve "bien hecho" y qué hace que la experiencia actual no funcione. Los equipos de producto que reciben declaraciones de trabajo en lugar de listas de puntos de dolor toman decisiones de priorización de mayor calidad porque entienden el contexto del fallo, no solo el síntoma.

¿Cuántas declaraciones de trabajo validadas debería producir un equipo de CS por trimestre?

Tres a cinco declaraciones de trabajo validadas por trimestre es el volumen correcto para la mayoría de los equipos de CS del segmento medio. Menos de tres sugiere que el proceso de extracción no está extrayendo de suficientes fuentes de datos o que la disciplina de etiquetado es demasiado débil para identificar patrones distintos. Más de cinco satura la conversación sobre la hoja de ruta. Los equipos de producto que toman decisiones a nivel de capacidad contra ocho o diez trabajos simultáneamente tienden a diferir todos. Tres a cinco crean la función de forzamiento correcta: suficiente amplitud de patrón para identificar brechas estratégicas reales, suficientemente estrecha para producir decisiones reales en la revisión trimestral de retroalimentación del cliente.

Aprenda más

Tara Minh

Senior Operations & Growth Strategist