6 minutos de leitura

Uma conversa recorrente que tenho com founders ou líderes de produto em startups early stage é sobre qual a melhor estrutura para o time de produtos e squads. Com o passar dos anos e já tendo cometido minha parcela de erros e acertos nesse tópico, fica cada vez mais claro para mim que não existe uma receita de bolo ou bala de prata, mas que existem boas práticas e padrões que podem ajudar a resolver alguns impasses.

Se você tem curiosidade nesse tema ou busca resposta para perguntas como “quando é hora de ter um time dedicado?”, “como criar a primeira squad de produto?”, ou ainda “qual melhor forma de escalar o time de produto?”. Afinal de contas, é como sempre digo: aprender com os próprios erros é bom, mas aprender com o erro dos outros é melhor ainda – é mais rápido e mais barato!

Solução de prateleira

A maioria das pessoas geralmente só quer um analgésico pra sua dor atual, mas nesse caso o contexto é importante e aqui vamos nos aprofundar um pouco nele antes de mais nada e tentarei te mostrar que não existe uma solução de prateleira pra esse problema. Entendo também que você não quer me ver falando sobre primórdios das metodologias ágeis e onde tudo começou, mas é importante entender de onde veio a concepção atual da maioria das startups para as estruturas de times de produto que vamos por aí e garantir que estamos alinhados nos princípios fundamentais.

O famigerado modelo de squads se popularizou em um paper publicado em 2012, chamado Scaling Agile at Spotify, por Henrik Kniberg. No artigo de 14 páginas com várias fotos e esquemas, os autores nos explicam como o time do Spotify à época conseguiu dar escala para processo de desenvolvimento ágil e alocar um grande e crescente número de desenvolvedores de software em uma das startups mais populares do planeta.

Nesse artigo são explicadas muitas das nomenclaturas, estruturas e processos que hoje são velhos conhecidos como: Squads, Tribos e Chapters. Também são descritas ideias como times de até 8 pessoas, o papel do PO e como evitar interdependências entre esses times.

Tudo isso não deve ser novidade para você que nos lê, e é algo ensinado em qualquer bootcamp de formação de Product Managers dos dias de hoje como o modus operandi da indústria. Geralmente as dúvidas e questionamentos começam a surgir quando as companhias tentam trazer isso para o seu dia a dia e aqui entram algumas das principais dúvidas que já vi surgirem.

Quando é a hora de ter um time de produto dedicado?

Sei bem que no começo, todo founder deve vestir múltiplos chapéus, incluindo de PM, designer e desenvolvedor. Conforme a companhia ou business unit cresce, fica cada vez mais difícil de estar envolvido em todas as tomadas de decisão e áreas que envolvem o desenvolvimento de produto. Esse momento é crítico e por vezes assustador, mas é necessário para qualquer negócio crescer.

Alguns fatores para se levar em conta e saber se é hora de contratar seu primeiro PM ou time de produto são a complexidade do produto, o ritmo de desenvolvimento, o tamanho da sua base de clientes e o quanto de dinheiro você tem disponível.

Quando você não conseguir mais dar conta de estar envolvido na tomada de decisão ou precisar que seu produto ande mais rápido do que você pode dar conta, é um ótimo sinal de que você precisa de um time de produto dedicado. Você pode começar a construir esse time de pouco em pouco ao seu redor e ir diminuindo a necessidade da sua participação nele com o tempo. Para que isso funcione bem é crucial que você invista tempo e dedicação trazendo as pessoas certas para o seu time. Lembre-se, esse primeiro time provavelmente vai ser responsável por ditar como todos os demais times se comportarão depois dele.

Quantas pessoas alocar em cada time?

O folclore startupeiro vai te responder a velha máxima do “two pizza team” — os times devem ser pequenos o suficiente para serem alimentados por até duas pizzas. Esse é um ótimo exercício para se ter em mente e manter seus times pequenos. Os superpoderes de um time pequeno são tirar melhor proveito da agilidade, manter a comunicação fluindo sem interrupções, ter uma cadência de entregas mais constantes e se mover mais rápido em geral.

VEJA TAMBÉM: Estruturas Organizacionais para Times de Tecnologia

Aqui também não vamos ter uma resposta universal, vai depender muito do escopo de atuação do time, da cultura da sua companhia e do ritmo que você quiser impor. Agora, um aprendizado importante é que nem sempre “mais é mais” e mais gente no time pode até desacelerar a velocidade de desenvolvimento, por mais contraintuitivo que pareça.

Já diria Fred Brooks: “9 mulheres grávidas não fazem uma uma criança em um mês”, e em desenvolvimento de software isso se mostra mais verdade do que nunca. Mais pessoas implica em mais documentação, mais handover de trabalho, mais tempo discutindo arquitetura e soluções e, consequentemente menos software saindo do outro lado.

Claro que simplifiquei muito os motivos que justificam times pequenos fazerem coisas grandes enquanto alguns times grandes fazem coisas pequenas, e eu poderia ficar horas falando desse tema, mas vou deixar para me aprofundar nisso em outro momento — e existe muita literatura sobre esse assunto disponível caso tenha interesse. A questão é que você pode ter times tão pequenos quanto um dev e um product designer andando tão rápido quanto squads de 15 pessoas. Via de regra, se você prioriza velocidade e eficiência, times pequenos vão funcionar melhor que times grande.

Qual melhor forma de dividir os times?

A principal dúvida quando se começa a estruturar os times de produtos é como organizá-los e garantir que todos os desafios da empresa, metas, ambições, manutenção e construção de nova funcionalidades sejam cobertos por esses times.

Essa é um das questões que mais gera discussão e, não por acaso, onde já bati muito a cabeça e investi incontáveis horas como líder de produto tentando resolver. Já adianto que aqui também não tem uma resposta universal para cada empresa. Na verdade, toda empresa vai ter múltiplas resposta pra essa mesma pergunta ao longo do tempo.

A estrutura de times de produto é algo que evolui junto com o negócio. As necessidades de uma empresa começando com 5 pessoas são muito diferentes de uma empresa com 20 pessoas e completamente diferentes de uma empresa com 100 ou 500 pessoas no time de produto.

Além disso, a natureza do seu negócio e dos outros times vão influenciar muito como você deve organizar seus times de produto.

Uma das coisas mais importantes que aprendi sobre esse tema foi a Lei de Conway, que diz basicamente que a arquitetura de um sistema vai replicar a forma como o time que projetou esse sistema se organiza. No contexto de desenvolvimento de software isso é extremamente importante, uma vez que a forma como você organiza seus times vai impactar diretamente na arquitetura da sua aplicação. Dito isso, é crucial que a estrutura do seu time esteja alinhada ou reflita de alguma forma a arquitetura do seu produto.

Um dos melhores conteúdos sobre esse assunto foi produzido pelo Joca Torres e recomendo demais sua leitura para quem quiser se aprofundar no tema. Para os mais curiosos que quiserem ir ainda mais a fundo, recomendo o livro Team Topologies, um dos mais completos no assunto.

De maneira geral você pode organizar seus times de produto por Produto, por Usuário, por Jornada, por Objetivo ou de maneira híbrida.

• Produto – cuida de um produto ou feature específica (ex: no caso do Spotify, um time para a funcionalidade de busca, outro para reprodução e assim por diante)
• Usuário – olha para um tipo de usuário diferente (ex: em um marketplace como Uber motoristas e passageiros são tipos de usuários diferentes)
• Jornada – divide os times de acordo com a Jornada do usuário usando o produto (ex: no Airbnb poderia ser um time para encontrar o imóvel, outro para agendamento, outro para pagamento e outro para pós-venda, por exemplo)
• Objetivo – times separados de acordo com objetivos de negócio (ex: times com objetivo de Conversão, Retenção, ou geração de receita)

Além disso, você pode ter uma organização híbrida, quando mais de uma divisão dessas acontece dentro da sua organização ao mesmo tempo. Você pode dividir suas tribos por Jornada e dentro de uma dessas tribos as squad estarem divididas por Usuário, por exemplo.

Aqui cabe a você entender o momento da sua empresa e qual dessas divisões vai satisfazer melhor suas necessidades para que seu time realize seu melhor trabalho. O próprio Joca Torres elaborou essa tabela com os prós e contras de cada uma dessas divisões:

       Fonte: Estrutura de Times, por Joca Torres 

Conclusão

Um dos maiores aprendizados que pude tirar após anos estudando esse assunto é que não tem uma resposta universal. E se nem o Spotify usa mais o tal do Modelo Spotify, por que você deveria segui-lo cegamente? O próprio Henrik Kniberg já veio a publico algumas vezes dizer que o “modelo Spotify” não existe e seu artigo era simplesmente uma documentação de como as coisas eram feitas naquele momento. Inclusive, Marcin Floryan, um líder de engenharia do Spotify, fez uma palestra em 2016 explicando que o “modelo Spotify” não existia e que nem a própria empresa mais operava de acordo com o material poucos anos após sua publicação.

O mais importante é não perder de vista o motivo por tudo isso: construir software que gere valor para o seu cliente. Pode parecer óbvio, mas o óbvio precisa ser dito e estar encrustado na sua mente como líder de produto. É fácil se perder em tantos processos internos e complicações e perder de vista o óbvio e simples. No fim das contas não existe resposta certa ou errada, existem empresas que dão certo e que dão errado. Essas metodologias podem não garantir o seu sucesso, mas eu te garanto que a receita para o fracasso é deixar de olhar para os seus clientes.