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.

Custo, segurança e reversibilidade da pesquisa

Entrevistar tem custo real mesmo sem cobrar nada: tempo de agentes e gestores tirado do trabalho, risco de fadiga de pesquisa se a equipe voltar toda semana pedindo mais conversa, e risco de expectativa — uma pessoa entrevistada pode assumir que a empresa já decidiu construir algo, só porque alguém perguntou. O roteiro deste capítulo limita a rodada a quatro a seis agentes e dois gestores, evita perguntas hipotéticas sobre IA e define prazo curto (5 dias úteis para o teste concierge, uma reunião de 30 minutos para disposição a pagar) para não transformar discovery num processo sem fim.

Segurança de dado começa na entrevista, não no piloto: nenhum dado de cliente final identificável deve ser coletado nessa fase; se um agente mencionar um ticket específico, nome de cliente e número de ticket são removidos antes do registro. O JSON de entrevistas sintéticas não contém nenhum dado real — mas o protocolo que ele documenta (interview-guide.md) é o mesmo que valeria para dados reais, incluindo consentimento registrado, prazo de retenção da nota e direito de a pessoa entrevistada pausar ou encerrar a conversa.

Reversibilidade aqui significa duas coisas. Primeiro, cada teste (concierge, disposição a pagar) é desenhado para não deixar rastro operacional se falhar: o teste concierge não muda nenhum ticket real, e a conversa de disposição a pagar não gera cobrança nem contrato. Segundo, o próprio gate é reversível por desenho: "mudar de segmento" e "abandonar" são resultados válidos, registrados no decision log, não fracassos a esconder. Uma equipe que só sabe registrar "avançar" está, na prática, proibida de descobrir que a oportunidade certa é outra.

Checklist de partida

• Cada entrevista registrou gatilho, fluxo, workaround, frequência, consequência e decisão de compra (quando aplicável), sem perguntar "você usaria IA?"
• Consentimento, minimização e anonimização foram aplicados mesmo em exercício sintético?
• Cada oportunidade da árvore aponta para uma observação ou hipótese rotulada, não para uma opinião do time?
• Cada oportunidade compara pelo menos três soluções: manual, regra determinística e IA assistida?
• Cada teste de suposição de maior risco tem responsável, prazo, critério e decisão?
• O score de priorização foi tratado como heurística de ordem, não como prova de valor?
• O teste de disposição a pagar distingue elogio de sinal específico de orçamento e aprovador?
• O gate considera viabilidade, usabilidade e acesso a dados, com caminhos explícitos de avançar, mudar de segmento e abandonar?
• Alguma discordância real entre entrevistas permanece visível na síntese, em vez de mediada?
• Rodei o checker válido e inválido e li o resultado real em verification.md?

Três exercícios para a semana de discovery

Básico — reescreva uma pergunta indutiva. Pegue "você usaria uma sugestão de IA para isso?" e reescreva como uma sequência de perguntas sobre um episódio passado (gatilho, fluxo, workaround, frequência, consequência). Critério: a nova sequência não menciona IA até que a pessoa entrevistada a mencione primeiro. Solução comentada: substituir por "pensa no último ticket que te deu mais trabalho para classificar; o que fez ele parecer diferente? o que você fez, passo a passo? existe algo que você faz por conta própria que o sistema não oferece? com que frequência isso acontece? o que aconteceu depois?" — a mesma estrutura usada em interview-guide.md.

Intermediário — separe comprador de usuário numa frase real. Pegue a frase "o cliente adoraria essa funcionalidade" (ou equivalente ouvida em alguma reunião) e reescreva identificando qual papel específico a sustenta: usuário, comprador ou afetado. Critério: a frase reescrita nomeia o papel e o tipo de evidência que falta para os outros dois papéis. Solução comentada: "o gestor de suporte (comprador) disse que aprovaria orçamento se houvesse redução medida; ainda não sabemos se os agentes (usuário) aceitariam a sugestão no dia a dia, nem se os clientes finais (afetado) notariam diferença na resposta."

Avançado — desenhe um teste de disposição a pagar sem cobrar. Para uma das três oportunidades do DeskPilot (ou uma oportunidade real do seu contexto), escreva as três perguntas da conversa de disposição a pagar e o critério que distingue elogio de sinal de compra. Critério: o critério exige menção específica a orçamento, aprovador e condição de sucesso; nenhuma cobrança real ocorre; a decisão de "avançar" versus "manter em validação" está escrita antes da conversa, não depois de ouvir a resposta. Solução comentada: ver examples/pilot-plan.md, seção "Teste de disposição a pagar" — a frase de INT-006 é o contraexemplo documentado de elogio sem compromisso.

Glossário e ponte para o capítulo 03

Opportunity solution tree é uma estrutura que liga um outcome de negócio a oportunidades observadas, soluções candidatas e testes de suposição, evitando pular direto de um problema para uma solução favorita. Teste concierge é uma simulação manual de uma solução automatizada, feita por uma pessoa, antes de construir qualquer sistema. Disposição a pagar é um sinal específico de orçamento, aprovador e condição de sucesso — não entusiasmo verbal. Gate é o ponto de decisão explícito entre avançar, mudar de segmento ou abandonar uma oportunidade, com critério definido antes de ver o resultado. Evidência sintética é dado gerado para fins didáticos, rotulado como tal, que nunca deve ser reaproveitado como prova de demanda real.

Este capítulo termina com uma oportunidade priorizada (ambiguidade entre cobrança e produto), um fluxo de triagem melhor entendido e um conjunto de gates ainda não exercidos com dado real. Nenhuma entrevista de verdade aconteceu; nenhum cliente confirmou pagamento; a meta ilustrativa de 20% do capítulo 01 continua sem baseline real por trás dela. No capítulo 03 previsto desta série, a tarefa passa a ser técnica: transformar a oportunidade priorizada em domínio verificável — máquina de estados, matriz de permissões e contrato de eventos — para que a IA sugira categoria e resumo dentro de regras que ela não pode inventar sozinha.

Fontes e limites

• Teresa Torres, Opportunity Solution Trees, Product Talk, atualizado em 2023-12-06; consultado em 2026-09-28. Estrutura de árvore e recomendação de três a quatro entrevistas por episódio; método qualitativo, não estimativa de mercado.
• Jakob Nielsen, Thinking Aloud: The #1 Usability Tool, Nielsen Norman Group, 2012-01-15; consultado em 2026-09-28. Justifica não tratar seis entrevistas sintéticas como amostra estatística.
• Marty Cagan / SVPG, Product vs Feature Teams, 2019-08-29; consultado em 2026-09-28. Framework autoral sobre os riscos de valor, usabilidade, viabilidade e negócio; usado aqui só para nomear as três dimensões do gate.