BLiP

Transformar uma plataforma de mensageria existente em um produto SaaS exigia desenvolver rapidamente novas capacidades enquanto continuávamos atendendo clientes, corrigindo bugs e mantendo a plataforma em operação. Ao mesmo tempo, precisávamos evitar uma divisão permanente entre quem construía o futuro do produto e quem ficava responsável apenas pela manutenção.

Em 2016, depois de alguns anos na Take Blip, passei a atuar como Manager e Developer de duas squads. Uma delas trabalhava em um aplicativo próprio de mensagens OTT, posteriormente descontinuado após mudanças no mercado e a abertura da plataforma do WhatsApp. A outra era responsável pelo MensagemHub, plataforma que evoluiria para o BLiP. Com a saída do Product Manager, assumi também responsabilidades de produto e participamos da transformação do MensagemHub em um produto SaaS onde empresas poderiam construir e operar seus próprios chatbots.

Atuei inicialmente como Engineering Manager e Developer, mantendo participação direta no desenvolvimento. Nesse período, criei a primeira versão do BLiP Chat. Com a saída do Product Manager, passei também a assumir responsabilidades de Product Management, incluindo roadmap, priorização e evolução do produto. Também fui responsável por reestruturar a equipe, introduzir papéis que ainda não tínhamos e definir, no nível tático, como transformar o roadmap em software entregue.

Além da evolução do produto, desenhei um modelo operacional baseado em Focus Teams temporárias e uma Core Team. As Focus Teams trabalhavam protegidas das interrupções operacionais em problemas estratégicos do produto durante ciclos fixos de dois meses, enquanto a Core Team mantinha a plataforma funcionando. Ao final de cada ciclo, as pessoas retornavam ao Core e compartilhavam com toda a equipe o conhecimento adquirido e as decisões tomadas.

Cada Focus Team trabalhava em ciclos de dois meses: duas semanas para discovery, estudo do problema e definição da abordagem; aproximadamente um mês para desenvolvimento; e duas semanas finais para estabilização, documentação, débitos técnicos e melhorias. A equipe recebia um problema a ser resolvido e tinha autonomia para estudar e definir a solução. Paralelamente, a Core Team utilizava um fluxo baseado em Kanban para bugs, incidentes, chamados e pequenas melhorias. Ao terminar o ciclo, os integrantes da Focus Team retornavam ao Core, difundiam o conhecimento da nova funcionalidade e uma nova Focus Team era formada para o próximo problema.

Uma decisão central foi não criar equipes permanentes de inovação e manutenção. As Focus Teams eram temporárias e suas pessoas rotacionavam, permitindo que diferentes talentos participassem da evolução do produto. A composição considerava tanto as competências necessárias para cada problema quanto a distribuição de oportunidades. Também tornamos o compartilhamento de conhecimento uma responsabilidade explícita de quem retornava de uma Focus Team, reduzindo silos e mantendo a equipe alinhada com a evolução da plataforma.

O trabalho envolveu a evolução de uma plataforma de mensageria para um produto SaaS voltado à construção e operação de chatbots. Além de decisões de produto e organização, continuei participando de discussões técnicas, arquitetura, protótipos e desenvolvimento. Entre as entregas desse período esteve a primeira versão do BLiP Chat, criada para permitir experiências de conversação integradas a websites.

O principal desafio era equilibrar quatro necessidades simultaneamente: acelerar a inovação necessária para transformar o produto, manter a plataforma existente em operação, manter os talentos motivados e distribuir o conhecimento das novas funcionalidades por toda a equipe. O crescimento do produto e da engenharia também exigiu que o próprio modelo organizacional evoluísse ao longo do tempo.

O modelo ajudou a criar capacidade para evoluir rapidamente o BLiP sem interromper a operação da plataforma existente. Durante aproximadamente um ano operamos com uma Focus Team e uma Core Team. Com o crescimento da equipe, o modelo evoluiu para duas Focus Teams trabalhando simultaneamente e uma Core Team. A rotação também ajudava a distribuir progressivamente o conhecimento das novas funcionalidades, evitando que ele permanecesse concentrado apenas nas pessoas que as desenvolveram.