Repensando design de produto com inteligência

O pedido que chega e o pedido que importa

O time chegou com o escopo pronto: um botão de IA dentro do produto, capaz de resumir o que o usuário tinha na tela. Fazia sentido no roadmap, cabia no trimestre e já tinha data no material de vendas. O problema é que resolvia um sintoma.

Na primeira semana de discovery ficou claro que o gargalo não era resumir. Era que o dado do cliente vivia espalhado em quatro lugares, e nenhum deles conversava. Qualquer camada de inteligência ali em cima ia resumir uma versão parcial da verdade, com confiança total. É o pior tipo de erro: o que parece certo.

O teste que encerrou a discussão

Discovery vira opinião rápido, então em vez de argumentar montamos um protótipo tosco e rodamos em 150 perguntas reais que clientes tinham feito ao suporte no mês anterior. Para cada uma, comparamos o resumo da IA com a resposta que a pessoa mais experiente do time daria depois de olhar os quatro sistemas.

Em 47 das 150, o resumo omitiu algo que mudava a resposta. Não estava errado: estava incompleto, e escrito com a mesma segurança dos outros 103. Foi mais barato descobrir isso numa planilha do que seis meses depois, num ticket.

Widget resolve tela, fundação resolve operação

Widget de IA é fácil de vender e fácil de abandonar. Ele mora numa tela, responde a um clique e desaparece do fluxo assim que o usuário fecha a aba. Seis meses depois ninguém sabe dizer se ele mudou algum número.

Fundação é o contrário: entra embaixo do produto, não em cima. Significa decidir de onde vem o dado, quem pode ver o quê, o que a IA pode fazer sozinha e o que precisa de gente. Dá mais trabalho no começo e sobrevive à segunda leva de features.

O atalho que a gente recusou

Existia um caminho para entregar no trimestre, e alguém do nosso time defendeu ele com bons argumentos: soltar o botão na data com um aviso embaixo, do tipo “resumo gerado por IA, confira as informações”. É o que boa parte do mercado faz. Resolve o jurídico, cumpre o roadmap, aparece na release note.

A gente recusou, e o motivo é a única parte deste texto que vale para qualquer projeto:

Um aviso não conserta um dado incompleto. Ele transfere para o usuário a responsabilidade de perceber um erro que o sistema não sinalizou.

Tem um detalhe cruel nisso. Se o resumo acerta 103 vezes seguidas, ninguém confere na 104ª. A confiança que o recurso constrói acertando é exatamente o que faz o erro passar. Recurso que só funciona enquanto é desconfiado não funciona.

O que a gente mudou no escopo, e o que custou

O add-on saiu do primeiro ciclo. No lugar entrou uma base única com o histórico do cliente, uma camada de recuperação sobre esse histórico e uma regra explícita de quando a resposta vai direto para o usuário e quando passa por revisão.

Isso custou nove semanas e uma reunião ruim. O time tinha vendido interno como entrega do trimestre e passou a mostrar à diretoria um trabalho que não aparece em tela. A recomendação foi nossa, então a conta de estar errado também seria.

Só depois disso o recurso de resumo voltou, agora consultando a base inteira. A diferença é que ele deixou de improvisar sobre o que estava na tela e passou a responder sobre o que a empresa sabe.

Como medir se valeu

A pergunta que fecha o escopo é sempre a mesma: qual número muda se isso funcionar? Se ninguém consegue responder antes de construir, não é hora de construir.

Neste caso, a régua foi o tempo entre a dúvida do cliente e a resposta certa. Era medido em horas porque alguém precisava juntar informação de quatro sistemas. Passou a ser medido em segundos, e o suporte parou de ser o gargalo do onboarding. O mesmo teste das 150 perguntas voltou com 6 omissões em vez de 47, todas em anexos que ninguém tinha mapeado como fonte.

O número que não entrou em nenhuma apresentação: a regra de revisão foi calibrada errada. No primeiro mês ela mandava 1 em cada 3 respostas para conferência humana, o que irritou o suporte e quase matou o recurso por excesso de zelo. Levou seis semanas de ajuste para chegar num patamar que o time aceitou. A gente acertou onde o dado morava e errou o quanto de desconfiança o fluxo aguentava.

O que fica

IA não é feature. É camada. E camada precisa de chão.

Ela não erra sobre o que não sabe. Erra sobre o que ninguém contou a ela, com a mesma convicção com que acerta o resto. Por isso a pergunta que abre projeto aqui não é o que a IA consegue fazer, e sim o que existe embaixo dela.

Se o seu roadmap tem um item chamado “IA”, o teste é barato: pegue 150 casos reais, rode um protótipo qualquer e compare com o que a pessoa mais experiente do time responderia. A diferença entre os dois é o seu escopo de verdade.