Você está estruturando seu time de produto do jeito certo?
TEMPO DE LEITURA: 10 A 12 MIN
Estruturar times de produto de forma eficaz é fundamental para impulsionar a inovação, otimizar a produtividade de equipes e entregar experiências de alta qualidade em toda a jornada do usuário. No entanto, a dúvida mais recorrente entre os CPO's (Chief Product Officer) é: como realizar essa distribuição de modo que as equipes operem de maneira eficiente e produtiva?
Neste artigo, iremos falar sobre os temas mais relevantes para a gestão de CPO's, quando o assunto é estruturar times de produto, como estrutura mínima de time, Topologia de Times, Lei de Conway e carga cognitiva. Além de trazer um compilado valioso de dúvidas reais de líderes de produto que foram respondidas pelo Joaquim Torres, que é Advisor e Consultor de Gestão de Produtos e Transformação Digital e Mentor do IFTL, durante uma de nossas Masterclass.
Entre os temas questionados pelos CPO's estão:
- Diferença entre os papeis de Product Manager e UX Designer;
- Como evitar gargalos nas squads estruturais?
- Integração entre o time de Design Ops e UX
- Como migrar a estruturação de time por produto para um modelo por jornada do usuário
- Como reestruturar times de produto, quando é necessário refazer o software?
Por isso, não deixe de acompanhar até o final. Todas as dúvidas foram respondidas com base na experiência real do Joca, ou seja, trazem exemplos práticos de como resolver gaps e maximizar a performance das suas estratégias como CPO
Qual é a estrutura mínima de um time de produto?
O time mínimo de desenvolvimento de produto é composto por um Product Manager, um Product Designer e dois ou mais engenheiros.
"O time de desenvolvimento de produto é quem vai executar a estratégia e atingir os objetivos para alcançar a visão de produto". Joca Torres
Esse time mínimo pode também ser chamado de squad e deve ter no máximo umas 7 pessoas. Quanto maior o time, maior a dificuldade de coordenação. Na Amazon existe a famosa regra dos times de duas pizzas, ou seja, o tamanho máximo do time é aquele que consegue ser alimentado por duas pizzas grandes. A quantidade de interações entre os membros do time crescem rapidamente com o tamanho do time, seguindo a fórmula n*(n-1)/2.
Assim, enquanto um time de 5 pessoas tem 10 possibilidades de interação entre seus membros, em um de 7 pessoas esse número cresce para 21.
Quando juntamos dois ou mais squads temos um time de produto, que também pode ser chamado de tribo.
Essa tribo de produto pode ter um, dois ou três líderes. Se for uma pessoa líder, ela será responsável por liderar Product Managers, Product Designers e engenheiros. Se forem dois líderes, normalmente um vai liderar Product Managers e Product Designers, e o outro liderará engenheiros. Se forem três, um lidera Product Managers, outro, Product Designers e o terceiro, engenheiros.
Times de produto também podem ter alguns papéis compartilhados entre os squads.
3 principais objetivos de estruturar times de produto dedicados por squad:
- Tamanho de squad: manter o squad pequeno é importante para conseguir preservar a agilidade desse time. Quanto maior o time, maior a necessidade de coordenação entre os membros do time.
- Ownership: a partir do momento em que você tem uma pessoa no squad com uma função específica, essa função deixa de ser responsabilidade dos outros membros do time. Por exemplo, se tivermos uma pessoa cuidando da qualidade, esse tema virará responsabilidade dela, e as outras pessoas do squad vão se preocupar menos com o tema. As exceções são as três funções primárias de um squad que são engenharia, design de produto e gestão de produto.
- Alocação de recursos: além de o squad ficar grande se colocarmos esses papéis dentro dele, necessitando de mais coordenação e tendo o risco de ficar mais lento, cada squad custará mais caro. Com squads menores, temos a possibilidade de alocar os recursos que você tem disponível para desenvolvimento de produto em mais squads que constroem produto.
Papéis existentes em uma tribo de produto compartilhado entre os diferentes squads:
- Agile Coach: ajuda os squads em seus processos e cultura ágil. Em vez de um scrum master por squad, tem-se um agile coach por tribo que ajuda os squads nesse tema, mas os processos e a cultura ágil de cada squad é responsabilidade de cada membro do squad.
- Quality Assistance: assim como processos e cultura ágil são responsabilidade de cada membro do squad, o mesmo acontece com qualidade. Em vez de um quality assurance por squad, é possível ter um quality assistance por tribo de produto, que vai ajudar cada squad com questões de qualidade.
- Data Analyst: todo squad gera muitos dados e precisa entender o que esses dados querem dizer. De novo, entender o que esses dados significam é uma responsabilidade do squad. Contudo, quando a estrutura de dados é muito complexa, pode fazer sentido ter uma pessoa por tribo de produto ajudando seus squads nas necessidades mais complexas de dados de cada squad.
- SRE: para produtos com muita integração com sistemas de terceiros pode ser interessante ter um Site Reliability Engineer (SRE) por tribo ajudando os squads a definir e implementar arquiteturas estáveis, com boa performance e resilientes.
- User Research: essa é a responsabilidade dos Product Designers, com apoio dos gestores de produto de cada squad. Em alguns casos, pode fazer sentido ter uma pessoa com foco em research na tribo de produto para ajudar nessas pesquisas de cada squad.
- Product Marketing: enquanto a missão da pessoa gestora de produtos é construir o produto ou funcionalidade que resolve problemas dos usuários, o Product Marketing tem por missão contar ao mundo sobre o produto ou funcionalidade e o problema que ele resolve. Esse “mundo” refere-se tanto aos usuários do produto quanto aos novos usuários que queremos trazer. É responsável por desenhar e implementar a estratégia de go to market (GTM) do produto. Em muitas empresas essa responsabilidade recai sobre a gestora de produtos. Isso funciona em muitos casos, mas pode tirar seu foco em construir o melhor produto ou funcionalidade.
Há outros papéis que podem ser compartilhados mas lembre-se de que, quanto mais papéis compartilhados tiver, mais difícil ficará a coordenação das pessoas da tribo. Na mentoria CPO do IFTL, o Joca recomenda ter no máximo 3 papéis compartilhados. Eles podem ser liderados pela(s) líder(es) da tribo ou pela líder da tribo estrutural correspondente à sua função.
Na Mentoria CPO do IFTL, o Joca aborda profundamente como estruturar times mínimos de produto, dando exemplos reais da aplicação do SRE na Conta Azul em que realizaram a integração com o sistema das Secretarias da Fazenda de cada estado para emissão de nota fiscal.
.png)
Confira quais são os temas abordados na Mentoria CPO do IFTL:
- Como liderar equipes de alta performance;
- Como gerir melhor suas atividades e prioridades;
- Estrutura e topologia de times de produto, design e engenharia;
- Responsabilidades, atribuições e hierarquias;
- Desenvolvimento de pessoas (PDI) e avaliação de performance;
- Gestão, cultura, rotinas e rituais de produto.
O que é Topologia de Times?
Topologia de Times, ou "Team Topologies" é o termo que os autores Matthew Skelton e Manuel Pais, especialistas em DevOps, utilizaram para descrever como as “topologias de equipes” devem ser organizadas para melhorar a sua comunicação e, assim, conseguir mais agilidade, aumentando a eficiência e produtividade de times de produto e de equipes como um todo.
"Uma comunicação clara e eficiente é a chave para garantir a fluidez das entregas em times de produto bem-sucedidas." Joaquim Torres
No geral, o que se observa no contexto de times e DevOps é uma má distribuição entre funcionários altamente capacitados, que assumem problemas complexos e ficam atolados, enquanto funcionários menos experientes lidam com problemas mais simples e comuns.
Para solucionar isso e ter mais produtividade, os autores avaliaram que estruturas estáticas de time funcionam melhor para concluir entregas de produtos com o resultado esperado; e que o trabalho poderia ter um rendimento superior se organizado seguindo uma lógica que favoreça a autonomia, a automatização e o auto serviço.
Para adotar esse conceito, é importante considerar os quatro principais tipos de organização de times de produto. em Topologias de Time.
Como estruturar times de produto com Topologias de Time:
- Por produto ou funcionalidade: É uma das formas mais comuns de organização de times de produto. Para cada produto ou funcionalidade temos uma tribo. Segundo o Joca, na Locaweb eles tinham times de produto para: Email Marketing, PABX virtual, cloud, hospedagem de sites e assim por diante. A principal vantagem dessa forma de organização é que a parte do produto que é responsabilidade da tribo é bem clara mas, por outro lado, com o foco no produto perde-se um pouco de perspectiva da(s) pessoa(s) cujos problemas esse produto resolve.
- Por jornada: Nesse modelo, os times são organizados de acordo com cada jornada do usuário. Busca, compra, agendamento de aula e assim por diante são jornadas pelas quais seu usuário pode passar ao usar o seu produto. Segundo o Joca, esse modelo não é o mais usual, mas é possível ver no mercado times organizados por produto ou por tipo de usuário terem uma ou mais tribos focadas em alguma jornada, como ele fez na Conta Azul com o time Hubble que cuidava da jornada do usuário até ele poder usar funcionalidades financeiras, cuidadas pelo Spartans e funcionalidades fiscais e contábeis, cuidadas pelo time Underground. A principal vantagem dessa estrutura é que o foco em uma jornada aumenta a chance de proporcionar uma ótima experiência naquela jornada específica. Por outro lado, normalmente um squad é suficiente para cuidar de uma jornada, então você pode acabar com muitas tribos de um só squad.
- Por objetivo: A organização por objetivo significa que a tribo tem foco em um objetivo específico. Conversão, retenção, experiência de uso etc. Esse modelo é menos usual ainda no mercado, segundo o Joca, contudo é possível executar como ele fez no Gympass em que tinha duas tribos divididas: uma voltada para crescimento/conversão e outra para experiência digital. Nesse tipo de organização, o principal benefício é o foco no lugar aonde você quer chegar, o objetivo. A desvantagem é que você pode ter dois squads com objetivos diferentes lidando com a mesma área do produto, o que pode causar uma experiência estranha para o usuário. Outra desvantagem é que, se a arquitetura de sistemas estiver muito acoplada, pode haver também muita dependência entre as equipes.
Como deve ter notado, cada topologia de time tem suas vantagens e desvantagens, e a escolha do melhor modelo depende das necessidades e características específicas de cada empresa e projeto. Também é comum que empresas utilizem uma combinação de diferentes topologias para otimizar a eficiência e produtividade de times de produto.
Como estruturar times de produto de forma híbrida, segundo a Topologia de Times?
Essas diferentes formas de organizar times de produto podem ser usadas em conjunto, ou seja, não são exclusivas. Na verdade, é raro um time de produto usando exclusivamente um tipo de organização.
É possível ter um time por produto e outro focado na jornada do cliente e assim por diante.
Quer saber como escolher a melhor estrutura de time usando o conceito de Topologia de Times e, inclusive, descobrir como o Joca realizou essa organização de forma híbrida em suas passagens pela Locaweb, Gympass, Conta Azul e Lopes? Inscreva-se na próxima Mentoria CPO do IFTL. Nela, trazemos exemplos práticos e estudamos caso a caso para indicar a melhor solução para aumentar a produtividade de times de produto.
.png)
Confira quais são os temas abordados na Mentoria CPO do IFTL:
- Como liderar equipes de alta performance;
- Como gerir melhor suas atividades e prioridades;
- Estrutura e topologia de times de produto, design e engenharia;
- Responsabilidades, atribuições e hierarquias;
- Desenvolvimento de pessoas (PDI) e avaliação de performance;
- Gestão, cultura, rotinas e rituais de produto.
O que você deve saber sobre a Lei de Conway?
A Lei de Conway, também conhecida como "Lei da Organização de Sistemas", foi proposta por Melvin Conway em 1967. Esse conceito nada mais é do que uma observação sobre a relação entre a estrutura organizacional de uma equipe e o design de sistema que ela produz.
Essa lei afirma:
"As organizações que projetam sistemas estão inevitavelmente limitadas a produzir projetos cujas estruturas sejam cópias das estruturas de comunicação dessas organizações."
Em outras palavras, a lei sugere que a arquitetura de um sistema de software refletirá a comunicação e a estrutura da equipe que o desenvolveu.
Assim, quando falamos da estruturação de times de produtos, essa lei ressalta a importância de alinhar a estrutura organizacional com a arquitetura desejada para os sistemas. Em um exemplo prático, se uma empresa deseja criar um sistema altamente modular e colaborativo, será necessário que sua estrutura organizacional também seja modular e permita uma comunicação eficiente entre os times de produto.
De maneira simples se sua comunicação com a área de negócio não é clara não adianta você trabalhar com as melhores tecnologias e engenheiros que a chance de não terem um produto de sucesso é grande, por outro lado se uma organização é arranjada em silos funcionais como QA, DBA, Frontend, Backend, etc é improvável que produza um produto bem arquitetado de ponta a ponta.
"Se a arquitetura de um sistema e a arquitetura de uma organização estão em desacordo ou fora de sintonia, provavelmente, a arquitetura da organização ganha". Ruth Malan
Distribuição da carga de trabalho no time de produto:
Aqui entramos no assunto sobre a carga cognitiva, que refere-se à quantidade de esforço mental exigida para realizar uma determinada tarefa. No contexto de um time de produto e tecnologia, a carga cognitiva está relacionada à complexidade das atividades desempenhadas pelos membros da equipe.
Os três principais problemas de uma estruturação de time de produto mal planejada ou uma carga cognitiva excessiva, são:
- Sobrecarga de informações;
- Dificuldade na tomada de decisões
- Diminuição da produtividade
Para distribuir adequadamente as responsabilidades, é importante considerar a experiência e as capacidades individuais dos membros da equipe, além de utilizar ferramentas e processos que ajudem a reduzir a carga cognitiva para que se obtenha produtividade.
Essa distribuição pode começar com alguns questionamentos, que você como:
- Será que uma pessoa mais especializada não cumpriria o desafio?
- Será que está buscando a pessoa errada por dificuldade nas decisões de tecnologia ou estratégia de produto?
- Ou será que é porque está mudando frequentemente o seu roadmap?
Como CPO é sua função não desperdiçar talentos e a melhor forma de fazer isso é mapear exatamente as habilidades necessárias para a contratação. Desta forma, você ganha tempo e terá um custo muito menor.
Falamos melhor sobre como aplicar a Lei de Conway e distribuir a carga de trabalho entre os membros do time de produto na Mentoria CPO do IFTL.
Confira quais são os temas abordados na Mentoria CPO do IFTL:
- Como gerir melhor suas atividades e prioridades;
- Como liderar equipes de alta performance;
- Estrutura e topologia de times de produto, design e engenharia;
- Responsabilidades, atribuições e hierarquias;
- Desenvolvimento de pessoas (PDI) e avaliação de performance;
- Gestão, cultura, rotinas e rituais de produto.
A seguir está o compilado com as dúvidas de CPO's que participaram de eventos do IFTL. Decidimos reuni-las aqui, pois esse exercício ajuda a ampliar sua compreensão como líder de produto, enriquecendo sua visão geral.
As dúvidas abordam problemas reais e desafios que outros profissionais do mercado estão enfrentando. Entender como essas questões podem ser resolvidas será útil para quando se deparar com barreiras semelhantes no futuro.
FAQ: 5 dúvidas reais que CPO's possuem sobre como estruturar times de produto
1. "É possível que o Product Manager assuma também o papel de UX Designer"?
Sim, em algumas situações, um Product Manager (PM) pode assumir também o papel de UX Designer, especialmente em empresas menores ou em estágios iniciais de startups. Essa combinação de responsabilidades pode ser interessante quando a pessoa possui habilidades e conhecimentos sólidos em ambas as áreas. No entanto, é importante ressaltar que esses são dois campos distintos, e é difícil dividir a atenção de forma adequada entre ambas as funções.
Com o crescimento do produto e aumento das demandas, é provável que a pessoa acabe se concentrando mais em uma das áreas, de acordo com suas afinidades e expertise. Em estágios mais avançados ou em empresas com recursos disponíveis, é recomendado ter profissionais dedicados para cada função, com alguém focado em experiência/ usabilidade (UX Designer) e outro alinhado à conexão do produto com os objetivos estratégicos da empresa (Product Manager).
2. "Os squads estruturais não viram gargalos para atender os de produto, devido à demanda ser muito grande"?
Os squads são equipes multifuncionais que trabalham de forma independente, o que, teoricamente, evita gargalos. No entanto, é possível que a demanda por certos produtos ou recursos específicos seja muito grande, resultando em sobrecarga para certos squads. Para evitar esse problema, é essencial analisar a capacidade de cada squad e ajustar o tamanho e a composição do time de produto de acordo com as necessidades do projeto.
Se um squad estiver sobrecarregado, a empresa e o CPO pode considerar a alocação de recursos adicionais para esse time ou a reorganização de algumas tarefas entre diferentes squads, garantindo que todos estejam operando em um nível ideal de capacidade.
3. "O time de Design Ops poderia ser formado pela transversal dos UX dos squads de produto"?
O time de Design Ops, responsável por aprimorar a eficiência operacional do design dentro de uma organização, pode sim ser formado por profissionais transversais dos squads de produto, incluindo membros de UX Design. Essa abordagem pode ser especialmente útil em empresas com muitas squads e equipes de UX, onde centralizar algumas funções pode melhorar a colaboração e a padronização do trabalho.
O Design Ops pode ajudar a estabelecer processos mais eficientes, fornecer recursos e ferramentas padronizadas, garantir a consistência das diretrizes de design e promover a colaboração entre as equipes de UX. Isso permitirá que o CPO e o time de produto se concentrem mais nas tarefas principais, melhorando a qualidade do trabalho e a experiência do usuário.
4. "Na empresa onde trabalho temos um aplicativo e um site. Atualmente, estamos estruturados por produto/canal. Sempre falamos sobre evoluir para um modelo de jornada, porém nos deparamos com produtos com maturidade tecnológica distinta. Qual a recomendação nesse caso? Qual critério usar para (re)estruturar nossa área?"
Quando a empresa possui diferentes produtos com maturidade tecnológica distinta, migrar para um modelo de jornada pode ser uma excelente abordagem. A jornada do usuário representa todo o percurso do cliente ao interagir com a empresa, independentemente do produto ou canal específico. Isso permite uma visão mais holística das interações do cliente e facilita a identificação de pontos de melhoria em toda a experiência.
Se você é CPO e precisa (re)estruturar a área, é recomendado seguir os seguintes passos:
- Análise da jornada do usuário: Mapeie a jornada do usuário para identificar os pontos de contato com a empresa, incluindo o App, o site e outros canais. Compreenda as necessidades e expectativas dos usuários em cada etapa.
- Agrupamento de produtos por etapa da jornada: Agrupe os produtos ou canais de acordo com as etapas da jornada do usuário em que eles se enquadram. Isso ajudará a entender quais produtos estão mais alinhados com determinadas partes da jornada.
- Avaliação da maturidade tecnológica: Avaliar a maturidade tecnológica de cada produto ou canal, ajuda a identificar possíveis lacunas. Determine quais áreas precisam ser modernizadas ou atualizadas para melhorar a experiência do usuário. Caso precise de suporte para entender as melhores práticas em desenvolvimento, sustentação, produtização e escalabilidade da sua tecnologia, o IFTL pode te ajudar. Conheça o In Company, um programa dedicado a aumentar a eficiência das áreas de Produto e Tecnologia em empresas.
- Priorização de investimentos: Com base na análise da jornada e da maturidade tecnológica, priorize os investimentos em produtos ou áreas que têm maior impacto na experiência do usuário e que podem ser atualizados de forma mais eficiente.
- Equipes multifuncionais: Organize times multifuncionais que atuem em diferentes etapas da jornada, reunindo especialistas de diferentes produtos ou canais para garantir uma abordagem integrada e centrada no usuário.
5. "Quando você falou sobre a distribuição dos times por produto ou jornada, fiquei curioso. Como distribuir esses times caso seja preciso refazer o software"?
Refazer o software pode ser um desafio, pois requer mudanças significativas e impacta várias partes do produto. Nesse caso, a abordagem ideal é evitar dependências rígidas entre os times. A seguir, listamos três estratégias que podem ser utilizadas:
- Modelo de Inner Source: Esse foi o modelo adotado pela Locaweb, quando o Joca Torres ocupava o cargo como Engenheiro de Software. Inner Source possui o mesmo conceito do Open Source, mas ao invés de ser aberto para developers do mundo todo, o código fica acessível apenas para os times internos da empresa. Isso permite que diferentes times contribuam com melhorias no software, mesmo que a equipe original esteja focada em outras prioridades.
- Construção via API: Essa solução ajuda a amenizar a interdependência entre os times, mas não 100%. É válida, quando é possível construir um novo software usando uma arquitetura baseada em API. Isso permite que todos trabalhem em partes separadas do software sem afetar o trabalho uns dos outros.
- Iteração incremental: Em vez de tentar refazer todo o software de uma só vez, é possível adotar uma abordagem iterativa, onde o produto é reconstruído em incrementos menores. Isso possibilita uma distribuição mais controlada do trabalho entre os times e permite que as melhorias sejam entregues gradualmente.
Referências:
Team Topologies
Lei de Conway
Estrutura de Time por Joca Torres
Mentor
Joca Torres
É advisor e consultor de gestão de produtos e transformação digital. Tem mais de 30 anos de experiência hands-on. Liderou a transformação digital da Lopes Consultoria de Imóveis como CDO (Chief Digital Officer). Antes disso, foi CPO (Chief Product Officer) do Gympass, Conta Azul e Locaweb. Iniciou sua carreira montando sua primeira startup em 1992, um BBS que se tornou um dos primeiros provedores de acesso à internet do Brasil. Autor de 3 livros sobre gestão de produtos digitais.
.svg){kind=icon}
.svg){kind=icon}
Mentor
Joca Torres
É advisor e consultor de gestão de produtos e transformação digital. Tem mais de 30 anos de experiência hands-on. Liderou a transformação digital da Lopes Consultoria de Imóveis como CDO (Chief Digital Officer). Antes disso, foi CPO (Chief Product Officer) do Gympass, Conta Azul e Locaweb. Iniciou sua carreira montando sua primeira startup em 1992, um BBS que se tornou um dos primeiros provedores de acesso à internet do Brasil. Autor de 3 livros sobre gestão de produtos digitais.
Ver perfil do autor
.png)
