Não se muda cultura com decreto, e sim com resultado

Mudar a cultura de uma empresa é um desafio que muitos líderes enfrentam. O erro mais comum? Achar que cultura pode ser transformada por decreto, com regras, discursos ou apresentações institucionais. A realidade, porém, é que cultura não muda porque alguém mandou — ela muda quando as pessoas veem um novo comportamento gerar resultados e passam a adotá-lo.

Ou seja, cultura não muda com decreto, mas com resultado.

Cultura não muda com decreto, mas com resultado.

Por que cultura não muda por decreto?

Quando uma líder anuncia que “a partir de agora, seremos mais colaborativos”, “teremos uma cultura orientada a dados” ou “vamos adotar uma mentalidade ágil”, isso pode até soar inspirador. Mas sem exemplos concretos e resultados que validem essa mudança, a nova diretriz tende a ser ignorada ou até gerar resistência.

Isso acontece porque a cultura de uma empresa nada mais é do que o conjunto de comportamentos esperados em determinadas situações. E comportamentos não mudam com palavras — mudam com experiências.

Se queremos que uma equipe adote uma nova maneira de reagir, precisamos mostrar essa nova reação em prática, demonstrando que ela gera valor.

Exemplo prático: O app do corretor da Lopes

Quando entrei na Lopes, a equipe estava trabalhando em um “MVP” de um aplicativo para seus corretores. Coloquei aspas porque estava em desenvolvimento há 7 meses e ainda faltavam 2 ou 3 meses para ele ser entregue. Quando me aprofundei um pouco mais sobre o processo e por que estava demorando tanto, aprendi algumas coisas:

• O discovery durou algo em torno de 5 meses!;
• O discovery foi focado apenas na descoberta do problema, não na descoberta da solução;
• O discovery foi feito apenas internamente, com levantamento de demanda das áreas de negócios e benchmarking com outros aplicativos para corretores disponíveis no mercado, sem nenhuma conversa com clientes;
• O “MVP” foi definido com 58 requisitos e funcionalidades e já havia mais 90 requisitos e funcionalidades com escopo definido para serem desenvolvidos após o lançamento do “MVP”;
• O principal problema a ser resolvido foi baseado na hipótese de que, se a corretora recebeu um lead, que é um potencial cliente interessado em um imóvel, quanto mais rápido ela receber esse lead e interagir com o cliente, maiores serão as chances de fechar um negócio;
• Em seguida, a equipe analisou a jornada da corretora e percebeu que, quando um lead chega, a corretora precisa pesquisar no banco de dados de potenciais clientes da Lopes para verificar se o potencial cliente do lead já está em nosso banco de dados e, caso não esteja, cadastrar seus dados em nosso sistema.
• A partir dessa análise da jornada da corretora, o time percebeu então que, se a corretora pudesse enviar algumas outras opções de imóveis para o cliente em potencial, isso aumentaria as chances de fechar um negócio;
• Esse processo criou o escopo a ser implementado, que levou em torno de 5 meses de discovery, mais 7 a 8 meses de desenvolvimento para construir o aplicativo “MVP”. Ou seja, mais de 1 ano para fazer um “MVP”. 😱

Há alguns pontos a se destacar desse processo:

• O processo de descoberta do problema foi muito longo, o que gerou uma enorme lista de problemas da corretora a serem resolvidos;
• A fase de descoberta da solução não foi executada. A equipe passou da descoberta do problema diretamente para a entrega, sem qualquer oportunidade de testar hipóteses de solução;
• A enorme lista de problemas a serem resolvidos impactava diretamente o processo de desenvolvimento de produto, tornando-o muito longo também;
• Se o trabalho de descoberta de solução fosse iniciado assim que o problema principal fosse descoberto (velocidade em colocar o lead na mão da corretora), provavelmente a equipe conseguiria conceber uma solução mais simples, que levaria dias e não meses para ser implementada.

Em relação a esse último ponto, após algumas discussões, pensamos em um aplicativo com apenas uma notificação push para cada lead recebido, e a corretora poderia continuar as outras tarefas como já estava habituada a fazer. E, para ser ainda mais simples de testar a hipótese da solução, pensamos em nem construir um aplicativo, mas enviar um SMS ou uma mensagem de WhatsApp para a corretora. Um teste A/B pode ser feito para comparar as taxas de fechamento de negócios dos corretores que receberam notificação por SMS com as taxas de fechamento dos corretores que não receberam.

Mesmo tendo avançado bastante no desenvolvimento do app, acabamos tomando a decisão de implementar a notificação por SMS. Demoramos 10 dias para implementá-la e logo em seguida conseguimos testar a hipótese de que, quanto mais rápido um corretor receber um lead e interagir com o cliente, maiores as chances de fechar um negócio.

Esse exemplo do app para corretores da Lopes mostra a importância de dois princípios da Cultura de Produtos: a necessidade de 1) entregarmos rápida e frequentemente, e 2) de focarmos no problema e entendê-lo bem para criarmos e testarmos hipóteses de solução antes de desenvolver o produto.

Esse exemplo me ajudou muito na Lopes, pois eu o usava de exemplo sempre que o time de desenvolvimento de produto recebia demandas de implementação de soluções já especificadas. Quando essas demandas chegavam, a gente dizia: “Sua demanda é internessante, mas qual problema queremos resolver? Se vc nos disser o problema, o time pode encontrar soluções mais rápidas e baratas de implementar. Lembra do “MVP” do app do corretor?”.

Exemplo prático: Demanda de academia no Wellhub

Outro exemplo muito interessante aconteceu no Wellhub, que antigamente era conhecida por Gympass. Quando eu ingressei no Wellhub, em 2018, o time de desenvolvimento de produto, incluindo pessoas engenheiras, designers e product managers, era muito pequeno, menos de 5% do total de funcionários da empresa. Normalmente tech companies têm de 25% a 40% de seus funcionários pertencentes a esse time. Em função do time ser pequeno e não praticar a Cultura de Produto, esse time acabava se focando em atendar as demandas das outras áreas da empresa.

Certa vez, uma dessas áreas, a de parcerias com academias, chegou com uma demanda para o time de desenvolvimento de produto. A gerente de parcerias estava fechando com uma nova academia e ela disse que para fechar a parceria, a academia estava demandando que mudássemos o processo de check-in para incluir a assinatura eletrônica de um termo de responsabilidade que a academia solicita para todas as suas novas alunas. Explicamos que essa era mudança demorada e que para a usuária final ficaria muito estranho ter essa mudança no forma de fazer check-in em somente uma academia específica.

Pedimos para a gerente de parcerias se podíamos conversar com a academia para entender melhor o problema. Fizemos uma reunião com a pessoa da academia e também com a pessoa que cuidava de temas jurídicos da academia. Perguntamos o porquê dessa demanda e se esse formato pedido era obrigatório, ao que elas disseram que não, que era só uma sugestão. Nesse momento questionamos se um link para o termo de responsabilidade com um texto dizendo “Ao fazer check-in nessa academia você concorda com o Termo de Responsabilidade disponível no endereço XPTO”. A pessoa do jurídico disse que sim, que isso já atendia. Aí mostramos esse texto implementado, uma vez que esse texto era um campo opcional que pode ser preenchido quando do cadastramento de uma nova academia, e todos ficaram felizes. As pessoas da academia, por ter seu problema resolvido, a gerente de parcerias, por conseguir atender uma demanda da cliente para poder fechar a parceira, e o time de desenvolvimento de produto, por não ter que fazer um novo desenvolvimento específico para uma cliente.

A partir desse dia, a gerente de parcerias passou as nos trazer as demandas de novas parcerias dizendo “Olha a academia pediu isso aqui, mas acho melhor vocês conversarem com eles para entender melhor o problema”. E claro que passamos a usar esse exemplo internamente para ilustrar a importância do foco no problema, um dos princípios da Cultura da Produto.

A fórmula da mudança cultural

Esses exemplos ilustram um modelo simples, mas poderoso, para transformar a cultura de uma empresa:

1. Adote a mudança primeiro — Antes de exigir que todos mudem, experimente a nova abordagem com um grupo menor.
2. Gere resultados claros — Mostre, com números e exemplos concretos, que a mudança funciona.
3. Compartilhe o aprendizado — Dê visibilidade ao impacto positivo da mudança para que outros se sintam motivados a aderir.

Treinamento e consultoria em gestão de produtos e transformação digital

Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a enfrentarem seus desafios e oportunidades de produtos digitais por meio de treinamentos e consultoria em gestão de produtos e transformação digital.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 4 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

• Transformação digital e cultura de produto: Como colocar a tecnologia no centro da estratégia de sua empresa
• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.