ia para times de produto. ia para times de produto significa entregar uma funcionalidade de ia dentro das suas próprias interfaces de produto que os usuários adotam e continuam usando. não uma demo. uma funcionalidade com um número de retenção e um número de tickets de suporte por trás dela.
a maioria dos times de produto já tem um protótipo. você o construiu num fim de semana com Lovable, Bolt ou v0. ficou ótimo no standup. então travou no caminho para produção.
a lacuna não é o modelo. é tudo ao redor dele. streaming, evals, registro de auditoria e um lugar no produto onde o usuário já está. esse é o trabalho entre uma tela de v0 e uma funcionalidade que seus usuários mantêm.
#por que o protótipo trava antes do lançamento?
um protótipo responde a uma pergunta: o modelo consegue fazer aquilo. uma funcionalidade em produção responde a mais quatro. ela transmite em streaming para o usuário não ficar olhando para um indicador de carregamento. ela se mantém correta quando o prompt muda. você consegue provar o que ela disse a um cliente seis semanas atrás. e ela vive onde o usuário já trabalha, não atrás de uma aba separada.
qual é a diferença entre um protótipo de ia e uma funcionalidade em produção?
um protótipo prova que o modelo consegue fazer a tarefa numa demo. uma funcionalidade em produção adiciona streaming para que as respostas pareçam instantâneas, um conjunto de evals para que a qualidade se mantenha quando os prompts mudam, registro de auditoria para que você possa provar o que foi dito, e ux integrada ao produto para que os usuários a adotem. o protótipo é os 20% fáceis.
#você deve encaixar uma caixinha de chat ou construir dentro das suas interfaces?
a jogada padrão é uma bolha de chat flutuante no canto. sobe rápido. também fica sem uso, porque o seu usuário não veio para conversar. veio para enviar um pagamento, conciliar um extrato ou abrir uma disputa.
a jogada melhor é colocar a ia dentro da interface onde esse trabalho acontece. um padrão inteligente no formulário. uma explicação de um clique ao lado da transação. uma resposta renderizada no painel que o usuário já tinha aberto.
we are
a stennir constrói ia dentro das interfaces do produto que seus usuários já usam, com os números de adoção e de tickets de suporte para mostrar que funcionou.
we aren't
a stennir não é um time que encaixa uma caixinha de chat genérica no seu app e chama isso de funcionalidade de ia.
#como foi isso para uma fintech série b?
uma fintech série b chegou até nós com um assistente de ia voltado ao cliente construído no Lovable. respondia perguntas numa demo. não conseguia ir para produção. sem streaming, sem como medir qualidade, sem trilha de auditoria para um produto regulado.
- streaming: as respostas aparecem token a token, então o usuário vê a resposta se formando em vez de um indicador de carregamento.
- conjunto de evals: um conjunto fixo de perguntas reais roda a cada mudança de prompt, para que a qualidade não regride silenciosamente quando alguém edita o system prompt.
- registro de auditoria: cada resposta é gravada com seus inputs, para que uma fintech regulada possa provar o que foi dito a um cliente e quando.
- ux integrada ao produto: o assistente responde dentro da visão de transação que o usuário já tinha aberta, não numa aba de chat separada.
entregamos para 100% dos usuários em 5 semanas. os tickets de suporte nessa funcionalidade caíram 60% após o lançamento, porque os usuários obtinham a resposta no produto em vez de abrir um ticket para perguntar.
o protótipo provou que as pessoas queriam. o build em produção foi o que as fez continuar usando. a queda de 60% nos tickets é a parte que o nosso cfo se importou.
#como você define o escopo de um build assim?
rodamos pelo serviço de build: escopo fixo, preço fixo, e o código é seu desde o primeiro dia. você mantém o protótipo que já fez no v0, Bolt ou Lovable como ponto de partida. nós levamos o restante do caminho até uma funcionalidade no seu produto.
se você quer o padrão para o seu time especificamente, a página de ia para produto detalha onde a ia merece seu lugar dentro de um produto, e a prática de consultoria é onde esses builds acontecem. quer ver as provas antes de se comprometer? veja o trabalho.