Do que trata este artigo. Um exemplo prático ilustrativo, não um resultado de cliente. A equipe fintech, seu produto e cada número são premissas. Mostra o que é preciso para transformar um protótipo de AI que vai bem na demo numa funcionalidade que você pode colocar diante de todos os usuários.
Suponha uma equipe de produto de uma fintech em série b. Um product manager construiu um protótipo de uma funcionalidade de AI no lovable num fim de semana. Parece real e foi bem no all-hands. Depois fica parado, porque parecer real e ser confiável são dois trabalhos diferentes.
sobre este exemplo: a equipe é genérica e não há cliente por trás. Nada aqui é um resultado entregue nem uma projeção. O que importa é o design, não o logotipo.
#Por que um bom protótipo trava antes da produção?
Porque o protótipo responde a uma pergunta diferente da que a produção responde. O protótipo prova que a ideia funciona uma vez, com uma entrada limpa, com o fundador conduzindo. A produção precisa funcionar com a entrada bagunçada, às 2h da manhã, sem ninguém olhando, e ser defensável quando um cliente contesta o que a funcionalidade disse. é aí que a maioria dos builds em v0 e lovable morre. Não porque a ideia estava errada. Porque não havia um caminho da demo até algo em que você pode colocar seu nome.
Como levar um protótipo de AI à produção?
Comece pelo problema real, não pela interface da demo. Reconstrua a funcionalidade dentro do seu próprio produto, com respostas em streaming, uma suíte de testes que confronta as respostas com casos bons conhecidos, log de auditoria e revisão humana onde importa. Depois meça os tickets de suporte sobre a funcionalidade antes e depois.
#O que o design de produção inclui?
Não comece pela caixa de chat do protótipo. Comece pela fila do suporte. Suponha que os três tickets de maior volume sobre esta funcionalidade apontem para a mesma coisa: os usuários não conseguem uma resposta clara sem escrever ao suporte. Construa a funcionalidade para responder primeiro a essas três perguntas, dentro do produto e do design system da própria equipe, não como um widget colado.
- respostas em streaming para a funcionalidade parecer imediata em vez de um indicador de carregamento. A resposta vai aparecendo enquanto se forma.
- um conjunto de testes que roda a funcionalidade contra respostas conhecidas e corretas a cada mudança, para que um ajuste num prompt não quebre outro caso silenciosamente.
- registro de auditoria em cada resposta, para que, quando um cliente conteste o que a funcionalidade disse, o suporte consiga puxar a entrada e a saída exatas.
- UX integrada ao produto construída dentro do design system deles, para que pareça parte do produto, não uma janela de chat colada por cima.
We are
Reconstruímos um protótipo travado numa funcionalidade lançada, com streaming, suíte de testes, log de auditoria e UX nativa dentro do produto.
We aren't
Não colocamos uma caixa de chat genérica por cima do produto e chamamos de funcionalidade de AI.
#Como saber se a funcionalidade reduz os tickets de suporte?
Construa a funcionalidade de trás para a frente, a partir dos tickets. As perguntas que geram mais volume de suporte são as que a funcionalidade responde dentro do produto, antes que alguém precise escrever. O log de auditoria mostra quais perguntas ela trata e quais ainda chegam a uma pessoa. O mesmo log ajuda a distinguir uma queda real de uma oscilação sazonal: compare o volume de cada tipo de ticket com uma janela de referência anterior ao lançamento.
A suíte de testes é o que faz qualquer melhoria se sustentar. Antes do lançamento, cada alteração roda contra as respostas boas conhecidas. Uma edição de prompt que conserta um caso e quebra outros dois é pega antes de chegar a um usuário. Essa é a diferença entre uma demo que funciona uma vez e uma funcionalidade que funciona sempre. Equipes de produto chamam isso de entregar. Nós também. Mais sobre como abordamos o trabalho de produto, aqui.
#Em que ordem se constrói?
Primeiro o log de auditoria e a suíte de testes, porque você não melhora o que não consegue medir. Depois reconstruir dentro do produto as respostas dos tickets principais. Em seguida a UX do design system e o streaming. Por fim, uma implantação em etapas para uma parcela crescente de usuários, observando o log de auditoria atrás do que os testes deixaram passar. Sem lançamento de uma vez só.
O teste a aplicar: deve passar de algo que você demonstrou para algo que você entregou, e a fila do suporte é como você sabe que funcionou.
é isso que os nossos exemplos práticos têm em comum. O ganho não é o modelo. São as partes chatas ao redor: a suíte de testes, o log de auditoria, os portões de revisão, a implantação que você consegue observar. é isso que transforma um protótipo em algo que você pode colocar diante de todos os usuários. Se você tem um build do v0 ou do lovable parado na demo sem caminho à frente, é exatamente a lacuna que fechamos. conte o que você está construindo.
