30% mais engajamento depois de parar de tratar todos os professores igual
A Twin Science atende 1,5 milhão de estudantes em 4.000 escolas espalhadas por mais de 40 países. Tem parceria com Boeing, Rolls-Royce, Intel e Ford. Foi listada entre as melhores EdTechs do mundo pela revista TIME em 2025. O produto combina kits físicos de robótica com uma plataforma digital que usa IA para ajudar professores a montar planos de aula STEM. É, no papel, exatamente o tipo de empresa que parece ter resolvido o problema de distribuição educacional em escala.
O problema concreto era outro: os professores abriam a plataforma e não sabiam o que fazer com ela.
A Gerente de Produto Bennur Amaç descreveu a situação sem rodeios:
“Tínhamos duas escolhas: passar meses construindo um sistema de integração ou encontrar um caminho mais rápido.”
Essa frase resume o ponto de virada do projeto, mas o que tornou a situação difícil de resolver não foi falta de recursos. Foi um equívoco sobre quem era o usuário real da plataforma.
O produto tinha sido construído com a sofisticação certa para o que ele fazia, geração de currículo por IA, relatórios analíticos, ferramentas de personalização, integração com ecossistemas múltiplos de alunos, pais e administradores. O que não tinha sido previsto é que a maioria dos professores que precisava operar tudo isso vinha de escolas que adotam tecnologia por imposição administrativa, não por escolha. Esses professores não precisavam de um produto menos capaz, precisavam de uma entrada diferente no mesmo produto.
A confusão inicial não era sobre funcionalidade, era sobre orientação. Um painel com dezenas de opções, sem um ponto de partida claro, produz o que designers de UX chamam de “síndrome da página em branco”: o usuário enxerga possibilidade demais e não consegue começar. No caso da Twin, isso significava professores que criavam conta e paravam. Não tentavam configurar turma, não matriculavam alunos, não chegavam à parte do produto que gerava valor real.
A resposta instintiva para esse tipo de problema é documentação. Manual de usuário, vídeo de onboarding no YouTube, tutorial em PDF, nenhuma dessas saídas funciona bem porque todas exigem que o usuário saia do produto para aprender a usá-lo, e depois volte para aplicar o que leu ou assistiu. Cada vez que essa alternância acontece, parte da informação se perde e a sensação de dificuldade aumenta.
A decisão da Twin foi construir o onboarding dentro do próprio produto, usando uma ferramenta no-code chamada UserGuiding. A escolha pelo no-code tinha uma justificativa direta: se a equipe de engenharia precisasse codificar o fluxo de integração internamente, o projeto consumiria de 5 a 10 profissionais seniores durante semanas, entre PMs, designers, desenvolvedores front e back-end e analistas de dados, e depois exigiria manutenção constante a cada mudança de interface. A economia auditada foi de mais de US$ 10.000 só em custo de mão de obra direta, além de meses de desenvolvimento que não foram gastos, o que permitiu que a equipe técnica continuasse no roadmap principal da plataforma.
A economia de US$ 10.000 é a parte visível, mas a parte que muda o produto de verdade é a lógica de segmentação que a ferramenta habilitou.
A Twin dividiu os professores em dois grupos com base em comportamento, não em perfil declarado.
O primeiro grupo era de recém-chegados: contas criadas há menos de sete dias, sem nenhuma ação registrada nos logs, nenhuma turma criada, nenhum aluno matriculado. Para esse grupo, o fluxo de integração ignorava completamente as funcionalidades avançadas da plataforma. A única missão era guiar o professor até dois marcos: criar a primeira turma e matricular os primeiros alunos. Nada de IA generativa, nada de currículos dinâmicos, nada de relatórios. Só o básico que prova que o produto funciona.
O segundo grupo era ativado automaticamente quando o professor completava esses dois marcos. A plataforma detectava a conclusão via telemetria e mudava o conjunto de tutoriais disponíveis. Esse professor já não via mais instruções para adicionar alunos. Via caminhos para usar os recursos de IA, personalizar currículos e operar as partes mais complexas do sistema. A transição acontecia sem intervenção humana, sem que nenhum gerente de sucesso do cliente precisasse checar manualmente quem havia avançado.
Essa divisão resolve um problema que muitos produtos de software com múltiplos perfis de usuário ignoram: tratar usuários diferentes com o mesmo fluxo de integração produz resultados ruins nos dois extremos. O iniciante se perde, o usuário avançado perde tempo com instruções que não precisa. A segmentação por comportamento elimina esse conflito porque o critério de classificação é o que o usuário fez, não o que ele declarou ser.
O sistema de checklists que acompanhava o fluxo usava um princípio de psicologia cognitiva chamado Efeito Zeigarnik: tarefas incompletas geram tensão mental até serem concluídas, o que aumenta a motivação para terminar o que foi começado. Apresentar ao professor uma lista com três ou quatro tarefas básicas, com barra de progresso e estimativa de tempo (”leva 2 min”), transforma um painel assustador em um conjunto de passos gerenciáveis. A percepção de complexidade cai sem que o produto precise ser simplificado.
Os números reportados pela Twin:
aumento de 30% no engajamento diário dos usuários após a implementação,
redução de 10% a 20% no tempo até a primeira ação concreta dentro da plataforma (o que o setor chama de Time to First Value),
melhora de até 50% nas taxas de retenção em comparação com o modelo anterior sem onboarding estruturado.
Esses são os números que a empresa divulgou publicamente com base nos dados do UserGuiding.
O que esses números revelam é que o produto estava tecnicamente correto antes da mudança. O que não funcionava era a ponte entre o que o produto conseguia fazer e o que o professor conseguia descobrir sozinho dentro dele.
Essa distinção importa mais do que parece para quem constrói software B2B com usuários finais que não são os compradores. A escola compra o produto, o professor usa. O comprador avalia features, integrações e preço. O usuário avalia se consegue fazer a tarefa mais básica no primeiro dia. Se não consegue, para de tentar. E quando o usuário para de tentar, o dado que a escola vê no relatório de utilização é baixo, e na próxima renovação o contrato está em risco.
🔗 O que a Twin Science fez no onboarding, qualquer produto pode replicar. A UserGuiding é uma plataforma no-code que permite criar tours guiados, checklists de ativação, tooltips contextuais e segmentação por comportamento de usuário, sem depender de engenharia para cada iteração. Você configura o fluxo, define os gatilhos e publica direto em cima do seu produto.
Leitores desta newsletter têm 20% de desconto. Acesse aqui e use o cupom PRODUCTGURUS.
A Twin tem parceiros como Boeing e Intel porque o produto educacional convence em reuniões de C-level e avaliações de impacto social. Mas o que mantém esse produto sendo usado nas escolas é o professor de Ankara ou de Lagos que abriu o painel pela primeira vez e não desistiu nos primeiros quinze minutos, e o onboarding é o que decide se isso acontece ou não.
O problema que permanece sem resolução simples é que essa lógica vale para qualquer software com usuário final não técnico, mas a maioria das equipes de produto só descobre o custo do abandono precoce quando a taxa de churn já virou problema no board. Corrigir o fluxo de integração depois que os usuários desenvolveram hábito de não usar o produto é significativamente mais difícil do que construir o fluxo certo desde o início.