Já passou pela situação em que Suporte, CS e Comercial falam idiomas diferentes e cada sprint vira um campo minado de demandas conflitantes? Quais estratégias você usaria para destravar esse impasse e manter o foco no valor real do produto?
Convidamos Rafael Casagrande, Group Product Manager na Olist, para responder 6 perguntas e compartilhar insights práticos sobre:
Como reduzir ruído e retrabalho para que as entregas atendam à diversidade de necessidades do negócio;
Como transformar o “não” em instrumento de alinhamento, equilibrando as demandas da liderança e do time;
Quais sinais buscar para validar se uma ideia está pronta para execução com eficiência.
Pensando nas etapas de processo de upstream, qual fase tende a gerar mais ruído ou retrabalho na sua operação atual? Como você tem atuado sobre isso?
Acredito que teria diferentes respostas para essa pergunta em diferentes momentos da minha carreira. Já enfrentei bastante retrabalho em fases como discovery e prototipação, por exemplo. Mas o desafio mais recente — e talvez o mais ruidoso — tem sido o alinhamento da solução proposta com stakeholders seniores de diferentes áreas.
Naturalmente, cada área espera que a próxima sprint contemple entregas que alavanquem seus próprios objetivos. O time de Suporte espera soluções que reduzam o contact rate. O time de CS busca ganhos em escala e eficiência operacional. Já o Comercial quer ver no ar aquela funcionalidade que os clientes vivem mencionando que o concorrente tem. A questão é que, dentro de uma sprint de produto, lidamos com um número limitado de entregas para atender a uma diversidade de necessidades do negócio.
Como conciliar tudo isso?
Passamos a trabalhar com cerimônias de priorização trimestral (quarterly prioritization), onde cada time de produto é responsável por apresentar e defender suas propostas ao time executivo — utilizando o formato de PRFAQs. As soluções defendidas já consideram tanto a capacidade alocada em iniciativas críticas quanto os desejos de stakeholders internos e externos.
Ao obter esse alinhamento diretamente com a camada executiva, conseguimos garantir um direcionamento claro e consensual, que depois é cascateado para as áreas envolvidas. Esse modelo tem reduzido significativamente o ruído e o retrabalho, e temos colhido bons resultados com ele nos últimos quarters.
Na sua realidade, o que é mais difícil: dizer não para a liderança ou para o próprio time? Qual dos dois mais pressiona o portfólio a se desviar das prioridades certas?
Acredito que não existe uma resposta única para essa pergunta. Já atuei com lideranças muito rígidas, com pouca abertura para debate, e também com lideranças altamente colaborativas e acessíveis. Do mesmo jeito, já tive no time pessoas extremamente racionais, que usavam afirmações como ponto de partida para o diálogo — e outras que tratavam opiniões como verdades absolutas.
No fim das contas, o mais difícil não é dizer “não” em si, mas entender o contexto por trás de cada “não”. A negativa, sozinha, não resolve nada. Ela precisa vir acompanhada de um racional claro, de dados, de priorização bem estruturada — ou, ao menos, de um probing bem feito que gere uma conversa produtiva.
O “não” faz parte da vida de Produto — e, na verdade, da vida profissional como um todo. O problema não é negar uma sugestão da liderança ou do time, mas negar sem critério. Quando o “não” é vazio, vira teimosia. Quando é fundamentado, vira alinhamento.
Na minha experiência, o que mais pressiona o portfólio a desviar das prioridades certas não é um lado específico, mas a ausência de clareza sobre o que é prioridade, e por quê.
Com clareza e transparência, o “não” deixa de ser um confronto — e vira só mais uma parte do processo.
O que você considera downstream bem feito? Tem algum padrão ou sinal que te mostra que uma ideia está realmente pronta pra ser executada com eficiência?
Essa é uma ótima pergunta — e, sinceramente, por muito tempo me questionei como saber, de forma confiável, se a solução que propomos realmente entrega valor para uma base ampla de clientes. Alguns times validam protótipos, outros apostam em uma boa fase de discovery e analisam métricas dias ou semanas após o rollout. Já experimentei diversos caminhos com meu time e, mesmo tendo bons resultados em alguns deles, sempre ficava aquela sensação de “estamos realmente no caminho certo?”.
Recentemente, adotamos uma prática que tem funcionado bem: a formação de squads de projeto. Esses squads reúnem pessoas de diferentes áreas — internas e externas — com conhecimento profundo no tema. Um exemplo foi o projeto de adequação à reforma tributária, que afeta empresas que atuam com fiscal ou faturamento. Formamos um squad com representantes de Legal, Tax, Produto, Engenharia, Suporte Fiscal, Design, além de contadores e clientes. Trabalhar lado a lado com stakeholders que têm contexto real reduz bastante o risco de entregas com baixo valor percebido.
Ainda assim, mesmo com todo esse cuidado no processo, acredito que nada substitui o acompanhamento contínuo de métricas — tanto durante os testes quanto após o rollout completo. Monitorar essas métricas de forma viva é o que nos dá segurança de que a entrega realmente foi bem-sucedida.
Como você define o que é “performance aceitável” para um produto ou funcionalidade nova? Que tipos de métrica ou comportamento você espera enxergar nos primeiros dias ou semanas?
Naturalmente, toda nova funcionalidade nasce a partir de uma dor conhecida — seja algo que os clientes precisam fazer de forma ineficiente, ou algo que simplesmente não conseguem fazer. Essas dores deixam marcas, e essas marcas são mensuráveis. Um exemplo recente foi a criação de um novo fluxo de onboarding, onde a dor anterior estava na complexidade da configuração tributária. As “marcas” que buscamos acompanhar nesse caso foram a melhora na taxa de won e o engajamento de novos clientes com o fluxo.
Para novos recursos, temos o privilégio de estruturar lançamentos versionados, o que nos permite observar a performance em diferentes estágios: ambiente de teste, produção controlada (com poucos usuários), produção em larga escala e, por fim, o rollout completo. A partir daí, avaliamos entrega de valor, completude da funcionalidade, experiência de uso e estabilidade.
No pós-lançamento, acredito que a avaliação deve ser feita tanto no quantitativo quanto no qualitativo, cada um com sua abordagem. No lado quanti, utilizamos ferramentas como Mixpanel para medir taxa de sucesso nos fluxos, engajamento, etapas de desengajamento, taxa de adoção etc. No quali, aplicamos métricas como CES (Customer Effort Score) e CSAT (Customer Satisfaction), especialmente em funcionalidades mais sensíveis ou core.
Além disso, criamos uma funcionalidade interna que permite que o próprio usuário registre sua opinião sobre o recurso lançado — o que funcionou, o que ainda sente falta e o que espera para as próximas versões. Isso nos traz insights riquíssimos diretamente da base.
De forma geral, entendo que todo projeto precisa nascer com uma definição clara de sucesso, baseada em dores já conhecidas. Ter esse alinhamento antes do início da entrega nos ajuda a entender, logo nas primeiras semanas, se estamos caminhando em direção ao PMF da feature.
Qual prática, rotina ou métrica que é comum no mercado, mas que na sua experiência mais atrapalha do que ajuda seu time?
Não é exatamente uma prática ou métrica específica, mas algo que tenho observado com frequência no mercado: a romantização excessiva da teoria em Produto.
Ao longo dos anos trabalhando com times diversos, entrevistando profissionais e acompanhando a evolução do mercado, percebi um movimento crescente em que a disciplina de produto tem se tornado cada vez mais lúdica e teórica.
Conhecer frameworks, métodos e buzzwords é importante, claro. Mas sem domínio do contexto onde se está atuando, toda essa teoria vira palpite.
No meu time, tenho buscado formar pessoas com profundo conhecimento do contexto em que estão inseridas. Avaliamos background, interesses e criamos processos que fomentam a especialização. Isso tem elevado bastante a qualidade das entregas e reduzido o tempo de desenvolvimento. Resumidamente: o time entrega mais e melhor.
Também tenho mentorado pessoas iniciando na área de produto. E a primeira coisa que faço é colocá-las para trabalhar em algo prático. Se estamos aprendendo a fazer um research, vamos aplicar em um problema real — seja na empresa onde a pessoa trabalha hoje, seja em um produto que ela usa no dia a dia, como um app de streaming ou um serviço de entrega.
A teoria é essencial, mas ela só ganha valor quando é colocada em prática. Prática é a teoria materializada — e é ela que transforma conhecimento em resultado.
No cenário atual, o que você enxerga como os principais fatores que ainda travam a operação de GPMs em times que já têm processo estruturado, mas seguem com dificuldade para entregar valor de forma consistente?
As causas podem variar bastante, mas de forma geral, vejo dois grandes vilões que se somam: a alta carga de demandas prioritárias e a má estruturação dos times e dos processos. Juntas, essas duas forças acabam travando até mesmo operações que já têm uma certa maturidade.
Ao longo de 8 anos trabalhando com Produto, não me lembro de um único momento em que ouvi de algum líder de Produto ou Tech a frase: “a esteira está tranquila”. Isso me fez refletir se esse equilíbrio entre urgências e capacidade realmente existe — ou se estamos sempre lidando com um descompasso entre o que é pedido e o que conseguimos entregar.
Partindo do princípio de que esse cenário “ideal” talvez nunca chegue — e que ele está fora do meu controle — passei a focar naquilo que posso de fato organizar: montar os times certos, com as pessoas certas nos lugares certos, e garantir que os processos sejam pensados para maximizar velocidade e qualidade.
Isso inclui tanto adicionar rotinas realmente necessárias quanto remover aquelas que seguimos apenas por hábito (o que, aliás, é mais importante — e subestimado — do que parece). Reavaliar constantemente o que estamos fazendo e por quê é um passo essencial para destravar operações e voltar a gerar valor de forma consistente.