Escalando o time de Gestão de Produtos na Resultados Digitais

Publicado por Alexandre Spengler no dia gestão, produto

Foguete

Uma das coisas mais impressionantes da Resultados Digitais é o seu crescimento extremamente acelerado. É quase impossível entrar em uma conversa sobre a RD com alguém de fora da empresa e o assunto “o crescimento da RD é impressionante” não surgir de alguma forma. E, se pra quem está de fora isso já impressiona, imagina pra quem está vivendo essas mudanças! É realmente uma experiência incrível!

Quando entrei na RD, no início de 2015, éramos pouco mais de 100 pessoas na empresa toda, tínhamos cerca de 1200 clientes e, até então, apenas 1 Product Manager, o mito Diego Pereira que já escreveu alguns posts por aqui. Hoje (e enquanto você lê este post esta informação com certeza já está desatualizada) somos quase 100 pessoas só na área de Produto, temos 12 PMs no time e mais de 7000 clientes! Pensando nesse cenário resolvi escrever uma série de posts para compartilhar como escalamos o time de Product Managers na Resultados Digitais. Para começar, vou contar um pouco de como nós evoluímos a nossa estrutura dos times de Produto de 2015 para cá.

A estrutura

No início de 2015 nosso time de produto tinha cerca de 30 pessoas, divididas em 4 times do RD Station e um time de Sistemas Internos. Naquela época os Product Managers (que na verdade se chamavam Product Owners) ficavam “separados” dos times. Nós mantínhamos o que chamávamos de “Kanban de Produto”, que basicamente continha todos os Épicos que estavam rodando nos times e os famosos Quick Wins (pequenas melhorias no produto normalmente sugeridas por RDoers ou clientes). O objetivo desse Kanban era basicamente nos ajudar a organizar e priorizar as próximas funcionalidades do RD Station, e com isso montar o backlog de cada time.

Com 4 times para manter e evoluir o RD Station, sendo um deles focado em Operação, essa estrutura, sem um PM/PO exclusivo por time, funcionava razoavelmente bem. A comunicação e o alinhamento entre a área como um todo era fluida, principalmente porque estávamos todos distribuídos em 4 ou 5 mesas. Nosso papel na época, como PM/PO, era basicamente estudar os principais problemas do RD Station, priorizar esses problemas junto aos times e lançar as novas funcionalidades para nossa base de clientes.

Outro grande benefício do time enxuto que tínhamos na época era que o alinhamento da área de Produto com o restante da empresa acontecia de forma facilitada, visto que ainda estávamos todos em uma única sala. Para conversar com os times de CS, Suporte, Vendas, Marketing e etc bastava, basicamente, virar a cadeira ou no máximo dar uma dúzia de passos. Isso facilitava bastante o nosso trabalho para comunicar internamente alterações no produto, ouvir feedbacks e etc.

O processo de escala

No início do segundo semestre de 2015 esse cenário positivo já começava a dar fortes sinais de que ia se alterar. Com o crescimento dos times existentes e a criação de novos times, ficou cada vez mais claro que ter PMs/POs “satélites” não iria funcionar. Nós estávamos com cada vez mais demanda e cada vez menos tínhamos visão do que iríamos fazer no mês seguinte, muito menos em 3 ou 6 meses. Um reflexo claro disso era o aumento do número de Quick Wins que eram executados pelos times, o que era um reflexo direto da falta de Épicos que os times tinham para executar, que por sua vez era causado por nós não termos tempo suficiente para estudar mais do que um ou dois problemas complexos ao mesmo tempo.

Foi justamente nessa época que começamos a contratar novos PMs/POs para os times (assunto que vou tratar em mais detalhes em um próximo post) e começava a ficar mais claro como iríamos escalar o time de produto da li em diante. Em Agosto de 2015 tivemos um grande problema com o Email Marketing do RD Station e, para resolver esse problema, nós resolvemos testar uma nova estrutura. Em Setembro do mesmo ano criamos o primeiro time especialista da Resultados Digitais, ainda como um MVP. Fechamos o ano de 2015 com 6 times evoluindo o RD Station e em Janeiro de 2016 aplicamos o modelo de time especialista para todos os times da área.

Times especialistas

Um time (ou Squad) especialista funciona como uma mini Startup. Ele é composto de um PM (nesse momento é que passamos a chamar os Product Owners de Product Managers), um Tech Leader (antigamente eram Scrum Masters), um Designer (UX), um QA e de dois a quatro Engenheiros de Software (SE). Mas a grande diferença desse time, além de ter um PM dedicado, é o nível de conhecimento e autonomia que esse time tem sobre determinada temática. Todas as decisões, de Roadmap a como gerenciar o Suporte, eram tomadas pelo próprio time. Isso trouxe uma profundidade enorme para o time sobre os problemas que precisavam ser resolvidos e possibilitou que nós, Product Managers, pudéssemos mergulhar em um assunto específico, como Email Marketing ou Landing Pages.

Estrutura de uma tribo

A criação dos times especialistas foi a base para que nós pudéssemos evoluir e escalar uma série de práticas de produto e para que nós pudéssemos escalar com sucesso o time de Product Managers na RD. Essa estrutura foi inspirada pelo modelo do Spotify e está, cada vez mais, fazendo bastante sentido pra gente. Investimos praticamente todo o ano de 2016 para lapidar essa estrutura e chegamos ao final do ano com 12 times na área de Produto e 12 PMs no time. Foi também durante o ano de 2016 que criamos os primeiros Chapters na RD, que são basicamente estruturas transversais aos times para evoluir cada job em específico. Tínhamos, em 2016, os Chapters de QAs, PMs e Designers.

Tribos

Mesmo com todas essas evoluções e benefícios que a estrutura de times especialistas trouxe, nós começamos a sentir algumas dores relacionadas ao crescimento do número de times e pessoas. O principal motivo foi quando ainda no primeiro trimestre de 2016, nós precisamos criar um segundo time especialista em uma mesma temática. É claro que é importantíssimo existir um alinhamento entre os times do RD Station como um todo, mas o alinhamento entre dois ou mais times que trabalham em uma mesma temática precisa ser ainda maior. Esses times vão, inevitavelmente, ter que compartilhar problemas, soluções, roadmaps, tickets de suporte e até pessoas em algum momento. Pensando nisso, novamente a critério de MVP, nós criamos a primeira Tribo do RD Station. E, em Janeiro de 2017, nós novamente reformulamos a estrutura do nosso time de Produto para organizar todos os times em Tribos.

Uma Tribo é, basicamente, uma estrutura que agrupa times de uma mesma temática. Temos hoje 5 Tribos, responsáveis pelas temáticas de Relacionamento, Geração de Leads, Jornada do Cliente, Plataforma e Sistemas Internos. Hoje, cada Tribo é liderada por uma dupla responsável por Produto e Engenharia, algo como um Tech Leader de Tribo e um Product Manager de Tribo. De forma simplificada, o objetivo dessa estrutura é garantir autonomia para Tribo em todos os sentidos, de metodologias, processos e cerimônias a budget e contratações. Além disso, esse PM líder de Tribo é o grande responsável por manter todos os Roadmaps dos times da Tribo alinhados e coerentes com a visão da Tribo e da RD em si. Essa estrutura nos permite escalar os times de Produto da RD de forma ágil, mantendo uma gestão próxima e sem criar novos níveis hierárquicos ou novos processos desnecessariamente.

Estrutura de uma tribo

O dia depois de amanhã

Hoje, em Abril de 2017, é neste formato de Times Especialistas e Tribos que os 13 times de produto da Resultados Digitais funcionam e estão distribuídos. Tenho certeza absoluta que essa estrutura vai ter algum tipo de alteração até o meio do ano e que no início de 2018, com quase 160 RDoers no time de Produto, vamos estar enfrentando novos desafios e tendo que resolver novos problemas. E essa é uma das coisas mais bacanas de se estar na RD, você não precisa mudar de empresa para enfrentar novos desafios, a empresa está mudando a todo momento e os desafios são cada vez maiores!

Se você tiver interesse em conhecer mais dessa história e saber em mais detalhes como escalamos o time de Gestão de Produtos aqui na RD, fique atento aos novos posts dessa série. Caso você tenha dúvidas com relação a este post ou sugestões do que você gostaria de ouvir nos próximos, não hesite em entrar contato comigo através dos comentários. E, se mais do que conhecer a nossa história você gostaria de fazer parte dela, temos várias vagas abertas para o nosso time produto, é só conferir no nosso mural de vagas!

Alexandre Spengler

Alexandre Spengler

Product Manager

Comentários