Alinhamento entre Customer Success e Produto

Quase toda equipe de CS tem alguma versão das duas práticas: um conjunto de conversas no advisory board em que clientes seniores opinam sobre a direção estratégica, e uma prática mais informal de envolver clientes quando algo novo está sendo desenvolvido. O problema é que muito poucas equipes traçam uma linha clara entre elas. Um cliente que participou do advisory board do último trimestre é convocado para uma revisão de protótipo porque está engajado. Um PM que quer insumo de design agenda uma "sessão de advisory" com cinco contas e as conduz por um mockup no Figma. O vocabulário se mistura, as expectativas se misturam e os resultados se misturam com elas.

A distinção é operacional, não filosófica. Customer councils e advisory boards tratam da direção estratégica. Envolvem um grupo mais amplo de clientes, ocorrem em cadência trimestral e produzem insumos sobre para onde o produto deve ir nos próximos 12 a 18 meses. A cocriação é sobre uma funcionalidade específica. Envolve 3 a 6 contas, ocorre ao longo de 4 a 8 semanas e produz insumos diretos sobre como essa funcionalidade deve funcionar no nível de desenvolvimento. O compromisso de tempo, a expectativa do cliente, o formato da sessão e o que conta como sucesso são todos diferentes.

Confundi-los cria dois modos de falha. O advisory board é posicionado como uma influência de cocriação que não possui de fato, gerando dívida de expectativa quando o roteiro segue direções que os participantes não aprovaram. O engajamento de cocriação é inflado numa conversa estratégica, expandindo o escopo para um território que nenhuma funcionalidade isolada consegue satisfazer. Ambas as falhas custam capital de relacionamento, e ambas são evitáveis com disciplina operacional.

Este artigo é sobre como conduzir a cocriação. O artigo 11 cobre os advisory boards. A linha entre eles é o que este artigo começa por traçar claramente.

O Modelo de Operações de Cocriação com Clientes definido aqui é explicitamente distinto dos customer advisory boards (artigo 11 desta coleção), que tratam da direção estratégica para um grupo mais amplo em cadência trimestral. A cocriação é operacional, não estratégica: molda uma funcionalidade específica no pipeline de desenvolvimento com 3 a 6 contas ao longo de 4 a 8 semanas. O modelo tem quatro disciplinas operacionais: (1) disciplina de escopo: a cocriação cobre uma funcionalidade, não uma direção de produto; (2) disciplina de coorte: 3 a 6 contas representando a versão mais aguda do problema, não as mais leais ou maiores; (3) disciplina de papéis: Produto lidera a decisão de desenvolvimento, CS facilita a sessão, Engenharia observa; (4) disciplina de expectativa: os clientes cocriaram o quê, os engenheiros são responsáveis pelo como, Produto tem a decisão final. Toda falha de cocriação remonta ao rompimento de uma dessas quatro disciplinas.

Advisory Board versus Cocriação: A Distinção Necessária

A pesquisa da McKinsey sobre a construção de organizações B2B centradas no cliente mostra que empresas que confundem insumo de advisory estratégico com cocriação de funcionalidades específicas acabam com dados de clientes que não respondem com precisão nem à questão estratégica nem à questão de desenvolvimento. A distinção é operacional, não filosófica, e a confusão é comum o suficiente para valer a pena ser declarada com precisão.

Customer advisory boards reúnem um grupo mais amplo, tipicamente de 8 a 15 representantes seniores de clientes, para fornecer insumos sobre a direção estratégica. As perguntas são: para onde devemos levar o produto no próximo ano? Que problemas você está antecipando que ainda não estamos resolvendo? Onde nossos concorrentes têm vantagens que você gostaria que fechássemos? Os advisory boards são prospectivos e amplos. Não moldam funcionalidades individuais. Moldam a visão de produto que impulsiona o roteiro. A cadência é trimestral. O resultado é contexto estratégico para a equipe de PM.

A cocriação reúne um pequeno coorte (3 a 6 contas) para fornecer insumos operacionais sobre uma funcionalidade específica que já está no pipeline de desenvolvimento. As perguntas são: este fluxo de trabalho corresponde a como você realmente realiza essa tarefa? Em que ponto nesse fluxo você encontra um problema? O que tornaria isso útil o suficiente para mudar como sua equipe trabalha? A cocriação é presente e focada. Molda uma funcionalidade específica que está sendo desenvolvida agora. A cadência é intensiva ao longo de um engajamento curto. O resultado é feedback acionável no nível de desenvolvimento.

Quando você precisa de cocriação versus quando o insumo de advisory é suficiente. Se a pergunta é "devemos desenvolver essa categoria de capacidade?", o insumo de advisory é suficiente. Se a pergunta é "essa implementação específica dessa capacidade é algo que nossos usuários-alvo conseguem realmente usar?", você precisa de cocriação. O insumo de advisory diz se você está construindo na direção certa. A cocriação diz se o que você está construindo vai realmente funcionar.

A decisão prática: a cocriação é indicada quando há ambiguidade de design suficiente numa funcionalidade específica que errar significaria reconstruir partes significativas dela após o lançamento, e quando você tem clientes que têm o caso de uso específico e a expertise de domínio para avaliar uma solução proposta.

Principais Fatos: Resultados de Programas de Cocriação

Funcionalidades desenvolvidas com sessões estruturadas de cocriação com clientes têm taxas de adoção 41% maiores em 90 dias pós-GA em comparação com funcionalidades desenvolvidas apenas com insumo de advisory (Pendo, 2024).

Sessões de cocriação facilitadas pelo PM produzem 35% menos feedback crítico do que sessões facilitadas pelo CS, porque os participantes suavizam as críticas quando a pessoa que desenvolveu o que estão avaliando está na sala (UserTesting, 2024).

Engajamentos de cocriação que terminam sem uma sessão formal de encerramento têm taxas 2,1 vezes maiores de decepção de expectativa relatada pelos participantes no lançamento do GA, em comparação com engajamentos que incluem uma chamada de debriefing estruturado (Gainsight, 2024).

Quem é Convidado para a Cocriação (e Quem Não É)

Os critérios de seleção são mais específicos do que para um programa beta ou um advisory board, e o custo de errar neles é maior. Uma seleção ruim para um advisory board produz insumo estratégico vago. Uma seleção ruim para a cocriação produz decisões de desenvolvimento baseadas no caso de uso errado.

"Funcionalidades desenvolvidas com sessões estruturadas de cocriação com clientes têm taxas de adoção 41% maiores em 90 dias pós-GA em comparação com funcionalidades desenvolvidas apenas com insumo de advisory." (Pendo, 2024)

O filtro de agudeza do problema. O primeiro critério: esta conta tem o problema específico para o qual a funcionalidade está sendo desenvolvida, e ela o tem de forma aguda o suficiente para fornecer feedback significativo sobre uma solução proposta? Não "eles encontram a categoria geral do problema", mas "este problema é uma restrição operacional real para eles agora?" Contas que têm o problema teoricamente ("podemos ter esse problema se nossa equipe crescer") não conseguem avaliar uma solução com a mesma especificidade de contas que o têm operacionalmente, todos os dias.

A porta de saúde de CS. Apenas pontuações de saúde verdes ou amarelas. Cocriação com contas vermelhas é extração, não colaboração. Um cliente gerenciando uma crise de suporte ativa, um conflito de orçamento ou uma implementação travada não tem condições de dar feedback honesto sobre o produto. Está gerenciando sua própria situação. E se a experiência de cocriação for frustrante (o que o trabalho de funcionalidades em estágio inicial frequentemente é), ela agrava um relacionamento já estressado. O glossário de alinhamento CS & Produto define os níveis de pontuação de saúde e o vocabulário compartilhado que CS e Produto precisam para aplicar essa porta de forma consistente.

O filtro de capacidade. Este cliente tem a expertise de domínio para avaliar se uma solução proposta realmente resolve o problema? Um cliente que tem o problema mas não tem a sofisticação técnica ou operacional para distinguir "este fluxo de trabalho não se encaixa no nosso processo" de "este fluxo de trabalho é confuso" é um colaborador limitado de cocriação. Você precisa de contas onde o profissional que participa da sessão possa explicar exatamente como faz atualmente o que a funcionalidade vai substituir, porque esse entendimento é o que torna o feedback sobre a solução proposta preciso em vez de impressionístico.

O teto do coorte. 3 a 6 contas. Não é uma diretriz suave. É a realidade operacional do que um PM consegue gerenciar e com o que um CSM consegue trabalhar de forma significativa ao longo de um engajamento de 4 a 8 semanas. Seis já é ambicioso. Oito se torna um comitê. Com 10, você está conduzindo um beta, não um engajamento de cocriação, e perdeu a intimidade que torna o feedback de cocriação diferente dos dados de uma pesquisa.

O enquadramento do convite importa tanto quanto a seleção. "Ajude-nos a desenvolver isso corretamente" é o enquadramento certo. "Dê-nos sua lista de desejos" é o errado. O convite deve ser específico sobre o escopo da funcionalidade, explícito sobre o compromisso de tempo (tipicamente 3 a 5 sessões ao longo de 4 a 8 semanas, cada uma de 60 a 90 minutos), claro de que se trata de insumo de design em vez de influência sobre o roteiro, e honesto de que a decisão final de desenvolvimento pertence a Produto, não ao coorte de cocriação. Com o coorte certo estabelecido, a estrutura do engajamento determina se as sessões produzem sinal real.

Estruturando o Engajamento de Cocriação

Um engajamento de cocriação que dura mais de 8 semanas geralmente sinaliza que houve expansão de escopo. Um engajamento de cocriação com mais de 5 sessões geralmente sinaliza que o problema não estava bem definido o suficiente para começar. A estrutura abaixo se aplica a um engajamento bem delimitado.

Pré-trabalho: Produto compartilha a declaração do problema e as restrições. Antes da primeira sessão, os participantes recebem um briefing escrito do PM: o problema sendo resolvido, por que a abordagem proposta foi escolhida e quais restrições não são negociáveis (limitações técnicas, requisitos regulatórios, decisões de arquitetura existentes). Os clientes não cocriaram no vácuo. Eles precisam de contexto sobre o que é possível antes de poderem fornecer insumos significativos sobre o que é melhor.

Sessão 1: Validação do problema. O propósito desta sessão não é mostrar uma solução ao cliente. É validar que o entendimento de Produto sobre o problema corresponde à experiência vivida do cliente. O PM apresenta a declaração do problema. O cliente reage: "isso descreve com precisão o que você está enfrentando?" Discrepâncias aqui (e quase sempre há algumas) são o resultado mais valioso de todo o engajamento. Elas aparecem antes que qualquer trabalho de desenvolvimento esteja definido.

Sessão 2: Feedback sobre o protótipo. O PM apresenta um protótipo inicial ou um mockup de fluxo de trabalho. O trabalho do cliente: percorrê-lo como o usaria de fato, narrando suas reações. Não "você gosta disso?" mas "me mostre o que você faria a seguir." O CSM captura pontos de atrito, momentos de confusão e alternativas que o cliente sugere espontaneamente. Engenharia observa e toma notas, mas não apresenta, defende ou explica nada. Estão lá para ouvir diretamente, não para justificar decisões.

Sessão 3: Iteração da solução. O PM apresenta o protótipo revisado incorporando o feedback da sessão 2. O propósito: confirmar que as mudanças abordaram o atrito, identificar novos problemas introduzidos pelas mudanças e começar a convergir para um design que funcione. Esta sessão é tipicamente mais curta do que a sessão 2. Se a iteração foi boa, há menos a questionar.

Sessões 4 a 5 (se necessário): Aprovação final e casos extremos. Essas sessões são para participantes com casos de uso complexos o suficiente que as sessões 1 a 3 não resolveram completamente como a funcionalidade funciona para eles. Nem todo coorte precisa das sessões 4 e 5. Se um engajamento de três sessões produz sinal claro o suficiente para finalizar o design, adicionar sessões por causa da estrutura desperdiça o tempo dos participantes e arrisca corroer a boa vontade sobre a qual o programa é construído.

Regras de presença. O trabalho do MIT Media Lab sobre cocriação de tecnologia baseada em comunidade confirma que o valor da cocriação vem especificamente do "co" (a própria estrutura de participação, não apenas os resultados), razão pela qual o modelo de presença do fornecedor aqui separa os papéis em vez de colapsá-los numa única presença da equipe de produto. Do fornecedor: PM lidera, CSM facilita, Engenharia observa. O PM está lá para ouvir o caso de uso e tomar decisões de desenvolvimento em tempo real sobre qual feedback incorporar. O CSM está lá para gerenciar a dinâmica da sessão: envolver participantes quietos, redirecionar participantes que estão redesenhando o produto inteiro em vez da funcionalidade específica e capturar sinais de relacionamento que o PM pode perder. Engenharia está lá para ouvir o caso de uso na linguagem do cliente, não para apresentar restrições técnicas ou defender escolhas de implementação.

Do cliente: o profissional que vive o problema todos os dias, não o patrocinador executivo. Um executivo que fica sabendo do problema pela sua equipe é um defensor estratégico útil. É um participante de cocriação ruim porque não tem a especificidade operacional para avaliar se uma solução proposta funciona no nível do fluxo de trabalho. O participante certo consegue dizer "quando faço essa tarefa, faço desta forma, e o fluxo proposto falha no passo três por causa de X."

O Papel de CS nas Sessões de Cocriação

"Sessões de cocriação facilitadas pelo PM produzem 35% menos feedback crítico do que sessões facilitadas pelo CS, porque os participantes suavizam as críticas quando a pessoa que desenvolveu o que estão avaliando está na sala." (UserTesting, 2024)

CS facilita; CS não defende. Essa é a linha mais difícil de manter. O trabalho do CSM numa sessão de cocriação não é fazer o cliente se sentir bem sobre o produto ou proteger o relacionamento do feedback crítico. É identificar o sinal honesto: fazendo perguntas de acompanhamento quando o feedback do cliente é vago, extraindo insatisfação que o cliente está expressando com educação em vez de diretamente, e não suavizando a transcrição.

Gerenciando o participante dominante. Quase todo coorte de cocriação tem um: o cliente que é engajado, articulado e falante, e cujas opiniões abafam os outros participantes. O trabalho de facilitação do CSM é redistribuir ativamente o tempo de fala: "Ouvimos muito da [conta A] sobre isso. [Conta B], como isso se encaixa no fluxo de trabalho da sua equipe?" A voz mais alta numa sessão de cocriação raramente é a mais representativa.

Capturando feedback em formato de saída estruturado. O produto de cada sessão não é uma transcrição nem um resumo. É um registro de feedback estruturado que Produto pode referenciar diretamente ao tomar decisões de desenvolvimento. Formato: ponto de atrito (específico, contextualizado no fluxo de trabalho) / qual conta o levantou / severidade (bloqueador / significativo / menor) / correção sugerida pelo cliente (se oferecida) / leitura inicial do PM (incorporar / recusar / investigar mais). Esse formato é acordado antes do início do engajamento. Os CSMs não o improvisam sessão a sessão. O playbook de captura sistemática de feedback fornece a taxonomia completa para traduzir notas de sessão em registros prontos para o backlog.

Sinalizando a expansão de escopo em tempo real. Quando um participante começa a redesenhar o produto inteiro em vez da funcionalidade específica ("já que estamos falando sobre isso, e se você também reconstruísse como o dashboard inteiro funciona?"), o CSM redireciona: "Esse é um insumo mais amplo e válido, e vamos capturá-lo separadamente. Para a sessão de hoje, queremos nos manter focados no [escopo específico da funcionalidade] para podermos ir fundo o suficiente para ser útil." Esse redirecionamento é responsabilidade do CSM, não do PM. A presença do PM na sala torna mais difícil para ele redirecionar sem parecer defensivo.

Os Pontos Inegociáveis de Produto na Cocriação

A decisão de desenvolvimento pertence a Produto. Sempre. A cocriação é um insumo sobre como uma funcionalidade é desenvolvida, não uma delegação da decisão de desenvolvimento a um comitê de clientes. Isso precisa ser declarado no enquadramento do convite e reforçado na abertura de cada sessão. "Queremos sua perspectiva sobre se essa abordagem funciona para o seu fluxo de trabalho. A decisão final sobre o que desenvolvemos é nossa, e seremos transparentes com você sobre quais insumos estamos incorporando e por quê."

Restrições técnicas não são negociáveis e devem ser declaradas antecipadamente. Sessões de cocriação em que os participantes projetam sua solução ideal e o PM depois precisa explicar por que nenhuma parte dela é tecnicamente possível desperdiçam o tempo de todos e criam dívida de expectativa. Antes da sessão 1, o briefing escrito deve declarar claramente: "Aqui está o que está tecnicamente definido neste design. Aqui está onde você tem influência genuína." Clientes que entendem o espaço de restrições projetam dentro dele. Clientes que não entendem projetam ao redor dele, produzindo feedback que não é acionável.

Clientes cocriaram o quê; engenheiros e PMs são responsáveis pelo como. Um participante pode dizer "preciso conseguir reatribuir a propriedade de uma tarefa em massa sem perder o rastro de auditoria." Isso é um quê. Como isso é implementado tecnicamente (qual modelo de dados, qual padrão de API, qual componente de UI) é uma decisão de engenharia. A linha entre quê e como é onde a disciplina de escopo vive.

Quando participantes de cocriação discordam entre si. Acontece em quase todo engajamento com múltiplas contas, porque as contas têm fluxos de trabalho diferentes, restrições diferentes e definições diferentes de "óbvio." Produto arbitra. Não fazendo uma média do desacordo ("vamos fazer uma versão que satisfaça parcialmente ambos"), mas tomando uma decisão explícita: "Ouvimos dois modelos de fluxo de trabalho diferentes aqui. Vamos desenvolver para o modelo da [conta A] porque se mapeia mais proximamente ao nosso ICP principal. Para a [conta B], veja como sugerimos adaptar seu fluxo de trabalho à funcionalidade." A arbitragem transparente é melhor do que fingir que o desacordo não existe.

Gestão de Expectativas ao Longo do Processo

O risco de expectativa na cocriação é diferente do risco num advisory board. Participantes do advisory board esperam influência estratégica. Participantes de cocriação esperam que seu fluxo de trabalho específico seja refletido no que é lançado. Quando a funcionalidade final não parece exatamente com o que eles projetaram, os participantes sentem que a cocriação foi uma encenação em vez de uma colaboração genuína.

Na sessão 1, declare o modelo explicitamente. "Você está aqui porque tem a versão mais aguda do problema que estamos resolvendo e a expertise de domínio para nos dizer se nossa solução proposta realmente funciona. Seu insumo informará diretamente o que desenvolvemos. Mas você não é o único insumo. Também estamos trabalhando dentro de restrições técnicas, equilibrando múltiplos casos de uso e tomando decisões de produto que podem não refletir completamente a preferência de nenhuma conta individual. Seremos transparentes com você sobre o que estamos incorporando e o que não estamos, e por quê."

Como lidar com um participante cujas ideias não foram incorporadas. O CSM faz a abordagem proativamente, antes que a funcionalidade seja lançada. "Discutimos [insumo específico] na sessão 3. Em última análise, decidimos não implementá-lo neste lançamento porque [razão específica]. Quero que você saiba diretamente, antes de ver a funcionalidade no GA." Essa conversa, feita antes que o participante descubra a lacuna por conta própria, é um ato que preserva o relacionamento. Feita depois, parece controle de danos.

A chamada de debriefing não é opcional. A pesquisa da HBR sobre como obter feedback honesto dos clientes estabelece que o encerramento de um engajamento de feedback é onde a confiança é confirmada ou rompida. Os clientes precisam ver que seu insumo foi levado a sério, não apenas processado. Todo engajamento de cocriação termina com uma chamada de debriefing de 30 minutos em que o PM conduz os participantes de cocriação por: o que entrou no desenvolvimento, o que não entrou, e por quê. Este é o encerramento formal do engajamento. Participantes que não recebem um debriefing (que experimentam o engajamento como "demos nosso tempo e então a funcionalidade simplesmente foi lançada") são a fonte do problema de reputação da cocriação que torna futuras captações mais difíceis.

Quando a Cocriação Dá Errado

Três modos de falha cobrem a maioria do que dá errado, e cada um tem uma correção específica.

Expansão de escopo: clientes redesenhando o produto inteiro. A sessão derivou da funcionalidade específica para uma conversa sobre toda a experiência do produto. Causa: o enquadramento do convite foi amplo demais ("ajude-nos a melhorar o produto"), o CSM não redirecionou cedo o suficiente, ou o PM começou a fazer perguntas que abriram um escopo mais amplo ("e o que mais tornaria esse tipo de trabalho melhor para você?"). Correção: reafirmar o escopo no início de cada sessão, treinar o CSM para redirecionar de forma visível e sem se desculpar, e manter as perguntas do PM rigorosamente ligadas à funcionalidade sendo cocriada.

Captura pelo relacionamento: PM concorda com tudo. O PM está tão focado em manter um relacionamento positivo com o participante que sinaliza concordância com insumos que não tem intenção de implementar, para evitar conflito na sala. Isso produz dois problemas: participantes que se sentem validados durante as sessões e traídos no GA, e um registro de feedback que representa excessivamente compromissos que não existem. Correção: o CSM (não o PM) gerencia o tom da sessão. O trabalho do PM é ouvir e registrar, não responder afirmativamente a cada sugestão. O formato de saída estruturado (incorporar / recusar / investigar) força o reconhecimento explícito de quais insumos estão e não estão sendo atendidos.

Viés do coorte: participantes não são representativos do ICP mais amplo. O coorte de cocriação foi selecionado porque estava disponível e engajado, não porque representa o caso de uso-alvo. O feedback reflete seu fluxo de trabalho específico, que é um caso extremo, não o caso de uso central. Funcionalidades desenvolvidas para essa especificação funcionam bem para os participantes de cocriação e mal para a base geral de clientes. Correção: aplicar o filtro de agudeza do problema estritamente na seleção. Se as contas que têm o problema mais agudamente não estão saudáveis o suficiente ou disponíveis o suficiente para participar, adie a cocriação até que candidatos melhores sejam identificáveis. Não substitua com participantes que atendam melhor aos critérios de relacionamento do que aos de caso de uso.

Após a Cocriação: Encerrando o Engajamento

Reconhecimento dos participantes sem prometer demais acesso futuro. Os participantes de cocriação investiram tempo e confiança. O encerramento do engajamento deve reconhecer isso especificamente: "Você dedicou [N sessões / N horas] do seu tempo ao longo de [N semanas]. As [características específicas do que foi lançado] refletem o que você nos disse diretamente. Obrigado." Esse é o nível certo de reconhecimento. Prometer demais ("vamos garantir que você seja a primeira conta que consultamos para a próxima funcionalidade nessa área") cria dívida de captação no próximo programa de cocriação antes mesmo de começar.

Os participantes de cocriação veem a funcionalidade final antes do GA. Isso não é negociável. Participantes que contribuíram com 4 sessões e então veem o anúncio do GA ao mesmo tempo que todos os outros clientes sentem que seu insumo foi absorvido, não honrado. A sequência: o PM compartilha a funcionalidade final com os participantes de cocriação 1 a 2 semanas antes do GA. Os participantes têm a chance de sinalizar algo crítico que foi perdido. Então é lançado para todos. A estrutura da chamada de debriefing, o resumo escrito e o retorno em 48 horas estão todos descritos no artigo fechamento do ciclo de feedback com clientes. Essa cadência se aplica aqui exatamente como nos programas beta e de advisory.

Retrospectiva antes da próxima cocriação. O debriefing do engajamento não é apenas para os participantes. É para a equipe interna. O que o formato da sessão produziu que foi útil? Qual formato de feedback funcionou? As contas certas foram selecionadas? O que mudaríamos no enquadramento do convite? Uma retrospectiva interna de 60 minutos após cada engajamento de cocriação melhora a qualidade do próximo e reduz a taxa de falhas ao longo do tempo.

Considerações para o Mercado de Médio Porte

A cocriação consome recursos. Uma empresa de médio porte sem uma função dedicada de pesquisa de UX ainda pode conduzi-la, mas precisa ajustar as expectativas. A versão mínima viável: um PM, um CSM, três contas, três sessões, sem necessidade de protótipo no Figma. Um mockup inicial de fluxo de trabalho descrito em linguagem simples funciona. O PM analisa a saída estruturada, o CSM facilita, e o resultado é específico o suficiente para informar o desenvolvimento.

"Engajamentos de cocriação que terminam sem uma sessão formal de encerramento têm taxas 2,1 vezes maiores de decepção de expectativa relatada pelos participantes no lançamento do GA, em comparação com engajamentos que incluem uma chamada de debriefing estruturado." (Gainsight, 2024)

O que não escala para baixo: a chamada de debriefing, os critérios de seleção por agudeza do problema e a definição explícita de expectativas na sessão 1. Esses são os elementos essenciais. Todo o restante pode ser simplificado. Acompanhar quais participantes de cocriação estão prontos para ativação após o GA é onde a identificação de barreiras à adoção assume. A equipe de cocriação já conhece os pontos de atrito. A equipe de pós-venda precisa desse conhecimento para acelerar a ativação para a base mais ampla.

Análise Rework: Os programas de cocriação são operacionalmente leves (3 a 6 contas, 3 a 5 sessões, 4 a 8 semanas), mas exigem rastreamento rigoroso dos resultados das sessões, pontuações de saúde dos participantes e decisões de feedback em múltiplas conversas simultâneas. Equipes de CS de médio porte que conduzem cocriação no Rework podem usar o rastreamento de tarefas em nível de projeto para gerenciar a estrutura das sessões, vincular registros de feedback à saúde da conta e identificar o filtro de agudeza do problema junto com os dados do ICP sem construir um sistema separado de gestão de pesquisa. O formato de feedback estruturado (ponto de atrito / severidade / decisão do PM) se mapeia diretamente ao modelo de tarefas e comentários do Rework.

Perguntas Frequentes

O que é o Modelo de Operações de Cocriação com Clientes?

O Modelo de Operações de Cocriação com Clientes é a estrutura operacional para conduzir a cocriação de funcionalidades com 3 a 6 clientes selecionados ao longo de 4 a 8 semanas. É explicitamente distinto dos customer advisory boards, que fornecem direção estratégica a um grupo mais amplo trimestralmente. A cocriação molda uma funcionalidade específica no pipeline de desenvolvimento. O modelo opera em quatro disciplinas: escopo (uma funcionalidade, não uma direção de produto), coorte (seleção por agudeza do problema, não por lealdade), papéis (CS facilita, Produto lidera a decisão de desenvolvimento, Engenharia observa) e expectativa (os clientes cocriaram o quê, os engenheiros são responsáveis pelo como).

Como a cocriação é diferente de um customer advisory board?

Os advisory boards reúnem 8 a 15 clientes seniores trimestralmente para dar insumos sobre a direção estratégica: para onde o produto deve ir nos próximos 12 a 18 meses. A cocriação reúne 3 a 6 contas ao longo de 4 a 8 semanas para fornecer feedback no nível de desenvolvimento sobre uma funcionalidade específica já no pipeline. O insumo de advisory responde à pergunta "devemos desenvolver essa categoria de capacidade?" A cocriação responde "essa implementação específica vai realmente funcionar para nossos usuários-alvo?" Confundir os dois produz fadiga de advisory e expansão de escopo na cocriação.

Quem deve ser convidado para as sessões de cocriação?

Os critérios de seleção têm três portas: (1) agudeza do problema: a conta tem o problema específico que a funcionalidade está resolvendo, de forma operacional e aguda, não teórica; (2) pontuação de saúde: apenas verde ou amarela. Contas vermelhas estão gerenciando sua própria situação e não conseguem avaliar uma nova funcionalidade objetivamente; (3) capacidade: o profissional que participa consegue descrever exatamente como realiza atualmente a tarefa que a funcionalidade vai substituir, porque essa especificidade operacional é o que torna seu feedback preciso em vez de impressionístico. O teto do coorte é 6 contas. Acima disso, você está conduzindo um beta, não um engajamento de cocriação.

Por que o CS deve facilitar as sessões de cocriação, não o Produto?

Sessões de cocriação facilitadas pelo PM produzem 35% menos feedback crítico do que sessões facilitadas pelo CS, porque os participantes suavizam as críticas quando a pessoa que desenvolveu o que estão avaliando está na sala (UserTesting, 2024). Os facilitadores de CS criam separação entre a camada de relacionamento e a camada de avaliação. O trabalho do CSM é extrair insatisfação que os participantes estão expressando com educação, redirecionar a expansão de escopo em tempo real e capturar o registro de feedback estruturado, sem suavizar a transcrição. O PM observa e toma decisões de desenvolvimento em tempo real. Engenharia observa e ouve o caso de uso na linguagem do cliente.

O que acontece quando os participantes de cocriação discordam entre si?

Produto arbitra. Não fazendo uma média do desacordo nem fingindo que não existe, mas tomando uma decisão explícita: "Ouvimos dois modelos de fluxo de trabalho diferentes. Vamos desenvolver para o modelo da conta A porque se mapeia mais proximamente ao nosso ICP principal. Para a conta B, veja como sugerimos adaptar seu fluxo de trabalho à funcionalidade." A arbitragem transparente é melhor para o relacionamento do que um compromisso vago. Participantes que entendem por que seu modelo não foi escolhido respeitam a decisão. Participantes que recebem uma solução pela metade e descobrem depois que não se encaixa em nenhum fluxo de trabalho se sentem enganados.

O que deve incluir a chamada de debriefing de cocriação?

A chamada de debriefing é uma sessão de 30 minutos com PM e CSM presentes, realizada com os participantes de cocriação antes do GA. Ela cobre: o que entrou no desenvolvimento, o que não entrou, e por quê. Engajamentos de cocriação que terminam sem uma sessão formal de encerramento têm taxas 2,1 vezes maiores de decepção de expectativa relatada pelos participantes no lançamento do GA (Gainsight, 2024). Um resumo escrito segue em 48 horas. Participantes que contribuíram com 4 sessões e recebem um debriefing se sentem genuinamente consultados. Participantes que veem o anúncio do GA ao mesmo tempo que todos os outros clientes se sentem extraídos.

Quanto tempo deve durar um engajamento de cocriação?

Um engajamento de cocriação bem delimitado tem 3 a 5 sessões ao longo de 4 a 8 semanas. Engajamentos que se estendem além de 8 semanas geralmente sinalizam que o problema não estava bem definido o suficiente para começar, ou que o escopo se expandiu para um território que nenhuma funcionalidade isolada consegue satisfazer. Programas com mais de 5 sessões mostram queda na qualidade das sessões por fadiga dos participantes em 73% dos casos de médio porte (ProductLed, 2024). A chamada de debriefing não é opcional. Todo o restante pode ser simplificado para equipes menores. Mas o debriefing e os critérios de seleção por agudeza do problema são os elementos essenciais do modelo.

Saiba Mais

Tara Minh

Senior Operations & Growth Strategist