Como o Notion criou um sistema de gerenciamento de produtos para alinhar cada equipe

Quando centenas de pedidos de suporte lotaram nossas caixas de entrada em uma noite, ficou claro que havíamos chegado a um limite. Nossa Engenharia havia lançado um novo recurso sem que o Suporte soubesse, e fizemos um esforço durante a noite toda para responder às perguntas dos clientes.

Mas não foi só isso. Nas semanas anteriores, a equipe de Marketing de Produto pediu a vários engenheiros que preenchessem as notas de lançamento semanalmente. Diferentes equipes estavam realizando suas próprias reuniões de status para acompanhar o mesmo lançamento. Coletivamente, estávamos perdendo muito tempo tentando nos comunicar.

O Notion estava crescendo – tínhamos cinco equipes de engenharia e vários projetos estavam avançando em paralelo. Mas poucas pessoas entendiam tudo o que estava sendo lançado, ou por quê. Se não encontrássemos uma maneira melhor de coordenar as equipes, ficaria impossível de escalar o nosso negócio.

Toda startup tem essas dificuldades iniciais. Vi essa mesma situação acontecer nas equipes de produtos do Twitter, Oculus, Robinhood e agora no Notion (pois é, não estamos imunes!). Então, pensei em contar como criamos uma solução para a nossa própria equipe.

Aqui, vamos mostrar os sistemas e processos que colocamos em prática para manter cada equipe atualizada sobre nosso trabalho de engenharia e de produto. Também incluímos alguns modelos – para que você aplique na hora as melhores partes à sua própria equipe.

Quando entrei para o Notion, uma das primeiras coisas que fiz foi falar com engenheiros e designers sobre como eles normalmente criavam e lançavam os produtos. Algumas equipes usavam sistemas formais de tarefas e sprints, enquanto outras atualizavam um único e enorme documento colaborativo.

Eu já havia visto isto antes: à medida que as empresas crescem, cada equipe desenvolve hábitos diferentes, o que dificulta a coordenação do trabalho. Tudo bem! As equipes devem trabalhar da melhor maneira para elas, especialmente em uma realidade de trabalho remoto. Mas precisávamos padronizar a forma de comunicar o trabalho que nossas equipes estavam fazendo.

Mas como saber o que padronizar, se cada um está fazendo as coisas à sua maneira? Descobrindo o que todos estão usando mais ou menos da mesma maneira, e padronizando isso.

No Notion, nossos grupos de engenharia, produtos e design foram em geral centrados em três conceitos: equipes, projetos e tarefas (você pode encontrar nossas definições para cada um abaixo). Dedicamos um tempo definindo cada componente e depois os codificamos em um documento para toda a empresa, para que todos criassem projetos da mesma maneira.

Também é importante chegar a um acordo sobre o que não deve ser padronizado. Por exemplo, não ditamos como as equipes fazem suas reuniões, ou que ferramentas de mockup usar. Escolha algumas regras básicas e depois deixe as pessoas trabalharem livremente.

A identificação e padronização destes componentes nos ajudou a organizar todo o nosso trabalho em cada produto e equipe de engenharia. No entanto, precisávamos nos comunicar de maneira consistente com o resto da empresa sobre esse trabalho, e falando a mesma língua que eles.

Para fazer isto com eficiência, criamos um sistema de comunicação com quatro partes:

• Equipes – um conjunto de pessoas que contém projetos.

• Projetos – um trabalho discreto e independente, que pode ser dividido em tarefas.

• Tarefas – itens de trabalho atribuídos a um indivíduo.

• Atualizações – um resumo rápido e legível de cada projeto, a ser feito a cada 2 semanas.

Algumas partes ajudam as equipes de engenharia a se coordenar entre si, e outras, como as atualizações, são importantes para o resto da empresa. Cada uma é uma base de dados do Notion, com todas elas interligadas para criar o sistema. Pensamos nesse sistema como tendo quatro camadas, com cada uma dando um nível diferente de contexto para equipes diferentes.

O seu sistema provavelmente terá uma outra aparência – ele pode existir em planilhas ou em uma pasta de documentos. Você pode organizar seu trabalho em sprints ou em marcos. Mas se você quiser um ponto de partida, incluímos abaixo a nossa configuração exata como modelo.

Vamos mostrar cada parte do sistema, como o estruturamos e a que público ele serve.

Ter proprietários claros deixa os projetos organizados. Mas fazer uma lista exata das equipes é mais difícil do que parece. Você não cria um software como se estivesse em um organograma. Você está procurando os grupos virtuais onde as pessoas realmente trabalham para lançar algo. Isso pode incluir funções que você normalmente não imaginaria em uma mesma "equipe", como um engenheiro, um designer, um advogado, alguém do marketing e algumas outras.

Uma boa maneira de encontrar essas equipes é olhar os canais de Slack que as pessoas criam para coordenar seus projetos. Esses canais podem dar uma pista das equipes não-oficiais operando em um dado momento.

Depois de encontrá-las, você pode construir uma lista de equipe tão simples ou complexa quanto quiser. Na nossa, incluímos o nome da equipe, quem está nela e uma breve descrição do que cada um faz, além de algumas outras informações úteis, como o canal do Slack e os documentos da equipe.

Assim que tiver suas equipes, você pode identificar os projetos de cada uma delas. Para nós, os projetos são a "coisa" que pode ser lançada, e na maioria das vezes, são as coisas com as quais as pessoas da empresa mais se importam.

Isso também importa para equipes como Vendas, Jurídico e outras subequipes de engenharia – elas podem não estar ativamente no projeto, mas muitas vezes querem entender o progresso para trabalhar melhor. E todo mundo quer o mesmo nível de contexto:

• O que o projeto está resolvendo

• Qual é o status

• O que está sendo lançado

• Onde entrar mais fundo no design e nas decisões

Nossa base de dados de Projetos é otimizada para responder a essas perguntas: ela inclui nome do projeto, uma descrição resumida, status, data de lançamento e indicações para os documentos mais detalhados. Nós as exibimos como tabelas, para que qualquer pessoa possa passar o olho na lista de projetos ativos e obter na hora as respostas de que precisa.

Assim que os projetos são identificados, os engenheiros, designers e gerentes de produto podem dividi-los em tarefas gerenciáveis. Elas devem representar o trabalho diário da equipe do projeto e devem ser específicas e detalhadas o suficiente para as pessoas que estão trabalhando. Se você tenta tornar as tarefas compreensíveis para todos, elas se tornam vagas e inúteis.

Para tornar as tarefas compreensíveis para as pessoas que as executam, usamos propriedades específicas para rastrear a prioridade, status de QA, engenheiro designado, projeto relacionado e qualquer outra coisa que os engenheiros precisem para realizar seu trabalho.

A camada final é para pessoas que não sabem em que projetos estão interessadas. Se muitas tarefas constituem um projeto, então muitos projetos constituem uma atualização. As pessoas não vão analisar uma lista de 50 projetos. Elas querem ser apresentadas às coisas a que devem prestar atenção.

Como as atualizações semanais são para toda a organização, eu mesmo as escrevo de maneira simples e legível. Eu pego o conteúdo das atualizações individuais de produtos escritas por cada equipe de engenharia e depois as escrevo em páginas do Notion para que sejam facilmente encontradas em meio a atualizações mais antigas. Mas você também pode formatá-las como e-mails ou documentos.

Atualmente, eu estruturo as atualizações semanais em três compartimentos:

• O que vai ser lançado – simplesmente uma lista de tudo o que foi lançado para os clientes externos naquela semana.

• Anúncios – coisas que estão progredindo, boas ou ruins. Por exemplo, você pode colocar aqui um novo requerimento de produto, ou atrasos importantes em um projeto.

• Para seu conhecimento – aprendizados de projetos recentes ou mudanças gerais no organograma de produtos ou de engenharia.

Mas fique preparado para mudanças nessa estrutura, à medida que as prioridades da empresa mudarem. No momento, estamos interessados em saber o que está sendo lançado e em garantir que todas as equipes saibam desses planos. Se sua equipe estiver trabalhando em três grandes itens, sua atualização pode se concentrar em como eles estão progredindo.

Sabe tudo isso que acabamos de dizer? Tudo isso vai pelo buraco se ninguém usar o seu sistema. Para ter certeza de que o nosso havia dado certo, precisávamos mostrar às pessoas o valor que ele trazia.

Nosso objetivo era manter todos na mesma página, ao mesmo tempo em que pedíamos o mínimo de trabalho a mais possível. É um equilíbrio complicado. Para fazer isso, encontramos o máximo de maneiras possíveis de conectar partes do sistema entre si. Dessa forma, adicionar informações a uma parte torna as outras mais valiosas, incentivando as pessoas a continuar contribuindo para o sistema como um todo.

Por exemplo, eu incorporo o rastreador do projeto no fim de cada atualização semanal. Qualquer pessoa que quiser saber mais sobre um determinado projeto sabe exatamente aonde ir para ver mais detalhes. Com isso, eu incentivo a equipe de engenharia a manter a lista de projetos em dia.

Além disso, cada equipe de engenharia incorpora uma visualização filtrada da base de dados de tarefas dentro de cada documento de projeto em que apenas as tarefas relacionadas são visíveis. Quem abrir a página do projeto pode ver na hora como o trabalho foi dividido e até onde ele avançou.

Fazer o link com os sistemas de outros departamentos é algo que também reforça o seu valor. Por exemplo, o Marketing de Produtos – eles procuram as datas de lançamento externas no rastreador de Projetos para preencher um calendário de lançamento.

No fim desse processo, criamos um sistema para rastrear todos os nossos produtos e trabalhos de engenharia em um só lugar e comunicá-lo ao resto da empresa com o mínimo de despesas. Esperamos que essa estrutura seja útil para você levar à sua equipe.

Mas as coisas mudam rapidamente nas startups! O sistema que usamos muda à medida que crescemos. O seu vai mudar também.

Assim, com a evolução dos seus sistemas, você vai ver que compreender o que cada equipe precisa saber é o mais importante. É preciso uma empresa inteira para criar um produto. E ter em mente as necessidades de todos é a maneira como mantemos a transparência à medida que escalamos.