O que estamos fazendo voar na Flash

Em 2020, eu entrei na Flash como a primeira PM da empresa. Na época, o produto era “só” isso: um aplicativo de benefícios. Um produto, uma proposta de valor, um jeito de usar. Hoje, a Flash é uma empresa multiproduto, com um time de tecnologia de mais de 200 pessoas. Entre um momento e outro não teve nenhuma virada de chave, teve muito erro, muito ajuste de rota e, principalmente, muito aprendizado sobre como um time de tecnologia precisa trabalhar para sustentar esse tipo de crescimento.

Este texto é sobre isso: o que aprendemos de verdade, como a cultura tech da Flash se manifesta no dia a dia (e não só no discurso)

O aprendizado mais caro: time não é esteira

Se tem uma coisa que descobrimos cedo - e ainda bem que foi cedo - é que produto, design e engenharia não podem trabalhar em esteira. Produto define o que precisa ser feito, design desenha a solução, engenharia desenvolve o que foi desenhado. Nunca deu certo aqui na Flash.

Esse modelo assume que dá pra separar decisão de execução, e na prática do produto isso não existe. Quando engenharia só recebe uma especificação pronta, ela perde a chance de apontar um problema técnico antes de ele virar retrabalho. Quando design desenha sem estar na mesa da decisão, o resultado geralmente resolve o problema errado com muita elegância. E quando produto define sozinho, sem o contato direto com quem vai construir e quem vai desenhar a experiência, a solução nasce otimista demais.

Quando entendemos que ter todo mundo na sala, para entender o problema do cliente na raíz, isso mudou o jogo para evoluirmos nosso produto. Squads que discutem o “por quê” juntas erram menos e corrigem mais rápido do que squads que só recebem tarefas bem definidas.

Cultura tech, na prática

Na Flash, a prática que mais define a nossa cultura tech não é um ritual formal, é uma postura: errar rápido e perto do cliente, não longe dele. Em vez de tentar blindar cada decisão com meses de validação antes de qualquer coisa ir ao ar, a gente aprendeu a colocar versões imperfeitas na frente de clientes reais, ouvir o que quebrou, e corrigir com velocidade. Isso só funciona se produto, design e engenharia estiverem alinhados sobre o que é um erro aceitável e o que não é — e essa é uma conversa que a gente teve (e ainda tem) com frequência.

Não é sobre gostar de errar. É sobre entender que, numa empresa que está construindo uma plataforma nova a cada ano, o risco maior não é errar — é demorar demais pra descobrir que errou.

O case: transformar a plataforma de benefícios em plataforma integrada

O momento que mais resume essa jornada foi quando entendemos que precisávamos refazer inteira a plataforma de gestão, indo de uma ferramenta pensada só para gestão de benefícios para uma experiência que sustenta todo o portfólio da Flash.

O desafio técnico e de produto aqui era duplo. De um lado, tínhamos clientes que já usavam a Flash havia anos só para benefícios, com um jeito de trabalhar consolidado. Do outro, precisávamos abrir espaço para um portfólio inteiro de produtos novos, com perfis de uso completamente diferentes, sem transformar a plataforma em uma colcha de retalhos.

Erramos bastante nesse caminho. Subestimamos a complexidade de manter uma experiência simples para quem só usava benefícios enquanto expandíamos a superfície do produto. Lançamos coisas que precisaram ser revisitadas. Mas foi exatamente nesse processo que aprendemos, na prática, a trabalhar de um jeito diferente: conectar o cliente de perto, testar hipóteses reais com quem usa o produto todo dia, errar rápido e corrigir mais rápido ainda. Foi o case que validou, com dados e com dor, tudo que a gente vinha tentando construir como cultura.

Hoje, quando olho pra trás, de uma empresa de benefícios para uma plataforma multiproduto, o que fez a diferença nunca foi ter acertado tudo de primeira. Foi ter construído um time que aprende rápido, que trabalha junto de verdade e que não tem medo de errar perto do cliente. É isso que continua fazendo a Flash voar.