Como criar uma base de conhecimento de produto que as pessoas realmente usem

As equipes de produto são alguns dos criadores de conhecimento mais prolíficos em qualquer organização. Pesquisas com usuários, análises de concorrentes, especificações de recursos, PRDs, registros de decisões, sínteses de feedback de clientes, justificativas de roadmaps, resultados de experimentos, avaliações pós-morte (post-mortems). O volume de pensamento investido no trabalho de produto é enorme, e quase tudo é valioso além do momento em que foi criado.

Quase nada disso é encontrável seis meses depois.

A pesquisa com usuários da fase de descoberta do ano passado vive em um Google Doc que o pesquisador que o criou já deixou a empresa desde então. A análise competitiva está em uma página do Notion que ninguém atualiza desde o segundo trimestre. O PRD para um recurso que foi descontinuado está no Confluence, intitulado com um codinome interno que ninguém lembra. A decisão sobre por que a equipe escolheu a abordagem A em vez da abordagem B foi tomada em um tópico do Slack que já desapareceu há muito tempo.

O conhecimento foi criado. O investimento foi feito. A recuperação falha porque o conhecimento está espalhado por várias ferramentas, nomeado pelas convenções do criador em vez das necessidades de quem busca, e sem manutenção após a conclusão do projeto imediato.

O que contém uma base de conhecimento de produto funcional

Registros de decisão. Por que a equipe escolheu essa abordagem, quais alternativas foram consideradas, quais restrições motivaram a decisão. Isso evita a re-discussão e dá aos novos membros da equipe o contexto de que precisam sem reabrir questões resolvidas.

Repositório de pesquisa de usuários. Cada entrevista, pesquisa, teste de usabilidade e insight, pesquisável por tema e pergunta em vez de nome do projeto e data. O insight sobre a fricção na integração de usuários corporativos da descoberta do ano passado é relevante para o trabalho de recursos deste ano.

Inteligência competitiva. Atualizada continuamente a partir de inteligência de campo, relatórios de analistas e lançamentos de produtos, em vez de ser montada trimestralmente e ficar obsoleta em semanas.

Contexto do recurso. Para cada recurso significativo: por que foi construído, qual problema do usuário ele resolve, quais são as métricas de sucesso, o que foi deliberadamente excluído. Esse contexto é importante muito tempo após o lançamento do recurso, pois embasa decisões futuras sobre iteração, extensão e descontinuação.

Justificativa do roadmap. Por que os itens são priorizados da forma como são. O roadmap em si é normalmente visível. O raciocínio por trás da priorização costuma estar trancado na cabeça do líder de produto, o que significa que cada conversa sobre "por que estamos trabalhando no X em vez do Y?" exige que o líder de produto explique novamente a justificativa em vez de apontar para um documento.

Por que as bases de conhecimento de produto falham

Elas falham pelos mesmos motivos estruturais pelos quais todas as wikis falham: a contribuição exige trabalho extra, ninguém mantém o conteúdo após o projeto inicial, a busca é baseada em palavras-chave e perde resultados conceitualmente relevantes, e a organização reflete o modelo mental do colaborador em vez das necessidades de quem busca.

As equipes de produto têm um modo de falha adicional: o conhecimento é criado durante uma fase específica do projeto (descoberta, planejamento, execução) e é relevante para essa fase. Assim que a fase termina, o conhecimento perde sua urgência imediata e o documento afunda no arquivo, inacessível e sem manutenção.

A alternativa que se escreve sozinha

A documentação que se escreve sozinha captura o conhecimento do produto a partir dos canais onde ele é naturalmente criado:

Slack discussões onde as decisões de produto são debatidas e resolvidas. O tópico onde a equipe decidiu adiar o recurso X torna-se um registro de decisão pesquisável.

Reuniões onde as prioridades do roadmap são discutidas, pesquisas de usuários são apresentadas e o contexto estratégico é compartilhado. O resultado da reunião de planejamento da sprint torna-se parte da base de conhecimento do produto automaticamente.

Canais de produto onde o contexto do recurso, o feedback dos clientes e a inteligência competitiva se acumulam diariamente.

A base de conhecimento cresce continuamente a partir da atividade existente da equipe. Não são necessários mutirões de documentação. Sem etapas separadas de contribuição. O trabalho normal do gerente de produto de discutir decisões, compartilhar contexto e debater prioridades gera a documentação como um subproduto.

Perguntas frequentes

Usamos muito o Notion para documentos de produto. Como isso é diferente? O Notion exige criação e manutenção manuais. Quando o processo da equipe muda ou uma decisão é atualizada, alguém precisa se lembrar de atualizar a página do Notion. Os documentos que se escrevem sozinhos são atualizados a partir das fontes onde as discussões reais acontecem, o que significa que a base de conhecimento reflete a realidade atual, em vez da realidade de quando alguém editou a página pela última vez.

E quanto à estratégia de produto confidencial? Os controles de acesso garantem que os documentos estratégicos fiquem visíveis apenas para as pessoas que devem vê-los. A base de conhecimento respeita os mesmos limites de acesso das ferramentas subjacentes.

Como isso se integra às nossas ferramentas de gestão de produto? As conexões com Linear, Asana, ClickUp e outras ferramentas de produto significam que o conhecimento nesses sistemas é pesquisável junto com a documentação do Slack, Google Drive e reuniões.

Leitura recomendada: Por que as decisões de produto voltam a ser discutidas, Sua pesquisa de usuário vale milhões, Ninguém lê a wiki. Páginas relacionadas: Documentos autograváveis, Para gerentes de produto, Para equipes de produto.