Lançar é metade: rollout, feedback e iteração

Existe um alívio traiçoeiro no dia do lançamento. A feature está no ar, o time comemora, todo mundo respira. E aí mora o erro mais comum de produto: tratar o lançamento como linha de chegada. Lançar não encerra nada. Lançar é o momento em que o produto finalmente encontra a realidade — e a realidade sempre tem opinião.

Na ClubPetro a gente aprendeu a tratar o pós-lançamento com o mesmo rigor do pré. Porque a distância entre "está no ar" e "está gerando valor" é onde a maioria das features boas morre em silêncio.

Rollout: colocar no ar não é abrir a porteira

Ship rápido não significa ship descuidado. Justamente porque a gente lança com frequência, o jeito de lançar importa:

• Aos poucos, quando o risco pede. Feature que mexe em fluxo crítico da operação do cliente não estreia pra todo mundo de uma vez. Colocar primeiro pra um grupo menor deixa a gente ver o comportamento real antes de expor a base inteira a um erro.
• Com caminho de volta. Antes de lançar, a pergunta obrigatória: se der errado, como a gente desliga? Lançamento sem plano de reversão é aposta, não estratégia.
• Com o time interno preparado. Nosso time de CS conversa com cliente todos os dias. Se ele descobre a novidade junto com o cliente, a gente falhou. Quem está na linha de frente precisa saber o que mudou, por que mudou e o que responder — antes do primeiro cliente perguntar.
• Com comunicação que respeita o usuário. Dono de posto e gestor de rede não acordam curiosos sobre nosso changelog. Eles têm uma operação pra tocar. A comunicação de lançamento precisa responder uma única pergunta: o que isso resolve pra mim?

Feedback: ir atrás, não esperar

Depois do lançamento, o silêncio é o pior sinal possível — e o mais comum. A ausência de reclamação não significa que está tudo bem; normalmente significa que ninguém se importou o suficiente pra reclamar. Feedback de verdade a gente vai buscar:

• O uso conta a primeira história. Quem ativou? Quem completou o fluxo? Onde as pessoas travam ou desistem? Os dados de uso mostram o comportamento que ninguém verbaliza.
• A conversa conta a segunda. Os números dizem que o cliente parou na segunda tela; só a conversa revela por quê. Depois de lançar, a gente conversa com quem usou — e, mais importante, com quem deveria ter usado e não usou.
• O CS é radar contínuo. Cada dúvida repetida que chega ao suporte é feedback sobre o produto. Se muita gente pergunta a mesma coisa, o problema não é o cliente: é a interface, o fluxo ou o conceito.
• Reação negativa é presente. Cliente que reclama está gastando energia pra te ajudar de graça. A reclamação incômoda de hoje é o churn evitado de amanhã — desde que alguém escute.

Iteração: a segunda versão é a que acerta

Quase nenhuma feature nasce certa. A primeira versão é a melhor hipótese que a gente tinha com a informação disponível — e a informação disponível antes do lançamento é sempre incompleta. A versão que realmente resolve costuma ser a segunda ou a terceira, moldada pelo atrito com o uso real.

Por isso a gente não lança e passa pro próximo item da lista. Lançou, acompanha, ajusta. Às vezes o ajuste é pequeno: um texto que ninguém entendia, um campo fora de ordem, um passo desnecessário no fluxo. Às vezes é estrutural: a solução atacava o problema pelo ângulo errado e precisa ser repensada. E às vezes — isso exige honestidade — a resposta certa é remover. Feature que não vingou depois de iteração e esforço genuíno de adoção não é patrimônio, é entulho. Manter tudo pra sempre é como nunca jogar nada fora: um dia a casa fica inabitável.

Ser AI-native ajuda demais nesse ciclo. Iterar ficou barato: ajustar, testar e recolocar no ar é questão de horas ou dias, não de sprints. Mas velocidade de iteração só vale alguma coisa com direção — e direção vem do feedback que a gente foi buscar.

Metade do trabalho, metade do talento

Muita gente entra em produto apaixonada pela primeira metade: descobrir, desenhar, construir, lançar. A segunda metade — acompanhar, ouvir, ajustar, insistir, às vezes desistir — tem menos glamour e mais impacto. É nela que uma feature lançada vira uma feature que importa.

Se você é do tipo que lança e fica curioso — que quer saber o que aconteceu depois, que sente incômodo com pergunta sem resposta — você tem o instinto certo pra essa área. Aqui, ninguém pergunta só "lançou?". A pergunta que vale é "resolveu?". E essa a gente só responde depois do lançamento.