Alinhamento entre Customer Success e Produto

Veja como a maioria das solicitações de funcionalidade percorre uma empresa SaaS: um CSM ouve "precisamos de exportação em massa" de um cliente frustrado. O CSM registra na plataforma de CS como uma solicitação de funcionalidade. O PM lê "exportação em massa: 4 contas" no resumo semanal de feedback. Vai para o backlog abaixo de outras 30 solicitações. Seis meses depois, o cliente faz churn. Entrevista pós-saída: "Não conseguíamos extrair nossos dados para executar os relatórios que nossa liderança precisava."

A solicitação de funcionalidade era real. Mas "exportação em massa" era a solução proposta pelo cliente, não o trabalho que ele contratava o produto para fazer. O trabalho real era: quando preciso reportar externamente, preciso extrair dados num formato que meus stakeholders consigam ler, sem ter que copiar e colar linha por linha.

Esse é um problema diferente. Pode ser resolvido por exportação. Ou por um link de dashboard compartilhável. Ou por uma integração nativa com o Salesforce. O time de CS tinha o sinal bruto. Ninguém o traduziu.

Jobs-to-be-Done (JTBD) é a camada de tradução. Não requer nova coleta de dados. É uma disciplina de reinterpretação aplicada aos dados que o CS já possui.

O Que o JTBD Realmente É (e Não É)

O enquadramento original de Clayton Christensen era simples: as pessoas não compram produtos. Elas contratam produtos para realizar um trabalho. O artigo seminal de Christensen na HBR sobre JTBD deixou isso claro: o exemplo do milkshake é famoso. O McDonald's descobriu que os passageiros matutinos contratavam milkshakes para tornar uma viagem monótona mais suportável e se manterem saciados até o almoço, não porque estivessem com fome ou fossem indulgentes. O trabalho definia a estratégia do produto. Milkshakes mais espessos, canudos mais fáceis, vendidos no drive-through.

Bob Moesta, que operacionalizou o JTBD no nível prático, foi além: os trabalhos não são apenas funcionais. Têm um contexto (a situação que desencadeia a necessidade), um resultado desejado (como é quando o trabalho está "feito") e uma restrição (o que o cliente não pode ou não vai fazer). O formato de declaração de trabalho que seu trabalho produziu é o que os times de CS devem usar:

Estrutura da declaração de trabalho:

"Quando [situação], preciso [resultado funcional], sem [restrição]."

Esse não é o formato de user story. "Como usuário, quero exportação em massa" descreve uma preferência. A declaração JTBD descreve uma situação, um resultado e o que torna a abordagem atual inviável. São coisas diferentes, e a diferença importa para as decisões de produto.

O JTBD também não é o mesmo que "pontos de dor". Pontos de dor descrevem fricção. Trabalhos descrevem intenção. Um cliente que diz "os relatórios são lentos" está descrevendo dor. O trabalho subjacente é "quando estou fazendo uma apresentação ao vivo para a liderança, preciso carregar dados do cliente em menos de cinco segundos, sem perder a credibilidade para uma tela de carregamento girando". Ponto de dor: corrija o desempenho. Declaração de trabalho: quais situações desencadeiam a necessidade e como é quando o trabalho é feito bem?

Para conversas entre VP CS e Head of Product, a lente operacional de Moesta é mais útil do que a teórica de Christensen. A questão não é "qual trabalho o nosso produto faz?" É "quais trabalhos os clientes estão realmente contratando-o para fazer, e em quais desses trabalhos estamos falhando?" A pesquisa da McKinsey sobre Customer Success 2.0 faz um ponto paralelo: times de CS que utilizam o conhecimento do cliente para identificar trabalhos não atendidos criam uma retenção mais duradoura do que aqueles focados apenas no gerenciamento de relacionamentos.

Fatos Relevantes: JTBD e Qualidade do Sinal de CS

Segundo o Relatório de Gestão de Produto 2024 da ProductPlan, 72% dos times de produto dizem que o feedback do cliente é um dos três principais inputs para as decisões de roteiro, mas apenas 31% têm um processo estruturado para interpretar esse feedback no nível do trabalho, e não no nível da funcionalidade.

As entrevistas de churn são consistentemente avaliadas como a fonte de dados de CS com maior sinal para extração de JTBD, segundo a pesquisa de benchmark de Customer Success da Gainsight, mas menos de 40% dos times de CS realizam entrevistas de saída estruturadas que perguntam o que o cliente estava tentando realizar.

Times que aplicam ponderação por ARR às declarações de trabalho (não apenas contagens de solicitações de funcionalidades) relatam 2,3 vezes mais alinhamento entre o feedback de CS e os itens do roteiro entregues, segundo a pesquisa State of Product Management do Productboard.

Onde os Dados de CS se Encaixam no Modelo JTBD

Os dados de CS são a matéria-prima mais rica para extração de trabalho na maioria das empresas SaaS. O desafio é que chegam no formato errado. Veja como cada fonte mapeia os componentes do JTBD.

Notas de reunião como contexto de situação. Quando um CSM escreve "o cliente disse que o fluxo de trabalho de relatórios é problemático durante sua reunião de planejamento de segunda-feira", isso é a cláusula de situação: "quando estou conduzindo a reunião de planejamento de segunda-feira". Está enterrada numa nota, mas está lá. Os CSMs capturam o "quando" constantemente. Quase nunca o apresentam como um input de JTBD.

Entrevistas de saída de churn como o sinal de falha de trabalho mais honesto. Quando um cliente faz churn, ele está demitindo o produto de um trabalho. Uma entrevista de saída bem conduzida pergunta: o que você estava tentando realizar que o produto não te ajudou a fazer? O que você vai fazer em vez disso? Essas são informações valiosas para o JTBD. A cláusula de restrição quase sempre aparece em entrevistas de churn: "Eu não conseguia fazer X sem Y", onde Y é o que o produto falhou em fornecer. Times de CS que combinam entrevistas de saída com sinais de sistema de alerta precoce muitas vezes conseguem detectar a falha de trabalho antes do churn, e não depois.

Verbatins de QBR como declarações de resultado disfarçadas. Quando um cliente diz num QBR "queremos que isso se torne nossa única fonte de verdade para dados de clientes", ele está declarando um resultado desejado. Essa é a cláusula do meio da declaração de trabalho. O CSM ouve como uma aspiração. Na verdade é uma definição de trabalho.

Picos de chamados de suporte como evidência negativa de trabalho. Quando 15 chamados chegam numa semana sobre o mesmo fluxo de trabalho, isso é evidência de que o produto está falhando num trabalho para contas suficientes a ponto de gerar frustração ativa. O trabalho não é "corrija o bug". É "entenda qual trabalho todas essas 15 contas estão tentando fazer quando batem nessa parede".

Verbatins de NPS de promotores vs. detratores. Promotores descrevem trabalhos que o produto faz bem. Detratores descrevem trabalhos que o produto está falhando. O contraste entre os dois grupos mapeia diretamente onde o desempenho do trabalho é forte e onde está com problemas. Os dados de tendência do NPS se tornam muito mais acionáveis quando sobrepostos aos sinais de uso do produto e saúde do cliente. Contas com alto uso e NPS em declínio são o grupo mais urgente.

A matéria-prima está lá. A lacuna é o processo de extração que a converte em declarações de trabalho nas quais o produto pode agir.

O Processo de Extração: Do Sinal Bruto à Declaração de Trabalho

Framework Nomeado: A Extração JTBD em 5 Etapas A Extração JTBD em 5 Etapas converte dados brutos de CS em declarações de trabalho validadas usando marcação baseada em situação, elaboração de declarações de trabalho, validação de verbatins de múltiplas contas, ponderação por ARR e entrega de mapa de trabalho ao produto. O framework foi desenvolvido a partir da teoria JTBD original de Clayton Christensen e da operacionalização prática de Bob Moesta, adaptado para times de CS de SaaS de médio porte que precisam de inteligência estruturada de trabalho sem reformular seus processos existentes de dados de CS.

Este é um processo de cinco etapas. Não requer uma ferramenta especializada. Um documento compartilhado funciona.

Etapa 1: Extraia dados de CS por tema, não por solicitação de funcionalidade. Não comece com "o que os clientes pediram?" Comece com "quais situações os clientes continuam descrevendo?" Extraia notas de reunião, chamados de suporte e verbatins de QBR do trimestre anterior e marque-os por tipo de situação, não por área do produto.

Etapa 2: Reescreva cada cluster como uma declaração de trabalho. Pegue o cluster de notas em torno de um tema e escreva uma ou duas declarações de trabalho usando o formato: "Quando [situação], preciso [resultado desejado], sem [restrição]." Não suavize a restrição. É muitas vezes a parte mais importante.

Etapa 3: Valide com três ou mais verbatins de contas diferentes. Uma declaração de trabalho que só pode ser atribuída a uma conta é anedota, não padrão. Você precisa de pelo menos três verbatins de contas diferentes (idealmente de contas em diferentes faixas de ARR) antes de tratá-la como um trabalho validado.

Etapa 4: Vincule peso de ARR e contagem de contas a cada trabalho. "7 contas representando R$420K em ARR estão falhando neste trabalho" é um input de priorização de produto. "7 contas" é apenas uma contagem. O peso de ARR transforma declarações de trabalho em decisões de negócios. A mesma disciplina de quantificação se aplica aqui como no pipeline de feedback mais amplo.

Etapa 5: Entregue um mapa de trabalho, não uma lista de funcionalidades. O output para o produto é um conjunto de declarações de trabalho com verbatins de suporte, peso de ARR e contagem de contas. Não uma lista de solicitações de funcionalidades. Se você entregar ao produto uma lista de funcionalidades, receberá decisões no nível de funcionalidades. Se você entregar um mapa de trabalho, receberá decisões no nível de capacidade.

Análise Rework: Com base em benchmarks de times de CS, os times de produto que recebem mapas de trabalho em vez de listas de funcionalidades durante as sessões trimestrais de feedback tomam decisões de roteiro no nível de capacidade em aproximadamente metade do tempo daqueles que avaliam filas brutas de solicitações de funcionalidades. O formato de declaração de trabalho (situação + resultado + restrição) dá aos PMs o contexto para avaliar trade-offs sem agendar entrevistas de acompanhamento para cada item. O limite de validação de três verbatins também filtra a anedota do padrão, reduzindo a porcentagem de discussões de roteiro consumidas por casos extremos de conta única.

Exemplos Práticos: Antes e Depois

Estes dois exemplos mostram a tradução na prática.

Exemplo 1:

Solicitação de funcionalidade: "Precisamos de exportação em massa."
Declaração de trabalho: "Quando preciso apresentar dados de clientes para nossa equipe de liderança trimestralmente, preciso colocar esses dados em um formato que nossa ferramenta de BI consiga ler, sem ter que copiar manualmente 300 linhas para uma planilha."
Implicação para o produto: a exportação em massa pode resolver isso, mas também uma integração nativa de BI, um endpoint de API ou uma visualização compartilhável com formatação de exportação. A declaração de trabalho abre o espaço de solução.

Exemplo 2:

Solicitação de funcionalidade: "Vocês podem corrigir a lentidão nos relatórios?"
Declaração de trabalho: "Quando estou em uma reunião ao vivo com o cliente e preciso extrair dados de uso para responder a uma pergunta, preciso que o relatório carregue em menos de cinco segundos, sem perder a atenção do cliente para uma tela de carregamento girando."
Implicação para o produto: "corrija a lentidão" é vago. A declaração de trabalho informa ao produto que o gatilho é uma reunião ao vivo, o resultado é manter a atenção do cliente e a restrição é o atraso de carregamento. Esse é um briefing de engenharia muito mais específico.

Exemplo 3:

Verbatim de detrator de NPS: "Não conseguimos gerenciar permissões da forma que o time de segurança de TI exige."
Declaração de trabalho: "Quando integramos uma nova equipe na plataforma, preciso configurar acesso baseado em função que corresponda às nossas políticas de segurança internas, sem ter que pedir ao seu time de suporte para fazer alterações manuais."
Implicação para o produto: a solicitação de funcionalidade implícita aqui é "permissões granulares". A declaração de trabalho revela o contexto (integração), o resultado desejado (conformidade de política em autoatendimento) e a restrição (dependência do suporte do fornecedor).

Exemplo 4:

Entrevista de saída de churn: "Acabamos construindo nossa própria solução porque não conseguíamos encaixar o fluxo de trabalho no nosso processo."
Declaração de trabalho: "Quando lidamos com [fluxo de trabalho específico], precisamos que o sistema se adapte ao nosso processo existente, sem ter que reformular o processo para se encaixar na ferramenta."
Implicação para o produto: essa é uma falha clássica de trabalho "o produto é muito opinado". O cliente contratou o produto para se adequar ao fluxo de trabalho deles. O produto os contratou para se adequar ao fluxo dele. Eles o demitiram.

Onde o JTBD Falha com Dados de CS

A extração de JTBD falha de maneiras previsíveis. Conhecê-las com antecedência evita sessões de síntese desperdiçadas.

CSMs que resumem em vez de citar. Quando um CSM escreve "o cliente quer relatórios melhores", a situação, o resultado e a restrição foram todos removidos. A paráfrase mata a extração de JTBD. A correção de disciplina é simples: as notas de reunião exigem uma citação verbatim por problema escalado, não um resumo. Essa é uma mudança de prática de marcação, não uma mudança de ferramenta.

Viés de contas pequenas. Dez chamados de SMB sobre a mesma funcionalidade vão obscurecer dois verbatins enterprise em uma contagem bruta. Mas se esses dois verbatins enterprise representam R$800K em ARR e os chamados de SMB representam R$50K combinados, a ponderação por ARR na Etapa 4 corrige isso. Não execute a extração de JTBD sem vincular números de ARR.

Viés de recência nas notas de reunião. Um verbatim de QBR de 18 meses atrás sobre um trabalho que o produto estava falhando ainda é evidência, especialmente se o produto não o abordou. Filtrar a extração de trabalho para os últimos 90 dias perde falhas de trabalho persistentes e não resolvidas.

O cliente que descreve sintomas, não intenção. Alguns clientes conseguem articular o trabalho claramente. Outros descrevem apenas o sintoma ("o dashboard não funciona para nós"). Quando o verbatim é apenas sintoma, a etapa de extração é uma hipótese: qual trabalho esse sintoma pode indicar? Essa hipótese precisa de pelo menos três verbatins corroborantes antes de se tornar uma declaração de trabalho validada.

Construindo uma Prática de JTBD na Fronteira CS-Produto

Uma sessão mensal de mineração de trabalho é o cadência operacional certa para a maioria dos times de médio porte. A pesquisa State of Customer Success da TSIA consistentemente constata que práticas estruturadas de feedback (não escaladas ad hoc) são o principal diferenciador entre times de CS que influenciam o roteiro e aqueles que não influenciam. A sessão dura 90 minutos e envolve o VP CS, o Head of Product e um representante do CS Ops. Esta sessão é uma extensão do CS como canal de voz do cliente, a disciplina estruturada que converte sinais de campo em inteligência de produto. O output é de três a cinco declarações de trabalho validadas, não uma lista de funcionalidades.

O que a sessão cobre: o CS Ops extrai os dados de feedback do trimestre por tema. O VP CS apresenta dois a três candidatos de declarações de trabalho com verbatins de suporte. O Produto faz perguntas de esclarecimento sobre contexto de situação e restrições. O grupo valida se cada candidato atende ao limite de três verbatins e aplica a ponderação por ARR. A sessão termina com um mapa de trabalho classificado que alimenta a revisão trimestral de feedback.

A mudança de marcação que torna isso possível: os CSMs precisam marcar as notas de reunião com o tipo de situação no momento da captura. Não retroativamente. Quatro marcações de situação cobrem 80% dos trabalhos relevantes para CS: relatórios para liderança, integração de equipe, fluxo de trabalho entre equipes e reunião ao vivo com o cliente. Essas são as situações de gatilho que aparecem com mais frequência na extração de JTBD de alto sinal.

Quantos trabalhos por trimestre: três a cinco declarações de trabalho validadas é o volume correto. Mais de cinco sobrecarrega a conversa sobre o roteiro. Menos de três sugere que o processo de extração não está puxando de fontes de dados suficientes.

Integração com o Restante do Pipeline de VoC

O JTBD opera em um nível de abstração mais alto do que as solicitações de funcionalidades. Alimenta a estratégia do roteiro, não o backlog do sprint. Essa é uma distinção crítica.

As solicitações de funcionalidades são inputs para o backlog. Respondem à pergunta "qual capacidade específica os clientes querem?" As declarações de trabalho são inputs estratégicos. Respondem à pergunta "qual progresso os clientes estão tentando fazer?" Os times de produto precisam de ambas, mas devem ser roteadas de forma diferente. As solicitações de funcionalidades vão para o pipeline de VoC que alimenta o backlog de produto. Os mapas de trabalho vão para a conversa de estratégia de roteiro: especificamente a revisão trimestral de feedback do cliente, onde o VP CS e o Head of Product tomam decisões de priorização no nível de capacidade.

Quando o CS traz um mapa de trabalho para a revisão trimestral de feedback do cliente, isso muda a natureza da conversa. Em vez de "quais dessas 20 solicitações de funcionalidades devemos construir?", a pergunta se torna "quais desses cinco trabalhos devemos resolver no próximo trimestre?" O produto pode responder a declarações de trabalho com uma gama mais ampla de soluções. E a quantificação de feedback ponderado por ARR garante que a priorização de trabalhos reflita a realidade comercial, não o volume de chamados.

A distinção importa porque o JTBD e as solicitações de funcionalidades ponderadas por ARR respondem a perguntas diferentes. As solicitações de funcionalidades respondem "o que os clientes querem?" O JTBD responde "o que os clientes estão tentando realizar?" Ambas são válidas. Use o JTBD quando a decisão de produto for sobre investimento em capacidade. Use solicitações de funcionalidades ponderadas por ARR quando a decisão for sobre funcionalidade específica.

Notas sobre Ferramentas

Não é necessária nenhuma ferramenta especializada. Um template estruturado no Notion, Confluence ou um Google Doc compartilhado atende ao mapa de trabalho para a maioria dos times de médio porte. Os campos do template: situação, resultado desejado, restrição, verbatins de suporte (mínimo três), contagem de contas, peso de ARR e tipo de fonte de dados (nota de reunião / entrevista de churn / QBR / chamado de suporte).

Transcrições do Gong e do Chorus são materiais brutos úteis. Pesquise por clusters de palavras-chave, não por intenção, porque a pesquisa de IA em transcrições ainda não identifica a intenção de trabalho de forma confiável. Pesquise padrões como "quando nós", "precisamos", "não conseguimos", "temos que". Essas frases aparecem com mais frequência nas cláusulas de situação e restrição de declarações de trabalho enterradas em conversas com clientes.

O Gainsight e o ChurnZero apresentam feedback no nível da conta, o que é útil para a ponderação por ARR. Mas não extraem declarações de trabalho. Essa é uma etapa de síntese humana. O que as plataformas de CS ajudam é na extração dos verbatins associados a um cluster de contas específico. O que elas obscurecem é o padrão de nível de trabalho entre contas, porque são construídas em torno de registros de conta, não de categorias de trabalho.

Diagnóstico: Sua Marcação Atual Suporta a Extração de JTBD?

Antes de investir em uma sessão mensal de mineração de trabalho, execute este diagnóstico. Cinco perguntas:

As notas de reunião incluem pelo menos uma citação verbatim por problema escalado, ou apenas paráfrases do CSM?
Os temas de chamados de suporte são marcados por tipo de situação ou apenas por área do produto?
As entrevistas de saída de churn perguntam explicitamente "o que você estava tentando realizar?"
Os verbatins de QBR são capturados em um formato pesquisável, ou estão enterrados em notas de apresentação?
O ARR está vinculado a algum registro de feedback antes de chegar ao produto?

Se você está respondendo "não" a três ou mais dessas perguntas, o processo de extração de JTBD produzirá matéria-prima de baixa qualidade. Corrija a marcação antes de agendar a sessão de mineração.

O Sprint de Mineração de Trabalho de 2 Semanas

Para times novos no JTBD, esta é a forma mais rápida de produzir seu primeiro mapa de trabalho validado sem reformular seu processo de dados de CS.

Semana 1, dias 1-2: Extraia as notas de entrevistas de churn do trimestre anterior (todas elas) e marque cada uma por tipo de situação. Escreva uma declaração de trabalho preliminar para cada cluster de dois ou mais.

Semana 1, dias 3-5: Extraia os três principais temas de escaladas de suporte do trimestre anterior. Verifique se cada um mapeia para uma situação já marcada nas entrevistas de churn. Se sim, fortaleça a declaração de trabalho com os verbatins de suporte.

Semana 2, dias 1-2: Extraia verbatins de QBR dos últimos dois trimestres. Marque qualquer declaração de resultado ("queremos usar isso para...") ou declaração de restrição ("não conseguimos fazer isso porque..."). Adicione aos clusters de trabalho relevantes.

Semana 2, dias 3-5: Finalize de três a cinco declarações de trabalho com pelo menos três verbatins cada. Vincule peso de ARR e contagem de contas. Apresente a três PMs e pergunte: "Isso soa como um problema que a estratégia do nosso produto deveria estar resolvendo?" Se os PMs adicionarem novos verbatins, o trabalho é real. Se refutarem com "já estamos resolvendo isso", peça para mostrarem onde. A lacuna entre a resposta deles e a evidência do cliente é onde a pontuação de impacto do cliente para decisões de produto é mais útil.

O sprint de 2 semanas produz seu primeiro mapa de trabalho. O processo de reconhecimento de padrões que roda continuamente entre os CSMs é o que mantém o mapa de trabalho atualizado entre as sessões trimestrais.

Perguntas Frequentes

O Que é Jobs-to-be-Done (JTBD) no Contexto de Dados de CS?

Jobs-to-be-Done é um framework, desenvolvido por Clayton Christensen e operacionalizado por Bob Moesta, que reenmoldura o feedback do cliente de preferências declaradas ("quero exportação em massa") para objetivos de progresso subjacentes ("quando preciso apresentar à liderança, preciso extrair dados em um formato que minha ferramenta de BI consiga ler, sem copiar 300 linhas manualmente"). Aplicado aos dados de CS, o JTBD é uma disciplina de reinterpretação. Ele converte notas de reunião existentes, entrevistas de churn e verbatins de QBR em declarações de trabalho que os times de produto podem usar para decisões de roteiro no nível de capacidade, em vez de adições ao backlog no nível de funcionalidade.

Como uma Declaração de Trabalho JTBD Difere de uma User Story?

Uma user story descreve uma preferência: "Como usuário, quero exportação em massa." Uma declaração de trabalho JTBD descreve uma situação, um resultado desejado e uma restrição: "Quando preciso apresentar dados de clientes à liderança trimestralmente, preciso colocar esses dados em um formato que nossa ferramenta de BI consiga ler, sem copiar manualmente 300 linhas para uma planilha." A declaração de trabalho abre o espaço de solução. Pode ser resolvida por exportação, uma integração nativa de BI, um endpoint de API ou uma visualização compartilhável com formatação de exportação. A user story estreita a solução para uma funcionalidade específica antes que o PM tenha avaliado toda a gama de opções.

Quantos Verbatins uma Declaração de Trabalho Precisa para ser Considerada Validada?

O framework de Extração JTBD em 5 Etapas exige pelo menos três verbatins de três contas diferentes antes de tratar um trabalho candidato como padrão validado, em vez de anedota de conta única. Idealmente, essas três contas abrangem diferentes faixas de ARR. Um verbatim enterprise e um verbatim de SMB descrevendo a mesma situação de trabalho têm mais peso de validação do que três contas de SMB. Uma vez validada, a declaração de trabalho também deve ter peso de ARR e contagem de contas antes de entrar na conversa de produto.

Quais Fontes de Dados de CS Produzem o Melhor Material Bruto para JTBD?

As entrevistas de saída de churn são a fonte JTBD com maior sinal: clientes que estão demitindo o produto descrevem o trabalho que ele falhou em fazer com clareza incomum. Os verbatins de QBR apresentam declarações de resultado na cláusula do meio do formato de trabalho ("queremos que isso seja nossa única fonte de verdade"). As notas de reunião capturam o contexto de situação na cláusula inicial ("quando estamos na nossa reunião de planejamento de segunda-feira"). Picos de chamados de suporte são evidências negativas de trabalho. Quando 15 chamados atingem o mesmo fluxo de trabalho, o produto está falhando num trabalho para clientes suficientes a ponto de gerar frustração ativa. Os verbatins de NPS de detratores completam o quadro: promotores descrevem trabalhos que o produto faz bem, detratores descrevem trabalhos em que está falhando.

Por Que a Extração de JTBD Falha na Prática e Como é Corrigida?

Os três modos de falha mais comuns são CSMs que resumem em vez de citar (removendo situação e restrição na paráfrase), viés de contas pequenas em contagens brutas de chamados (corrigido pela ponderação por ARR na Etapa 4) e viés de recência nos dados extraídos (corrigido ampliando a janela de extração para 12 a 18 meses, pois falhas de trabalho não resolvidas persistem além de 90 dias). A correção fundamental é uma mudança de marcação no momento da captura: os CSMs marcam as notas de reunião com um dos quatro tipos de situação (relatórios para liderança, integração de equipe, fluxo de trabalho entre equipes, reunião ao vivo com o cliente) em vez de por área do produto. Isso torna a extração retroativa de JTBD significativamente mais rápida.

Como o JTBD Difere da Análise de Pontos de Dor?

Os pontos de dor descrevem fricção: "os relatórios são lentos." O JTBD descreve intenção: "quando estou fazendo uma apresentação ao vivo para a liderança, preciso carregar dados do cliente em menos de cinco segundos, sem perder credibilidade para uma tela de carregamento girando." A análise de pontos de dor leva a uma correção (melhore o desempenho). O JTBD leva a um briefing de produto: o que desencadeia a necessidade, como é quando o trabalho é feito bem e o que torna a experiência atual inviável. Times de produto que recebem declarações de trabalho em vez de listas de pontos de dor tomam decisões de priorização de maior qualidade porque entendem o contexto da falha, não apenas o sintoma.

Quantas Declarações de Trabalho Validadas um Time de CS Deve Produzir por Trimestre?

De três a cinco declarações de trabalho validadas por trimestre é o volume certo para a maioria dos times de CS de médio porte. Menos de três sugere que o processo de extração não está puxando de fontes de dados suficientes ou que a disciplina de marcação é fraca demais para identificar padrões distintos. Mais de cinco sobrecarrega a conversa sobre o roteiro. Times de produto que tomam decisões no nível de capacidade contra oito ou dez trabalhos simultaneamente tendem a adiar todos. De três a cinco cria a força de forcing certa: amplitude de padrão suficiente para identificar lacunas estratégicas reais, estreita o suficiente para produzir decisões reais na revisão trimestral de feedback do cliente.

Saiba Mais

Tara Minh

Senior Operations & Growth Strategist