Reestruturando a equipe de produtos Braze

A força motriz mais importante por trás de qualquer produto de software é o grupo de pessoas que o constrói – e seus relacionamentos entre si. Portanto, é importante organizar as equipes de uma maneira que permita que elas tenham o máximo de alavancagem e impacto possível.

Na Braze, pensamos muito sobre como nossa organização de produtos e engenharia é projetada e queremos compartilhar nossos aprendizados de uma grande reorganização departamental que nos ajudou a melhorar muito a forma como priorizamos recursos, desenvolvemos a experiência da equipe e criamos nosso produto com mais eficiência.

Estrutura inicial: Product/Market Fit e além

Encontrar o ajuste do produto/mercado – e aproveitá-lo para expandir um negócio – é um cadinho pelo qual todas as startups devem passar. Ao longo deste estágio no desenvolvimento de uma startup, a velocidade de experimentação e a capacidade de capitalizar rapidamente as oportunidades são críticas. Para isso, nossa estrutura de equipe de produto original ficou assim:

Essa estrutura, que dividiu nossa equipe por especialidades funcionais, funcionou bem por vários motivos.

Em primeiro lugar, permitiu-nos enfrentar com eficiência as mudanças transformacionais do produto no caminho para o ajuste do produto/mercado - os especialistas podiam possuir grandes partes de nossa base de código e usar as linguagens, estruturas e decisões de design com as quais se sentiam mais à vontade. Abastecidos por enormes quantidades de cafeína, as “equipes” do projeto do exército de um enfrentaram regularmente grandes empreendimentos. Isso incluiu a construção de nossa API pública voltada para o cliente e a revisão de toda a nossa infraestrutura de envio de mensagens, muitas vezes preenchendo o papel de engenheiro único, gerente de produto e designer. Esses tipos de medidas extremas seriam uma loucura em uma grande empresa, mas são necessárias e quase rotineiras durante o crescimento inicial.

Além disso, essa estrutura nos ajudou a obter um profundo domínio de certas áreas técnicas com apenas uma equipe de 10 a 15 pessoas. Muitos elementos de nossos principais produtos – por exemplo, a camada de controle de visualização de modelo do front-end, APIs e código de envio de mensagens de alto rendimento – foram totalmente compreendidos por apenas alguns indivíduos.

Na época, era simples e tudo o que precisávamos. Quando a velocidade é tudo, organizar com base em diretrizes simples ajudou a reduzir a sobrecarga cognitiva e nos permitiu focar a atenção onde ela poderia fazer mais bem.

Estrutura posterior: crescimento e dimensionamento

À medida que nossa equipe passou dos 30 ou 40, no entanto, essa estrutura começou a desmoronar. Por fim, identificamos a reorganização de nossa equipe de produtos como uma solução para alguns de nossos maiores desafios. Estávamos gastando um esforço insustentável fazendo malabarismos com conjuntos de habilidades e cronogramas para compor equipes para projetos estratégicos. Também gastamos uma quantidade excessiva de tempo na priorização e, muitas vezes, nos vimos forçando a classificação de todas as prioridades de produtos em toda a empresa, já que nossa estrutura de equipe baseada em tecnologia não mapeava diretamente as necessidades de produtos mais essenciais. E, finalmente, tivemos poucas oportunidades para os membros da equipe desenvolverem uma experiência profunda com casos de uso de clientes específicos.

Por fim, mudamos para uma organização estruturada em torno de equipes multifuncionais ágeis semelhantes ao modelo Squad/Tribe popularizado pelo Spotify. Nossa nova estrutura organizacional se parece com isso:

A maioria de nossa equipe trabalha em “verticais de produtos”, correspondentes a uma área-chave de nosso produto ou negócio. Por exemplo:

• Nossa equipe Email & Enterprise executa o Email de cima para baixo, bem como certas áreas de produtos, como gerenciamento de permissões, que são essenciais para muitos de nossos maiores clientes.
• Nossa equipe de mensagens e automação possui várias áreas de produtos relacionadas à segmentação de usuários, mensagens e nosso principal produto de orquestração, o Canvas.

Dentro de uma vertical, esperamos que a priorização seja (relativamente) direta, pois cada vertical corresponde a um conjunto específico de necessidades do cliente. Certas equipes, como Design Visual, DevOps e nossos grupos de Engenharia de Infraestrutura, abrangem toda a plataforma, criando consistência em áreas-chave.

Impactos

Nossa reorganização reduziu significativamente as dependências entre as equipes. Anteriormente, lutávamos com o problema de agendamento semelhante ao Sudoku de alocar o equilíbrio certo de conjuntos de habilidades especializadas (engenharia, design, gerenciamento de produtos etc.) em um determinado projeto em um determinado momento. Também alinhou incentivos de curto prazo – antes da transição, as equipes muitas vezes se viam confiando em contrapartes que visavam objetivos não relacionados. Com nossa nova estrutura, as equipes de produto são independentes, têm muito mais controle sobre os prazos e estão totalmente alinhadas aos objetivos, aumentando a produtividade e o moral.

O novo design da organização também melhorou a priorização. Por exemplo, nossa equipe de Email & Enterprise pode precisar decidir entre atualizar nossa infraestrutura de email, criar um recurso principal de email ou corrigir um problema de usabilidade corporativa - uma decisão direta e facilmente quantificável, pois todas as três se relacionam às necessidades de nossos clientes de maneiras semelhantes .

Uma equipe lutando com muitas necessidades de alta prioridade também é um indicador de que sua área de produto precisa de mais recursos. Isso nos permite reformular problemas difíceis de priorização como necessidades de pessoal, que ainda são desafiadoras, mas conceitualmente fáceis de resolver.

Por fim, concentrar a maioria das equipes em uma área de produto específica permitiu que os indivíduos construíssem conhecimentos profundos e relações de trabalho altamente produtivas ao longo do tempo. Inicialmente, nos primeiros anos de construção, os indivíduos podiam manter essencialmente todo o produto e a base de código em suas cabeças, mas à medida que crescemos isso se tornou impossível. Os problemas do produto são fractais: cada vez que você olha mais de perto, encontra mais nuances e profundidade. Como resultado, passar muitas horas em uma área específica de um produto ou base de código e entender profundamente suas necessidades de negócios é uma das melhores maneiras de alcançar avanços reais no produto. Além disso, a criação de equipes de longo prazo focadas cria propriedade e relacionamento e permite que relações de trabalho tácitas entre um conjunto consistente de colaboradores se consolidem.

Claro, nenhum sistema é perfeito. Com foco em pilares orientados ao produto, aumentamos o potencial para as equipes otimizarem para necessidades localizadas em detrimento de prioridades holísticas. Por exemplo, pode-se focar em dívidas tecnológicas localizadas (“esse controlador é complicado”) em vez de questões globais (“alterar nossa estrutura de front-end aumentaria a velocidade geral de engenharia”). Antecipando essa necessidade, tomamos medidas para estabelecer as equipes transversais mencionadas acima e usamos comitês dedicados para outros projetos amplos - por exemplo, um comitê para construir um sistema holístico de produto/design de componentes front-end e padrões de design .

Nossa nova estrutura também traz maior energia de ativação para mudanças holísticas e transformacionais do produto. Algumas áreas de nosso produto, como nossas APIs de back-end, são de propriedade conjunta de várias equipes. O limite para fazer mudanças radicais em áreas amplas e transversais de nossa base de código é maior, portanto, esse tipo de estrutura funciona melhor quando o esqueleto do seu produto é amplamente formado.

Aprendizado

No geral, ficamos satisfeitos com nossa estrutura organizacional de produto reprojetada: resolvemos ou melhoramos bastante nossos desafios em relação às dependências de equipe, priorização e criação de experiência em produtos de longo prazo, e também temos um roteiro útil sobre como escalaremos. Em particular, aprendemos que:

• A remoção de dependências e o alinhamento de incentivos levam a enormes ganhos de eficiência.
• A priorização de maçãs para maçãs é mais simples e mais eficaz.
• A profunda experiência em um determinado cliente ou necessidade de negócios leva a melhores resultados do produto.
• Trabalhar com os mesmos membros da equipe por um longo período é fundamental para construir ótimas relações de trabalho.

Eu recomendaria essa estrutura para qualquer equipe que compartilhasse certas características-chave: uma organização multifuncional na qual especialistas funcionais, como gerentes de produto, designers e engenheiros, sejam partes interessadas iguais; mais de 15 a 20 pessoas na equipe combinada de desenvolvimento de produtos; e, mais importante, o ajuste firme do produto ao mercado. E se esse tipo de estrutura de equipe lhe parece atraente, estamos contratando!