Este artigo faz parte da série Erros de Organização de Times, que vai explorar os padrões mais comuns de disfunção em organizações de produto, e o que fazer a respeito.

Recebi uma mensagem no WhatsApp de uma pessoa que estava buscando uma Diretora de Engenharia para uma fintech. O perfil era interessante: empresa em fase de crescimento, com forte protagonismo de tecnologia, e foco em aquisição de novos clientes. Perguntei sobre o time. Ela me respondeu: “São cerca de 15 pessoas divididas em 3 times para atender Marketing, Vendas e Novos Negócios.”

A palavra “atender”, junto com essa dedicação de times por área interna, revela muito sobre como a empresa enxerga seu time de tecnologia. Não é um time de produto. É um time de serviço interno. Cada time com foco em servir uma área da empresa.

O padrão que se repete

Esse modelo é mais comum do que parece. A empresa cresce, as áreas internas começam a demandar mais tecnologia, e a solução natural parece ser criar times dedicados a cada área: um time para o financeiro, um para o suporte, um para marketing, um para vendas. Cada área tem “o seu” time.

À primeira vista, parece organizado. As áreas internas ficam satisfeitas porque têm capacidade dedicada. A liderança consegue responder “qual time cuida disso?” para qualquer demanda. O roadmap fica claro: cada time tem seu backlog e cada stakeholder sabe a quem recorrer.

O problema é que esse modelo otimiza para a satisfação dos stakeholders internos, e não para os resultados do produto e do negócio.

O que muda quando a cliente é interna

Quando um time existe para “atender” uma área interna, a dinâmica de trabalho muda de forma fundamental.

O time de tecnologia focado no marketing recebe demandas do time de marketing. O time de tecnologia focado em vendas recebe demandas do time de vendas. A priorização é feita pela área interna, com base nas suas necessidades do momento. O time implementa o que foi solicitado. Entrega o que foi solicitado. É avaliado pela capacidade de atender às demandas.

Essa forma de operar é o que eu chamo de time de funcionalidades ou de projeto. O stakeholder define o que fazer e o time implementa. Não há autonomia para o time decidir o que vai gerar mais resultado. Não há responsabilidade pelo outcome, só pelo output.

O time de produto, por outro lado, recebe um problema para resolver e um resultado para gerar. Ele tem autonomia para decidir como resolver esse problema. E é responsável não só por entregar algo, mas por gerar resultado a partir de suas entregas, tanto para a empresa quanto para a cliente.

Quando a “cliente” é uma área interna, essa responsabilidade por resultado some. O time de tecnologia entregou a funcionalidade que o marketing pediu? Ótimo, missão cumprida. Se a funcionalidade não gerou resultado nenhum, a culpa é do marketing, que pediu a coisa errada.

Um exemplo concreto do que isso gera na prática: na Lopes, um dos grandes objetivos da diretoria comercial era crescer o número de corretoras associadas. Como corretores são autônomos e podem se desvincular de uma imobiliária a qualquer momento, a área comercial pediu que os leads, que são pessoas interessadas em comprar ou alugar um imóvel, fossem distribuídos de forma sequencial entre as corretoras. Assim, nenhuma ficaria sem receber leads, o que ajudaria a retê-las. Só que essa solução era ruim tanto para a cliente quanto para a empresa. O objetivo final não é distribuir leads de forma justa entre corretoras, é ajudar a cliente a encontrar o melhor imóvel. E para isso, o mais indicado é entregar o lead não para a próxima corretora da lista, mas para a corretora com mais condições de fechar aquela venda específica. Um time de produto teria questionado o pedido e buscado a solução que gerava o melhor resultado para a cliente e para a empresa. Um time focado em atender uma área interna entrega o que foi solicitado.

O problema da priorização por HiPPO

Em times organizados por área interna, a priorização tende a seguir o que chamo de técnica HiPPO: Highest Paid Person’s Opinion (a opinião de quem tem o maior salário).

A VP de Marketing decide o que o time de tecnologia de Marketing vai fazer. A Head de Vendas decide o que o time de tecnologia de Vendas vai fazer. Não há um processo de priorização baseado em evidências sobre o que vai gerar mais resultado para o negócio. Há uma negociação política entre áreas, onde quem tem mais influência consegue mais capacidade do time de tecnologia.

O resultado prático: o time de tecnologia trabalha muito, entrega várias features, mas gera pouco resultado real. Porque o critério de priorização não é “o que vai gerar mais resultado?” mas sim “o que a área interna mais influente quer agora?”

O que a fintech deveria estar buscando

Voltando ao exemplo da pessoa que me pediu indicação de uma Diretora de Engenharia que vai liderar um time organizado em times focados em áreas internas. Essa diretora vai passar boa parte do seu tempo gerenciando expectativas de stakeholders internos e negociando capacidade entre áreas. Vai ter pouco espaço para construir um time focado em resultados de produto.

O problema não é a Diretora. O problema é a estrutura.

Se a fintech está em fase de crescimento com foco em aquisição de clientes, faz muito mais sentido organizar os times em torno de objetivos de produto, como aquisição, ativação, retenção, do que em torno de áreas internas. Um squad focado em aumentar a taxa de conversão de novos clientes tem um objetivo claro, mensurável, diretamente ligado ao resultado do negócio. Um squad que “atende Marketing” tem uma lista de tarefas.

Como saber se você tem esse problema

Algumas perguntas que ajudam a identificar se sua organização caiu nesse padrão:

• Os times são descritos pelo nome da área interna que atendem, e não pelo problema de produto que resolvem?
• A priorização do backlog é feita pelos stakeholders internos, e não pelo próprio time, com base em evidências?
• O time é avaliado pela quantidade de demandas entregues e não pelos resultados gerados para o negócio e para a cliente?
• Quando algo não funciona, a conversa é sobre “o time entregou o que foi pedido?” e não sobre “o que aprendemos e como ajustamos?”

Se a resposta para a maioria dessas perguntas for sim, você provavelmente tem times de funcionalidade disfarçados de times de produto.

Times voltados para o interno existem, e são necessários

Antes de continuar, preciso fazer uma distinção importante: o problema não é ter times cujo foco são as necessidades de outras áreas da empresa. O problema é como esses times operam.

Ao longo da minha carreira, trabalhei com times com foco nas necessidades internas assim em vários lugares. Na Locaweb e na Lopes, chamávamos de Sistemas Centrais. No Gympass, o nome era Crossfeatures, uma brincadeira com crossfit e a necessidade de atender aos outros times da empresa. E na Conta Azul, os mais criativos com nomes, chamávamos esse time de Hubble, porque esse time ajudava a enxergar o universo Conta Azul e precisava de manutenções críticas em pleno voo para que ele se mantivesse operando.

Esses times existiam, tinham foco claro nas necessidades internas e funcionavam bem. A diferença estava no modo de operação.

Um time voltado para o interno que opera como time de produto não simplesmente recebe demandas e as implementa. Ele entende profundamente quem são suas “clientes”, as outras áreas da empresa, e conecta essas necessidades com os objetivos estratégicos do negócio. Ele faz discovery, prioriza com base em impacto, e é responsável por resultados, não só por entregas.

A pergunta certa não é “qual área esse time atende?”, mas sim “esse time tem autonomia para decidir como gerar resultado para quem atende?”

Não é um problema de nomenclatura

É tentador achar que a solução é simples: renomear os times. Chamar de “Time de Crescimento” em vez de “Squad de Marketing”. Mas o problema não está no nome, está na lógica de como o time foi criado e de como opera.

Um time que existe para atender a uma área interna vai continuar operando como um fazedor de funcionalidades, mesmo que você mude o nome. O que precisa mudar é a forma como os objetivos são definidos, a priorização é feita e quem é responsável pelos resultados.

Isso requer uma conversa diferente e mais difícil com as áreas internas. Requer que elas abram mão do controle sobre “o seu” time de tecnologia e passem a colaborar com um time que tem autonomia para decidir como gerar resultado.

Não é uma mudança fácil. Mas é a mudança certa.

Resumindo

• Times organizados por área interna não são necessariamente um erro, desde que operem como times de produto. O problema ocorre quando o modelo de operação é o de fábrica de funcionalidades: a área pede, o time entrega, mas não é responsável pelo resultado dessa entrega.
• Os sinais de alerta são claros: times nomeados pela área que atendem, priorização feita pela stakeholder interna, avaliação pelo volume de entregas e ausência de questionamento sobre se o que foi pedido é realmente o que vai gerar resultado.
• A solução não é renomear os squads. É mudar o modelo de operação: dar autonomia ao time para entender o problema, conectar as necessidades internas aos objetivos da empresa e ser responsável pelos resultados, não apenas pelas entregas.
• Times com foco interno podem e devem existir. O Hubble da Conta Azul, o Crossfeatures do Gympass, os Sistemas Centrais da Locaweb e da Lopes são exemplos de que esse foco pode funcionar muito bem. O que faz a diferença é se o time opera como um time de projeto ou como um time de produto.

Masterclass: Por que a Estratégia Não Chega ao Produto

Nesta masterclass de 3 horas, Paulo Caroli e eu vamos explorar por que a estratégia se perde no caminho entre a liderança e os times, e como resolver isso. Três horas de conversa prática, com modelos que você pode aplicar na semana seguinte.

O objetivo é entender como transformar direção estratégica em decisões reais de produto.

Mais informações e inscrição:

https://www.gyaco.com/masterclass-caroli-e-joca/

Treinamento e consultoria em gestão de produtos

Ajudo empresas e lideranças (CPOs, heads de produto, CTOs, CEOs, tech founders e heads de transformação digital) a conectar negócios e tecnologia por meio de treinamentos e consultoria focados em gestão de produtos e transformação digital.

Podcasts da Gyaco

Na Gyaco, acreditamos no poder das conversas para promover reflexão e aprendizado. Por isso, temos o podcast Produto em Pauta, que explora o universo de gestão de produtos por ângulos diferentes:

• Mentorias: Nesta série, compartilho conversas reais de mentoria com profissionais de produto, partindo da ideia de que as perguntas de uma pessoa muitas vezes são as perguntas de muitas outras. Exploramos desafios concretos, refletimos juntas e transformamos experiência em aprendizados práticos que você pode aplicar no seu próprio contexto.
• Sem Filtros: Nessa série de episódios, Fabio Duarte, Paulo Caroli e eu temos conversas francas sobre produto, tecnologia e os incômodos reais que estamos vendo nas organizações.
• Além das Buzzwords: Nessa série de episódios, Felipe Castro e eu desmistificamos termos de produto com exemplos reais de nossas clientes.

Disponível no YouTube e no Spotify. Gravada em português e, no YouTube, com legendas em inglês.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer aumentar as chances de sucesso do seu produto, resolver os problemas das usuárias e atingir os objetivos da empresa? Conheça meus livros, onde compartilho o que aprendi ao longo de mais de 30 anos criando e gerenciando produtos digitais:

• 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.