Discovery para desenvolvedores: encontre a demanda antes de automatizar
A transcrição abaixo é sintética, escrita para este capítulo. Nenhum agente de suporte real foi entrevistado.
Product Engineer: Pensa no último ticket que te deu mais trabalho para classificar. O que fez ele parecer diferente?
Agente (INT-001): Vinha marcado como urgente, mas o texto era sobre cobrança, não sobre o produto. Eu tive que abrir outra aba pra achar o plano do cliente antes de decidir pra onde mandar.
Uma frase dessas pode virar produto em minutos, se ninguém separar o que foi dito do que foi concluído.
| Observação (o que foi dito) | Interpretação (o que parece significar) | Hipótese (o que ainda precisa de teste) |
|---|---|---|
| Agente reabriu outra aba para checar o plano do cliente antes de classificar um ticket marcado "urgente" | A categoria declarada pelo cliente ("urgente") não corresponde ao tipo real do problema (cobrança vs. produto) | Se o sistema sugerisse o tipo real a partir do texto, o agente gastaria menos tempo cruzando abas — mas não sabemos se isso é raro, comum, ou se afeta o tempo de atribuição de forma relevante |
O capítulo 01 desta série produziu um brief v0 para o DeskPilot, um exemplo didático de triagem assistida de suporte B2B: usuário é o agente, comprador potencial é o gestor, afetado é o cliente final. O brief tinha hipótese refutável, owner a designar e uma meta ilustrativa de 20% de redução na mediana do tempo até atribuição correta. Ele também tinha um buraco deliberado: nenhuma entrevista, nenhum episódio real, nenhuma evidência além de suposição estruturada. Minha tese aqui é que pesquisa de produto transforma essa suposição em decisão rastreável; IA pode ajudar a sintetizar entrevistas, mas não fabrica necessidade, não conduz entrevista por você e não substitui teste de disposição a pagar. A decisão que este capítulo pede ao leitor é dupla: qual oportunidade investigar primeiro, e qual resultado justificaria de fato construir alguma coisa.
Como no capítulo anterior, nenhum cliente real aparece aqui. Todas as seis entrevistas em examples/interviews.synthetic.json são geradas para o exercício e rotuladas "synthetic": true. Isso não é um detalhe de rodapé: um checker em examples/evidence-check.mjs rejeita qualquer registro que tente se passar por evidência real, exatamente como faria com dados de um piloto de verdade que alguém tentasse maquiar.
O menor exemplo: três colunas antes de qualquer ferramenta
A disciplina central de discovery cabe numa tabela de três colunas, repetida para cada trecho relevante de entrevista: o que a pessoa disse, o que isso parece significar, e o que ainda precisa ser testado. A maior parte dos erros de discovery vem de pular direto da primeira coluna para um roadmap, sem passar pela segunda e pela terceira.
Compare com o brief v0 do capítulo 01, que dizia: "hipótese: sugestão de categoria e resumo, revisada por agente, pode reduzir mediana do tempo". Essa frase era uma hipótese de outcome, escrita antes de qualquer episódio real (ou sintético) ser examinado. O trabalho deste capítulo é confrontar essa hipótese com relatos de episódios concretos — mesmo sintéticos — e ver se ela sobrevive, muda de forma, ou se revela menos importante do que outra oportunidade que ninguém tinha nomeado.
Duas outras entrevistas sintéticas ilustram por que a coluna "interpretação" não pode virar a coluna "hipótese" sem passar por teste. INT-003, um agente sênior, diz que reclassificação é rara ("1 em 30 tickets") e não a considera um problema central; ela se importa mais com o tempo que gasta explicando erros de sugestão automática para novatos. INT-004, um agente pleno, diz que reclassifica "4 ou 5 em cada 20 tickets" e já viu isso virar escalonamento formal de cliente. Uma interpretação apressada faria a média das duas estimativas e concluiria "reclassificação acontece em cerca de 15% dos tickets". Isso destruiria a informação mais útil da entrevista: a frequência pode depender de senioridade, de tipo de ticket, ou de como cada agente define "reclassificar". A hipótese correta não é um número médio; é uma pergunta segmentada, testável separadamente (examples/opportunity-tree.md, Oportunidade C).
Por que um brief plausível não basta
Um brief bem escrito pode descrever um problema real e ainda assim não ter intensidade, evidência ou reversibilidade suficientes para justificar um piloto. A árvore de oportunidades de Teresa Torres, consultada em 2026-09-28, organiza esse teste em quatro camadas: um outcome de negócio no topo, oportunidades (necessidades e dores observadas) que levam a ele, soluções candidatas para cada oportunidade, e testes que verificam a suposição de maior risco antes de construir qualquer coisa. Torres recomenda de três a quatro entrevistas baseadas em episódios reais antes da primeira árvore — um número que orienta profundidade qualitativa, não representatividade estatística. Achar padrão em seis entrevistas sintéticas não prova nada sobre o mercado; prova apenas que o método consegue estruturar sinal contraditório sem apagá-lo.
O segmento inicial precisa ser delimitado sem inventar tamanho de mercado. Para o DeskPilot, o recorte permanece o do capítulo 01: uma única equipe de suporte B2B com triagem manual, canal de entrada único e autorizado, tickets sem dado especialmente sensível. O que muda agora é o nível de detalhe: o volume a medir é "tickets elegíveis recebidos por semana no canal alvo", não "todo o mercado de suporte B2B"; a alternativa atual a comparar é o fluxo manual descrito pelos próprios agentes, não uma suposição sobre "como toda empresa de suporte trabalha". Nenhuma dessas entrevistas sintéticas autoriza uma frase como "empresas B2B perdem X% de produtividade com triagem manual" — essa frase exigiria uma amostra real e um método de medição que este capítulo ainda não tem.
A Nielsen Norman Group descreve o método de verbalização de pensamento (thinking aloud), consultado em 2026-09-28, como robusto e barato, mas explicitamente não estatístico: Jakob Nielsen escreve que o método "não se presta a estatística detalhada, a menos que se rode um estudo grande e caro". A mesma advertência vale aqui. Entrevistas sobre episódios passados revelam padrão e causa; não estimam prevalência. Um relatório interno que citasse "78% dos agentes preferem sugestão automática" a partir de seis conversas estaria emprestando precisão estatística que a amostra não sustenta.
Entrevistar sobre episódios, não sobre opinião
O roteiro completo está em examples/interview-guide.md. A estrutura evita a pergunta mais comum e menos útil de discovery: "você usaria uma ferramenta de IA para isso?". Essa pergunta mede entusiasmo hipotético, não comportamento. Em vez disso, cada entrevista percorre um episódio específico e recente em seis etapas:
1. Gatilho: o que fez você notar que aquele ticket era diferente?
2. Fluxo: descreva passo a passo o que você fez.
3. Workaround: existe algo que você faz por conta própria que o sistema não oferece?
4. Frequência: com que frequência isso acontece, aproximadamente?
5. Consequência: o que aconteceu depois, para o cliente e para você?
6. Decisão de compra (só com comprador): o que pesou na última aprovação ou recusa de uma ferramenta nova?
Recrutamento, consentimento, minimização e anonimização precisam existir mesmo quando as entrevistas são sintéticas, porque o protocolo é o que muda quando a equipe finalmente fala com pessoas reais. O roteiro define: convite via gestor com opção explícita de recusa, consentimento registrando objetivo e prazo de retenção, e anonimização por código (INT-00N) em vez de nome. Nenhum dado de cliente final identificável deve ser perguntado durante a entrevista; se um agente mencionar um caso específico, o registro remove nome de cliente e número de ticket antes de guardar a nota. Uma equipe que pule esse protocolo "porque o piloto é pequeno" está adiando um problema de privacidade, não evitando ele.
Evolução do DeskPilot: do brief v0 à árvore de oportunidades
As seis entrevistas sintéticas (quatro agentes, dois gestores) alimentam três oportunidades registradas em examples/opportunity-tree.md, todas amarradas ao mesmo outcome do capítulo 01: reduzir a mediana do tempo até atribuição correta sem elevar reatribuição, incidente de tenant ou carga de treinamento.
Oportunidade A — ambiguidade entre cobrança e produto. Vem diretamente do trecho de abertura: INT-001 mantém uma planilha pessoal de palavras-chave porque a triagem automática existente erra nesse tipo de ticket. Três soluções concorrentes: (1) manual — um checklist para diferenciar cobrança de produto; (2) regra determinística — um campo obrigatório de "tipo de solicitação" no formulário de entrada; (3) IA assistida — sugestão de categoria com trecho do ticket destacado, revisada pelo agente. O teste da suposição de maior risco não constrói nada: um agente sênior revisa 30 tickets históricos ambíguos e verifica se a sugestão hipotética bateria com a decisão humana final, antes de qualquer modelo ser treinado ou chamado.
Oportunidade B — prioridade contratual invisível. INT-002 descreve perguntar a colegas para saber qual ticket priorizar entre contas de tamanhos diferentes, usando uma lista mantida à parte pelo comercial; já perdeu um SLA por seguir apenas a ordem de chegada. Aqui a solução determinística (sincronizar o campo de SLA do CRM direto na tela de triagem) é testada antes da solução de IA (resumo incluindo prioridade), porque a suposição de maior risco não é sobre modelo — é sobre se o dado de SLA no CRM está correto o suficiente para ser exibido sem revisão.
Oportunidade C — divergência sobre frequência de reclassificação. Nasce da contradição registrada entre INT-003 e INT-004. Em vez de resolver a discordância com uma média, a árvore propõe medir diretamente: um campo obrigatório de motivo de reclassificação, sem IA, segmentado por senioridade do agente. Só depois de ver se o padrão de INT-003 (raro, mas custoso em treinamento) ou o de INT-004 (frequente, com escalonamento) domina os dados reais, faz sentido avaliar uma solução de IA com nível de confiança.
A tabela de priorização em opportunity-tree.md pontua cada oportunidade por intensidade relatada, número de fontes e reversibilidade da solução testada. A oportunidade A pontua mais alto; a C, mais baixo — não porque seja menos importante, mas porque a evidência é contraditória por desenho e precisa de mais teste antes de qualquer prioridade fazer sentido. Esse score é uma heurística de ordenação, não um ranking definitivo. Ele decide o que investigar primeiro, nunca substitui o teste descrito para cada suposição de maior risco. Um placar mais alto obtido com uma amostra de uma ou duas pessoas continua sendo um palpite mais bem organizado, não uma prova.
Testar sem cobrar: concierge e disposição a pagar
O plano de piloto define dois testes que acontecem antes de qualquer linha de código de produção. No teste concierge da oportunidade A, um agente sênior revisa manualmente, por uma semana, uma amostra de tickets ambíguos e anota à mão qual categoria teria sugerido — sem construir a automação. Isso mede se a ideia funcionaria em retrospecto, sem o custo e o risco de expor um modelo a tráfego real.
O teste de disposição a pagar não cobra nada. É uma conversa estruturada com o gestor de suporte, apresentando o resultado do teste concierge e perguntando, nessa ordem: que orçamento existe hoje para esse tipo de atraso; o que precisaria ser verdade para aprovar um piloto pago; quem mais precisa aprovar. Uma resposta específica sobre orçamento e aprovador conta como sinal de disposição a pagar. Uma frase como a de INT-006 — "parece que isso resolveria muito problema meu" — sem menção a orçamento, aprovador ou condição, conta como elogio, não como demanda. O plano registra essa distinção explicitamente porque é o erro mais fácil de cometer depois de uma boa conversa.
O gate final considera três dimensões, inspiradas na separação de riscos usada por equipes orientadas a outcome descrita por Marty Cagan/SVPG, consultado em 2026-09-28: viabilidade (o gestor tem orçamento e autoridade real, ou depende de uma aprovação externa não mapeada), usabilidade (o agente sênior concordou com a sugestão retrospectiva na maior parte da amostra) e acesso a dados (a equipe consegue autorizar tickets históricos anonimizados e um CRM com SLA confiável). Avançar exige as três favoráveis. Mudar de segmento se aplica quando viabilidade ou acesso a dados falham nesta equipe, mas o mesmo problema aparece com força equivalente em outra fila disponível para discovery. Abandonar se aplica quando usabilidade falha e nenhuma solução mais simples resolve a ambiguidade — nesse caso, o decision log do capítulo 01 e o método deste capítulo continuam válidos como estudo de caso, mesmo que o produto específico mude de direção. Nenhum desses três caminhos é fracasso do processo; são o processo funcionando.
Contratos entre papéis e IA
O comprador não é o usuário, e confundir os dois é o erro mais caro deste capítulo. O gestor de suporte (INT-005, INT-006) decide orçamento e aprovação; o agente (INT-001 a INT-004) decide, no dia a dia, se aceita ou rejeita uma sugestão. Uma equipe que só entrevista gestores porque "são eles que compram" nunca vai descobrir que a maior fonte de atraso é uma aba extra que o agente abre para checar o plano do cliente — e uma equipe que só entrevista agentes porque "são eles que usam" nunca vai descobrir que o gestor não aprovaria orçamento sem ver redução medida contra um baseline. As duas entrevistas são necessárias e respondem perguntas diferentes.
A síntese assistida por IA entra depois das seis entrevistas, não no lugar delas. Um resumo automático a partir do JSON de entrevistas poderia escrever algo como "agentes relatam reclassificação ocasional". Essa frase é tecnicamente verdadeira e editorialmente perigosa: ela apaga a diferença entre "1 em 30" e "4-5 em 20", e a associação de INT-003 entre reclassificação e treinamento de novato, que é o dado mais acionável da entrevista. O contrato adotado aqui é simples: qualquer síntese gerada por IA precisa apontar para o id da entrevista de origem, e uma discordância entre duas fontes (como INT-003/INT-004, marcadas com contradicts mútuo em interviews.synthetic.json) precisa permanecer visível no documento final, não ser resolvida por média ou por consenso automático. O checker em evidence-check.mjs recusa a árvore de oportunidades se nenhum par de contradição sobreviver — uma forma mecânica de impedir que a conveniência editorial apague o sinal mais interessante da pesquisa.
Quatro falhas que valem a pena nomear
1. Entrevista indutiva
Sintoma: a pergunta já descreve a solução — "você usaria uma sugestão de IA para categorizar tickets mais rápido?" — antes de o agente descrever o próprio episódio. Causa: o entrevistador quer validação, não descoberta; a pergunta pede uma opinião educada sobre uma ideia já formada. Resposta: perguntar pelo episódio (gatilho, fluxo, workaround, frequência, consequência) antes de qualquer menção a IA; se a pessoa entrevistada mencionar IA por conta própria, isso é dado, mas não deve ser induzido. O roteiro deste capítulo proíbe explicitamente perguntas como "isso seria útil?" pela mesma razão: qualquer pessoa educada tende a dizer que sim.
2. Comprador confundido com usuário
Sintoma: o brief lista "cliente: gestor de suporte" e trata as respostas dele como evidência de que os agentes vão adotar a sugestão. Causa: é mais fácil marcar reunião com quem aprova orçamento do que com quem faz o trabalho todos os dias; a linguagem de "cliente" no vocabulário comercial esconde que existem pelo menos dois papéis com interesses distintos. Resposta: manter as colunas de usuário, comprador e afetado sempre separadas (herdadas do capítulo 01) e verificar, para cada afirmação do brief v1, de qual papel ela realmente vem. Uma frase como "o cliente adoraria essa funcionalidade" deve responder à pergunta: qual cliente — o que usa, o que paga, ou o que é afetado pelo resultado?
3. Síntese de IA apagando contradições
Sintoma: um resumo gerado automaticamente concilia relatos divergentes numa única frase de consenso, e ninguém nota que perdeu informação. Causa: modelos de linguagem são otimizados para produzir texto coerente; coerência e fidelidade à fonte nem sempre coincidem, especialmente quando duas fontes discordam. Resposta: exigir que toda síntese aponte para o trecho e o id de origem, revisar manualmente qualquer resumo que combine mais de uma entrevista, e tratar divergência preservada como dado válido — muitas vezes o dado mais valioso da rodada, porque revela que o problema não é uniforme entre agentes.
4. Promessa de compra tratada como pagamento
Sintoma: uma frase de entusiasmo verbal ("isso resolveria muito problema meu") vira, na ata da reunião seguinte, "cliente confirmou interesse em comprar". Causa: encerrar uma conversa com um sinal positivo é gratificante, e a pressão para mostrar progresso empurra a interpretação mais otimista possível. Resposta: registrar a resposta literal, exigir menção específica a orçamento, aprovador e condição de sucesso antes de contar como sinal de disposição a pagar, e nunca lançar promessa verbal como receita, contrato ou pipeline. O checker deste capítulo rejeita mecanicamente qualquer linha do plano de piloto que afirme um pagamento como já realizado fora de uma seção explícita de restrições — uma segunda camada de proteção contra o mesmo vício de linguagem.
Avaliar descoberta sem fabricar sucesso
O critério de sucesso deste capítulo não é "o DeskPilot validou demanda" — isso seria fabricar um resultado que nenhuma entrevista sintética pode produzir. O critério é: o brief v1 distingue observação de hipótese em cada oportunidade; cada oportunidade compara pelo menos três alternativas; cada teste de suposição de maior risco tem responsável, prazo, critério e decisão explícitos; e pelo menos uma discordância real entre fontes permanece visível em vez de mediada. node examples/evidence-check.mjs all verifica essas quatro condições estruturalmente e falha se qualquer uma faltar (ver verification.md). Isso é disciplina de processo, não medida de produto: o checker não sabe se a "Oportunidade A" é real, apenas se o documento que a descreve segue o contrato mínimo para ser levado a sério.
Quando a equipe finalmente entrevistar pessoas reais, a régua muda: o outcome do capítulo 01 (mediana do tempo até atribuição correta, com pendentes visíveis no denominador) continua sendo o que precisa ser medido depois de qualquer piloto, não o número de entrevistas realizadas nem a elegância da árvore de oportunidades. Uma árvore bem construída que aponta para o segmento errado ainda é um discovery malsucedido; uma árvore modesta que evita um piloto caro e sem demanda é um discovery bem-sucedido, mesmo sem gerar uma linha de código.