Esse artigo faz parte do meu último livro sobre “Transformação Digital e Cultura de Produto“, e é mais um trecho do capítulo sobre estrutura de time onde vamos ver como organizar os times de produto.

Times de produto

O time mínimo de desenvolvimento de produto que vimos é composto um product manager, um product designer e dois ou mais engenheiros. Esse time mínimo pode também ser chamado de squad e deve ter no máximo umas sete pessoas. Quanto maior o time, maior a dificuldade de coordenação. Na Amazon, existe a famosa regra dos times de duas pizzas, o que significa que o tamanho máximo do time é aquele que consegue ser alimentado por duas pizzas grandes.

O racional por trás da vantagem de rodar com times pequenos é baseado no mesmo conceito que apresentei quando falei de plataformas no capítulo Modelos de negócio. A quantidade de interações entre os membros do time cresce 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 time 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.

Times de produto

Essa tribo de produto pode ter um, dois ou três líderes. Se for uma 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.

Já tive oportunidade de trabalhar em estruturas com um, dois e três líderes em cada tribo de produto, e cada uma dessas estruturas traz seus pontos positivos e negativos. Por pontos positivos da liderança compartilhada, ela evita sobrecarga e permite maior especialização da liderança. Por outro lado, pode ajudar a formar silos, e vai requerer maior esforço de coordenação. Já a liderança única tem por vantagens o fato de desfavorecer a formação de silos, já que é uma pessoa só liderando. Contudo, como desvantagem, há uma sobrecarga na líder, que terá que conhecer mais assuntos além dos que forem sua natureza.

Times de produto também podem ter alguns papéis compartilhados entre os squads. Tê-los compartilhados em vez de dedicados por squad tem três principais objetivos:

1. 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;
2. 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;
3. 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, podemos alocar os recursos disponíveis para desenvolvimento de produto em mais squads que constroem produto.

Exemplos de papéis que podem ser compartilhados entre squads de uma tribo de produto:

• 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 é de responsabilidade de cada membro do squad.
• Quality Assistance: assim como processos e cultura ágil são responsabilidades de cada membro do squad, o mesmo acontece com qualidade. Em vez de um quality assurance por squad, podemos ter um quality assistance por tribo de produto, que vai ajudar os squads 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. Na Conta Azul, como tínhamos integração com bancos e com os sistemas das Secretarias da Fazenda de cada estado para emissão de nota fiscal, fez sentido termos uma pessoa com esse conhecimento em cada tribo.
• User Research: essa é a responsabilidade de product designers, com apoio de 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 gestora de produtos é construir o produto ou funcionalidade que resolve problemas dos usuários, o Product Marketing tem por missão contar ao mundo externo e interno sobre o produto ou funcionalidade e o problema que ele resolve. Esse “mundo externo” refere-se tanto aos usuários do produto quanto aos novos usuários que queremos trazer. Já o “mundo interno” são todas as pessoas da empresa, incluindo as pessoas de suporte e de vendas. É 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 alguns casos, mas pode rapidamente se tornar uma sobrecarga e, consequentemente, prejudicar a performance do produto.

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. Minha recomendação é ter no máximo três 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.

Organizando times de produto

A Lei de Conway foi criada por Melvin Conway, cientista da computação americano, e publicada pela primeira vez em abril de 1968, em uma revista de Tecnologia da Informação bastante conhecida na época chamada Datamation. A Lei de Conway diz que:

LEI DE CONWAY

Qualquer organização que desenvolve um sistema produzirá um sistema cuja estrutura é uma cópia da estrutura de comunicação da organização.

Por esse motivo, a organização dos times de produto tem um impacto muito grande nas chances de sucesso do seu produto.

Existem quatro formas possíveis de se organizar times de produto:

1. Por produto ou funcionalidade;
2. Por tipo de usuário;
3. Por jornada;
4. Por objetivo.

Vamos agora conhecer com mais detalhes cada uma dessas formas.

1. Por produto ou funcionalidade

Essa é uma das formas mais comuns de organização de times de produto. Para cada produto ou funcionalidade, temos uma tribo. Na Locaweb tínhamos um time de produto para cada produto: Email Marketing, PABX virtual, Cloud, Hospedagem de Sites e assim por diante. Na Conta Azul também usávamos esse modelo, com um time, o Spartans, focado em funcionalidades relacionadas à gestão financeira, e o outro time, o Underground, focado em funcionalidades fiscais e contábeis. Quando entrei na Lopes, tínhamos um time focado no portal, outro no CRM utilizado pelos corretores e franquias e um terceiro focado no app para corretores. Em um banco, é comum ter times organizados por produtos financeiros, tais como conta corrente, investimento, crédito etc.

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 ou na funcionalidade, perde-se um pouco de perspectiva a(s) pessoa(s) cujos problemas esse produto resolve.

2. Por tipo de usuário

Esse é um modelo muito útil em marketplaces e plataformas. Cada tribo tem foco em um ator. Por exemplo, o Gympass interage com academias, RH das empresas e funcionários das empresas, por isso decidimos ter três tribos, cada uma focada em um desses três atores do marketplace. Na Conta Azul, tínhamos duas tribos focadas no dono do pequeno negócio e duas focadas no contador. Na Lopes, desenhamos uma estrutura na qual tínhamos uma tribo focada no comprador de imóvel, outra no vendedor e uma terceira focada no corretor, que faz a intermediação.

A vantagem desse modelo de organização é que o foco de cada time é bem definido, visando melhorar a experiência e resolver o problema de cada ator da plataforma. Caso a arquitetura de sistemas seja muito acoplada, pode haver bastante dependência entre os times.

Outro ponto de atenção é que algumas jornadas podem ficar divididas entre duas tribos. Por exemplo, no Gympass existe a jornada de fazer check-in em uma academia, que acontece quando o usuário vai até a academia, faz o check-in e a recepção o valida. Em uma organização de time por tipo de usuário, tanto o time de academias quanto o de usuário são responsáveis por essa jornada e devem se coordenar para fazer mudanças nessa parte do produto.

3. 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 exemplos de jornadas pelas quais seu usuário pode passar ao usar o seu produto. Confesso que nunca vi um time 100% organizado por jornada, mas já vi times organizados por produto ou por tipo de usuário terem uma ou mais tribos focadas em alguma jornada.

Por exemplo, na Conta Azul tínhamos um time chamado 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. No Gympass, além dos times de usuário, academia e RH da empresa, tínhamos um time chamado Cross Features, que cuidava do cadastro de cada um dos participantes do marketplace (usuários, academias e RHs) e, também, de receber o pagamento feito por RHs e usuários e fazer os cálculos de pagamento para as academias. Na Lopes, decidimos criar, além dos times para comprador, vendedor e corretor, um time chamado Leads, que cuida das interações entre comprador e corretor. Posteriormente esse time se juntou ao time de corretor, e criamos um time chamado de Sistemas Centrais, responsável pela geração e gestão de contratos de compra e venda de imóveis. Na Locaweb, também tínhamos o time de sistemas centrais, depois renomeado para enterprise applications, responsável pela central do cliente, na qual o cliente da Locaweb pode ver e administrar todos os produtos contratados.

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.

4. 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. Não conheço nenhum time 100% estruturado somente por objetivos. No Gympass, usávamos esse modo de organização no time de usuário quando o dividimos em duas tribos: uma focada em crescimento, que tinha por objetivo garantir que os funcionários dos clientes baixassem o app, criassem a conta gratuita e se tornassem assinantes; e a outra focada em experiência digital, para garantir que os usuários utilizassem e tirassem o maior proveito possível do app, garantindo a satisfação e a retenção deles.

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 muita dependência entre as equipes.

Já vi situações em que um time de desenvolvimento de produto é organizado em paridade com as áreas de negócio, com um time focado nas necessidades do atendimento ao cliente, outro focado no time de vendas, outro focado no financeiro, mais um focado no marketing, e assim por diante. Não recomendo esse tipo de estrutura, porque ela diminui o foco no cliente e deixa os times de produto subservientes aos outros times da empresa — e no capítulo Foco no problema, vimos que essa não é a forma de trabalho que extrai mais valor, inovação e resultado do time de desenvolvimento de produto.

Olhando essas diferentes formas de organizar um time de produto e seus prós e contras, fica a dúvida: qual é a melhor forma? A resposta é: a híbrida.

Essas diferentes formas de organizar times de produto podem ser usadas em conjunto, não são exclusivas. Na verdade, nunca vi uma equipe de desenvolvimento de produto usando exclusivamente um tipo de organização. As equipes são estruturadas em organizações híbridas. Na Locaweb, por exemplo, tínhamos times por produto (Hospedagem, Email Marketing, Cloud etc.) e um time focado na jornada do cliente (Central do Cliente):

Times de produto da Locaweb em 2016

Na Conta Azul, usávamos a organização por funcionalidade. Um time para gestão financeira do pequeno negócio (Spartans) e outro para gestão fiscal e contábil (Underground). Um para gestão fiscal, contábil e de folha dos clientes do contador (Area 42) e outro para gestão de clientes do contador (Babilônia). Também organizávamos por tipo de usuário (times focados no dono do negócio e no contador) e por jornada (Hubble).

Times de produto da Conta Azul em 2018

No Gympass, definimos os times por tipo de usuário (usuário final, academia e RH), mas também usamos a organização por jornada para criar o time de Cross Features, responsável pelo cadastro de cada um dos participantes do marketplace (usuários, academias e RHs), por receber o pagamento feito por RHs e usuários e por fazer o cálculo do pagamento para as academias. Usamos também a organização por objetivos, quando quebramos o time de usuário final em duas tribos, uma de crescimento e outra de experiência digital.

Times de produto do Gympass em 2019

Na Lopes também definimos os times por tipo de usuário (cliente final, incorporador & proprietário, corretor & franqueado) e definimos uma tribo focada na jornada entre cliente e corretor, que chamamos de Leads.

Times de produto da Lopes em 2020

É importante ressaltar que esses exemplos são da época em que trabalhei nessas empresas. Assim como a visão e estratégia de produto evoluem, a estrutura de times também deve evoluir.

Organizando squads em um time de produto

Essas formas de organização de times de produto servem tanto para definir a organização entre tribos, bem como a organização dos squads de uma tribo. Alguns exemplos:

• Hospedagem de sites (Locaweb): dentro do time de hospedagem de sites da Locaweb tínhamos três squads, um focado em hospedagem Windows, outro em hospedagem Linux e um terceiro com foco no painel de controle de gestão da hospedagem.
• Academias (Gympass): no time focado em academias do Gympass, tínhamos um squad focado em APIs para integração com sistemas de gestão para integração de processo de check-in dos usuários e de reserva de aulas e outro squad focado na experiência do gestor da academia, para que ele pudesse ter acesso a relatórios e configurar como sua academia apareceria no app do usuário.
• Financeiro (Conta Azul): no time focado em gestão financeira da Conta Azul, tínhamos um squad focado em integração com os bancos para receber dados de extrato bancário dos clientes, outro focado na interface de gestão financeira, com relatórios e sistema de categorização dos lançamentos do extrato, e um terceiro time focado em uma funcionalidade que tinha nome próprio, o Receba Fácil, sistema de emissão de boleto bancário.

Como definir a estrutura do time de produto?

O insumo que precisamos para definir a estrutura de produto é o que vimos nos dois capítulos anteriores: a visão de produto e a estratégia. Essas duas informações são o que nos ajuda a definir qual a melhor estrutura de time de produto que devemos ter para nos ajudar a atingir nossos objetivos.

A Locaweb oferece produtos digitais (Hospedagem, Email, Loja Virtual etc.), então a estrutura que mais faz sentido é uma estrutura de times organizada por produto. Na Conta Azul, temos os produtos financeiros e contábeis, e temos também dois atores, a pequena empresa e o contador. Esses foram os elementos que orientaram a definição da organização de times. Já no Gympass e na Lopes, o foco foi olhar para os atores do marketplace: academias, RHs e funcionários, no caso do Gympass; quando olhamos a Lopes, temos a pessoa compradora de imóvel, a pessoa que está vendendo o imóvel, que pode ser a incorporadora do imóvel na planta ou o proprietário do imóvel pronto, e a pessoa que está fazendo a intermediação, que é o corretor e a franquia à qual ele pertence.

Quando eu me juntei à Lopes, em meados de 2020, os times estavam organizados por produto. Havia um time de Portal, que fazia o portal onde se busca por imóveis, um time de CRM e outro para o app do corretor. No capítulo sobre Foco no problema, contei sobre o app do corretor: um “MVP” que estava em desenvolvimento há um ano e ainda não tinha sido lançado. A organização de times tem impacto direto na forma como as pessoas dos times resolverão problemas. Quando temos um time de app do corretor, a única forma que esse time sabe para resolver problemas é implementando funcionalidades nesse app. Quando mudamos para times por atores do marketplace, o time de Corretor ganhou a liberdade de buscar diferentes soluções para entregar valor para o corretor. Poderia ser o app, mas poderia ser uma notificação SMS, um chatbot, uma mudança em processo ou qualquer outra solução criativa. A mudança na forma como o time se organiza pode habilitar o time a ser mais eficiente nas soluções desenvolvidas e, consequentemente, nos resultados alcançados.

No próximo artigo vamos conhecer outro tipo de time, conhecidos como times estruturais, também conhecidos como times de plataforma, que são os times que trabalham na estrutura necessária para os times de produto poderem fazer seu trabalho.

Transformação digital e cultura de produto

Esse artigo é mais um trecho do meu mais novo livro “Transformação digital e cultura de produto: Como colocar a tecnologia no centro da estratégia da sua empresa“, que vou também disponibilizar aqui no blog. Até o momento, já publiquei aqui:

• Sobre o livro
• Parte 1: Conceitos
  • Capítulo 1: A tal da transformação digital – Projeto e Produto
  • Capítulo 2: Incerteza e transformação digital
  • Capítulo 3: Tipo de empresa
  • Capítulo 4: Tipo de empresa x maturidade digital
  • Capítulo 5: Modelos de negócio
  • Capítulo 6: Cultura ágil, digital e de produto
• Parte 2: Princípios
  • Capítulo 7: Entregas rápidas e frequentes – Medindo e gerenciando a produtividade – Estudo de caso: Grupo Dasa – Estudo de caso: Itaú Unibanco
  • Capítulo 8: Foco no problema – O Famoso Discovery de Produto – Por que o modelo “negócios demanda → tecnologia implementa” não funciona? – Estudo de Caso: Magazine Luiza
  • Capítulo 9: Entrega de resultado – Time Terceirizado ou Time Interno? – Estudo de Caso: Centauro
  • Capítulo 10: Mentalidade de ecossistema
• Parte 3: Ferramentas
  • Capítulo 11: Visão de Produto – Exemplos de visão de produto
  • Capítulo 12: Estratégia de Produto
  • Capítulo 13: Estrutura de time – Como estruturar times de desenvolvimento de produto mais eficazes

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.