O time de desenvolvimento de produto é quem vai executar a estratégia e atingir os objetivos para alcançar a visão de produto. Por isso, uma parte essencial da definição de estratégia é desenhar e implementar sua estrutura de time. Para isso, é importante entender as diferentes formas de se organizar um time de desenvolvimento de produtos e definir qual a mais apropriada para a sua estratégia.

Times de produto

O time mínimo de desenvolvimento de produto que vimos no capítulo sobre Carreira de gestão de produtos é 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 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. 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 O que é produto digital e gestão de produtos?. 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 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, como expliquei no capítulo sobre Carreira de gestão de produtos onde falo sobre liderança única e liderança compartilhada.

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

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

Exemplos de papéis que podem existir 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, podemos 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. 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 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 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. Minha recomendação é 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.

Organizando times de produto

Existem 4 formas possíveis de se organizar times de produto, por produto ou funcionalidade, por tipo de usuário, por jornada ou por objetivo. É possível também usar dois tipos diferentes de organização criando uma organização híbrida. Vou descrever a seguir cada uma:

Por produto ou funcionalidade

É uma das formas mais comuns de organização de times de produto. Para cada produto ou funcionalidade temos uma tribo. Na Locaweb tínhamos 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. Na Lopes, quando entrei, tínhamos um time focado no portal, outro no CRM utilizado pelos corretores e franquias e um terceiro focado no app para corretores.

A principal vantagem desse 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 tipo de usuário

Esse é um modelo muito útil em marketplaces e plataformas. Cada tribo tem o foco em um ator. Por exemplo, no Gympass, onde tínhamos academias, RH das empresas e funcionários das empresas, tínhamos 3 tribos, cada uma focada nesses 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 onde temos 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.

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. 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 de Cross Features, que cuidava do cadastro de cada um dos participantes do marketplace (usuários, academias e RHs) e de receber o pagamento feito por RHs e usuários, e por fazer o 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. Na Locaweb criamos o time de sistemas centrais, depois renomeado para enterprise applications, responsável pela central do cliente, onde 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.

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

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.

Híbrida

Essas diferentes formas de organizar times de produto podem ser usadas em conjunto, ou seja, 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. Veja a seguir alguns exemplos de organização híbrida.

Na Locaweb tínhamos times por produto (Hospedagem, Email Marketing, Cloud etc.) e um time focado na jornada do cliente (Central do Cliente)

Na Conta Azul usávamos 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).

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 pagamento para as academias. E 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.

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

É importante ressaltar que esses exemplos são da época em que trabalhei nessas empresas. Da mesma forma que 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 3 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 do Conta Azul, tínhamos um time focado em integração com os bancos para receber dados de extrato bancário dos clientes, um outro focado na interface de gestão financeira, com relatórios e sistema de categorização dos lançamentos do extrato e um terceiro focado em uma funcionalidade que tinha nome próprio, o Receba Fácil, sistema de emissão de boleto bancário.

Times estruturais

Times estruturais são os times que trabalham na estrutura necessária para os times de produto poderem fazer seu trabalho.

Alguns tipos de times estruturais necessários no desenvolvimento de produtos digitais:

• SRE ou DevOps: SRE significa Site Reliability Engineering. Essa área, às vezes chamada de DevOps, é responsável pela infraestrutura onde o produto será hospedado e servido aos clientes. Responsável também por monitorar o produto e a infraestrutura de hospedagem para garantir que ele opere com a performance ideal.
• Dados: aqui temos normalmente 3 disciplinas que precisam ser cuidadas pelo time de dados. Primeiro, é necessário um time de engenharia de dados que cuide da infraestrutura necessária para gestão dos dados da empresa. Em seguida, é necessário um time de análise de dados, responsável por gerar relatórios e dashboards com base nos dados e mostrando a performance do produto. Por fim, é interessante ter também um time de cientistas de dados capaz de tirar insights dos dados e eventualmente criar algoritmos de machine learning que possam evoluir à medida que mais dados são coletados e analisados.
• Arquitetura/Ferramentas/Fundação: time que ajuda os times de produto a definirem os padrões de arquitetura de software. Esse time também pode trabalhar em temas que são comuns a todos os times como, por exemplo, autenticação e autorização, e infraestrutura de APIs.
• Design Ops: time central de design que cuida de criar e manter o Design System, biblioteca de componentes e padrões de interação. Essa equipe também pode cuidar da eficiáncia operacional dos product designers, dando-lhes ferramentas, capacitando os gestores e líderes para avaliar o desempenho desses product designers e auxiliando no onboarding. Nesse time também podem ficar profissionais de user research e de UX writing.
• Segurança da Informação: responsável por todos os aspectos de segurança da informação, tais como LGPD, certificação PCI, certificação ISO 27001, políticas de BYOD (bring your own device) para permitir que os funcionários utilizem seus próprio devices para o trabalho.
• Sistemas Internos: responsável por cuidar dos sistemas de terceiros, tais como Google Suite, Office 365, Slack etc., bem como dos equipamentos da empresa.
• Engenharia de Vendas: essa área faz bastante sentido em empresas que desenvolvem produtos para outras empresas. É um time com conhecimento técnico capaz de discutir detalhes de implementação e integração do seu produto com os sistemas do cliente.
• Serviços Profissionais: caso as necessidades de implementação e de integração do novo cliente fujam do padrão, ou o cliente não esteja preparado para fazer essa implementação ou integração, pode ser interessante ter um time de serviços profissionais que faça esse trabalho. O recomendado é que esse time seja bem enxuto e utilize terceiros conforme a demanda para fazer o trabalho de implementação e integração.
• HRBP e contratação: como visto acima, times de produto e suas estruturas são complexos, com muito trabalho colaborativo e com estruturas matriciais. É essencial ter um time de RH por perto para ajudar na gestão do time, com dois focos. HRBP, ou Human Resources Business Partners ajuda no dia a dia dos times e líderes em todas as questões ligadas à RH. Contratação, no inglás talent acquisition é responsável por todo o processo de atração e contratação de pessoas para o time.

Implementação

A implementação da estrutura de produtos que foi desenhada pode acontecer de duas formas. Ou vocá está criando uma estrutura do zero, ou vocá está ajustando uma estrutura já existente.

Criando uma nova estrutura

Quando vocá cria uma estrutura do zero, vocá tem a oportunidade de crescer de acordo com as necessidades. Vocá pode começar com um único squad, depois criar o segundo e assim por diante. É importante vocá ter em mente aonde vocá deseja chegar com essa estrutura. Vocá terá times estruturais? Quais? Que times de produto vocá pretende ter?

Recomendo também começar a montar esses times pelos seus líderes, para que eles possam ter a oportunidade de contratar e formar os times conforme suas necessidades, desde que alinhados com a visão que vocá desenhou.

Mudando uma estrutura existente

Quando vocá chega para liderar um time já formado, é importante ter clareza da visão de produto, da estrutura atual e das pessoas que fazem parte desse time. Vocá precisará fazer várias conversas para entender bem esses trás aspectos antes de propor mudanças na estrutura atual. Assim que vocá desenhar uma primeira versão da sua proposta, apresente-a como trabalho em progresso para algumas pessoas para colher feedback e ir ajustando.

Uma vez acordada a nova estrutura, coordene com as pessoas dos times para fazer a mudança. Pode ser que alguns times que serão mexidos estejam terminando de fazer algumas coisas, então é importante alinhar com essas tarefas pendentes para permitir uma transição mais suave da estrutura atual para a nova.

Qual é a melhor proporção entre Eng, UX e PM?

Podemos encontrar muitos artigos de diferentes equipes de desenvolvimento de produto ao redor do mundo mostrando benchmarks de relações Eng:PM e UX:PM. Há um artigo recente de Ken Norton, parceiro do Google Ventures e ex-líder de gestão de produto do Google e do Yahoo!, onde ele compartilha os resultados de uma pesquisa informal que fez no Twitter:

“Uma maioria significativa dos tweets recomendou algo na faixa de 5 a 9 engenheiros para cada PM. Houve motivos pelos quais as pessoas recomendaram ter mais ou menos, mas entre 5 e 9 parece ser o ideal. Pensando em minha própria experiáncia, minhas equipes de melhor desempenho também se enquadraram nessa faixa.

Quando se trata de designers, prefiro uma proporção de 1:1 com PMs para equipes de produtos focadas no usuário. As equipes de produto funcionam melhor quando a tríade dedicada de PM, designer e líder de tecnologia forma o núcleo.“

Portanto, parece que a recomendação geral é de 5 a 9 engenheiros por PM e 1 UX por PM. Aqui, quando contabilizamos as pessoas de engenharia, devemos também considerar as pessoas dos times estruturais.

Alguns números da vida real

No Gympass, trabalhamos para aumentar o número de engenheiros por gestores de produto. Em nossos esforços para aumentar a equipe de 32 para 85 pessoas em 5 meses conseguimos aumentar a relação Eng:PM e também a relação UX:PM. Nosso plano era chegar ao final de 2019 com quase 200 pessoas em nossa equipe de desenvolvimento de produto, com ainda mais engenheiros por gerente de produto e um melhor equilíbrio entre designers de UX e gerentes de produto, como acabou acontecendo.

Todos os benchmarks são claros quando explicam que cada gestor de produto deve ser pareado com um UX, especialmente para produtos voltados para o cliente. No caso do Gympass, são 3 tipos diferentes de clientes (usuários finais, academias e clientes corporativos) o que reforça a necessidade de manter a proporção recomendada de 1 product designer por gerente de produto.

Na Conta Azul já tínhamos uma boa relação Eng:PM quando entrei em agosto de 2016. No entanto, a relação UX:PM estava abaixo dos padrões de mercado. Principalmente levando em consideração que um dos 4 valores fundamentais da Conta Azul é entregar o “Uau” aos clientes. Por esse motivo, trabalhamos para aumentar a proporção de designers de experiáncia do usuário em relação aos gestores de produto para aumentar o “Uau” entregue aos clientes.

Na Locaweb, muitos produtos que construímos eram para engenheiros de software. Hospedagem de sites, hospedagem de banco de dados, SMTP, Servidores cloud e servidores dedicados. Por isso, o número de engenheiros por gestores de produto é maior que o da Conta Azul e do Gympass. É ainda maior do que o limite superior recomendado de 9 engenheiros por gestor de produto. No entanto, podemos ver um fato interessante na proporção de designer de UX por gestor de produto. Como visto nos números de agosto de 2015, uma proporção maior de Eng:PM força um aumento em UX:PM em comparação à proporção de 1:1 recomendada. Quando olhamos os números de julho de 2016, temos mais engenheiros por gestores de produto, chegando a quase 12 Eng:PM, o que fez aumentar a proporção UX:PM para quase 2:1. Tivemos que colocar 2 designers de UX para cada gerente de produto para que eles pudessem lidar com todo o trabalho de discovery que precisava ser feito para que os engenheiros pudessem construir o produto certo. Considerando os engenheiros como responsáveis pelo delivery e UX e gestores de produto como discovery, isso nos mostra que tínhamos cerca de uma pessoa de discovery para cada 4 de delivery.

Lei de Conway

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.

Já vi situações em que um time de desenvolvimento de produto é organizado em paridade com as áreas de negócio, ou seja, 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, pois diminui o foco no cliente.

Os estágios de Tuckman de evolução de times

Bruce Tuckman, um pesquisador americano sobre dinâmica de grupos, propôs em 1965 quatro estágios pelos quais passa um grupo de pessoas que começam a trabalhar juntas, e como esses estágios impactam na eficácia desse grupo.

• Formando (forming): nesse estágio, as pessoas do grupo estão se conhecendo, entendendo os objetivos comuns e buscando formas de trabalharem juntas.
• Confrontando (storming): em seguida, acontecem alguns confrontos, quando o grupo começa a discutir sobre como o trabalho será feito e começa a conhecer as habilidades de cada pessoa no grupo.
• Normatizando (norming): esse é o momento em que os membros do grupo definem o processo de trabalho e os papéis e responsabilidades de cada membro do time. Nessa fase os membros do time já se conhecem melhor e respeitam as habilidades uns dos outros.
• Performando (performing): é nesse momento que o time de fato começa a produzir e a entregar resultados. O time já se conhece bem, o processo de trabalho é claro e acordado entre todos os membros do time.

Não há uma melhor forma de se estruturar um time de produto. Há aquela que faz mais sentido para a estratégia e objetivos definidos para atingir a visão de produto. Por isso, a estrutura de time não é escrita em pedra. Se houver necessidade, por mudança de objetivos ou de estratégia, pode fazer sentido mudar a estrutura do time. Contudo, não recomendo fazer isso com muita frequáncia, devido ao tempo necessário para um time recém-formado passar pelos estágios de Tuckman. Ouvi certas pessoas comentando que trabalham em empresas que mudavam a estrutura de time de desenvolvimento de produtos a cada 3 ou 6 meses. Não é tempo suficiente para passar pelos estágios de Tuckman.

Unidades de negócio

Em algumas situações, em vez de ter times de produto separados, mas dentro da mesma organização, pode ser interessante criar unidades de negócio razoavelmente independentes. Em unidades de negócio, temos não só um time de desenvolvimento produto separado, como todas as áreas necessárias para o negócio acontecer de forma independente tais como marketing, vendas, atendimento ao cliente etc.

Na Locaweb optamos pelo modelo de unidades de negócio independentes quando adquirimos empresas. A Tray era uma empresa de soluções de ecommerce que passaram a fazer parte do portfólio de produtos da Locaweb. Como a Tray já operava como uma empresa independente, optamos por mantá-la dessa forma, somente tendo as áreas de administração, financeiro e RH em comum. Essa é uma maneira bem comum de criar áreas de negócio, por meio de aquisições de empresas.

No Gympass vislumbramos a oportunidade de criar um novo produto chamado Gympass Wellness, que oferece serviços de bem-estar tais como aplicativos de atividade física, de nutrição e de meditação para os funcionários dos clientes do Gympass. Optamos por iniciar esse novo produto como uma unidade de negócios, com time de produto, de marketing e de vendas independente do Gympass, visando dar maior autonomia e agilidade para esse time.

Na Lopes temos a CrediPronto, unidade de negócios que é uma joint-venture entre Lopes e Itaú para oferecer crédito para compradores de imóveis. Pelo fato de a natureza do negócio ser completamente diferente do negócio principal de transação imobiliária e ainda por ter um novo sócio, optou-se pelo modelo de unidade de negócio.

O que faz um grupo de pessoas se comportar como um time?

Não é suficiente organizar as pessoas na estrutura de equipes descrita aqui para que se comportem como uma equipe. Para que se percebam como uma equipe e passem a atuar como tal, precisam de objetivos comuns.

Um problema muito comum que vejo nas equipes de desenvolvimento de produto é que, mesmo sendo muito bem organizados em tribos e esquadrões, com tribos estruturais e tribos de produtos, e as pessoas certas com as funções certas em cada equipe, os objetivos são definidos por função. Os gerentes de produto tám um conjunto de objetivos diferente dos de designers de produto, que são diferentes dos objetivos dos engenheiros. Isso simplesmente não funciona, porque cada pessoa se concentrará nos seus próprios objetivos.

Se definirmos todos os objetivos como sendo comuns a todos os membros da equipe, todos eles trabalharão juntos para atingi-los. Mesmo que o objetivo pareça mais relacionado a um dos aspectos, como mais relacionado ao negócio (gerente de produto) ou à experiáncia do usuário, ou mais relacionado à engenharia, todos os membros da equipe devem ter os mesmos objetivos.

Então, a resposta curta para a pergunta “O que faz um grupo de pessoas se comportar como uma equipe?” são objetivos comuns.

Resumindo

• Times de desenvolvimento de produto são organizados em times mínimos, também chamados de squads, compostos de engenheiros, product designers e product managers. É importante deixar esses times o mais enxuto possível para ajudar em sua produtividade. Esses times mínimos são agrupados em times de produto chamados de tribos de produto.
• Há 4 formas de se organizar os times de produto: por produto ou funcionalidade, por tipo de usuário, por jornada ou por objetivo. É possível também usar dois tipos diferentes de organização, criando uma organização híbrida.
• Existem também as tribos estruturais, que criam a estrutura necessária para as tribos de produto performarem. Times que compõem as tribos estruturais são SRE/DevOps, Dados, Arquitetura/ Ferramentas/ Fundação, Design Ops, Segurança da Informação, Sistemas Internos, Engenharia de Vendas e Serviços Profissionais.
• A implementação da organização de time desenhada pode ser feita ou criando uma nova estrutura ou ajustando um time já existente. Em ambas as situações é importante conhecer bem a visão e a estratégia de produto para desenhar e implementar uma estrutura de time alinhada com ela.
• A proporção mais indicada entre pessoas em engenharia e gestores de produto é de 7 +/- 2 engenheiros para cada gestor de produto. E de um product designer para cada gestor de produto.
• Dois conceitos importantes no desenho de sua estrutura de time são o da Lei de Conway, que diz que as organizações tendem a criar sistemas que são uma cópia da estrutura de comunicação das empresas, e os 4 estágios de Tuckman de formação de times, formando, confrontando, normatizando e performando.
• É possível também organizar times de produto por unidades de negócio que tenham outras funções além das compreendidas em um time de desenvolvimento de produto, tais como marketing, vendas e atendimento ao cliente. As motivações para criar unidades de negócio em vez de times de produto podem ser devido à aquisição, ou para dar mais agilidade ao novo negócio ou mesmo por se tratar de uma nova linha de produto completamente diferente do produto original.
• O que faz um grupo de pessoas se comportar como um time são os objetivos comuns.

No próximo capítulo vamos ver um pouco mais sobre desenvolver o time e gerenciar expectativas.

Liderança de produtos digitais

Estou publicando os 30 capítulos do meu mais novo livro, Liderança de produtos digitais: A ciáncia e a arte da gestão de times de produto, um por semana. Caso vocá queira ler o livro completo, pode adquiri-lo diretamente da editora. Vocá também pode se interessar pelos meus outros dois livros:

• 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