Entendimento compartilhado: O que distingue os melhores times de produto
O entendimento compartilhado é a principal habilidade de um excelente time de produto. Ele distingue bons times dos melhores. De acordo com um gerente de produto da Atlassian com onze anos de experiência, o melhor gerente de produto não é aquele que sabe todas as respostas. Ele garante que seu time compreenda O que eles fazem, para Quem, e Por quê. Este artigo compartilha a experiência do time hi.ducalis.io na adoção do entendimento compartilhado — um processo longo e complexo com resultados incríveis.
Como ser um bom gerente de produto
De acordo com discussões no Quora, existem duas listas principais de habilidades:
- Habilidades específicas: análise de dados, UX/UI, entrevistas, pesquisa, testes A/B
- Habilidades gerais: empatia, pensamento estratégico, proatividade, adaptabilidade, capacidade de prever consequências não intencionais
O conjunto de habilidades de um bom PM não é difícil de determinar e aprender.
Mas a gestão de produto não é apenas sobre habilidades. É sobre tomar decisões.
Duas formas de tomada de decisão
Depois de centenas de horas de entrevistas com usuários que são PMs, identificamos duas abordagens:
- Super-herói — um PM onisciente e onipotente que responde todas as perguntas do time e toma todas as decisões
- Facilitador — um PM que ajuda o time a compreender problemas e tomar decisões
A armadilha do consultor de produto
Histórias sobre Steve Jobs inspiram as pessoas a serem super-heróis.
O super-heroísmo te coloca em uma armadilha. Em vez de ser um gerente, você se torna um consultor — uma pessoa que responde qualquer pergunta sobre o produto.
Ser um super-herói de produto é uma ladeira escorregadia
Sherif Mansour, um gerente de produto distinto na Atlassian, compartilha uma história de experiência valiosa.
Uma captura de tela de "O que é gestão de produto?"
No início de sua carreira, ele acreditava que um PM é um super-herói com respostas para todas as perguntas. Eventualmente, isso levou a um problema: ele tinha que responder todas e cada uma das perguntas sobre o produto. Até perguntas como "coloque o botão aqui", "pinte de azul", "faça requisições de API desta forma" e assim por diante. Ele ficou sobrecarregado com tarefas do dia a dia.
Em uma reunião individual com seu gerente, ele descreveu dezenas de sutilezas sobre o que o time estava fazendo. Quais botões eles colocavam e como ele se sentia sobrecarregado. Mas o que ele ouviu foi que deveria se concentrar em coisas mais estratégicas.
Essa é uma das maiores armadilhas na gestão de produto:
Você rebaixa a si mesmo de gerente de produto para consultor de produto ao responder constantemente cada vez mais perguntas dos seus colegas de equipe. (ideia de Ivan Spasojevic do tópico no Quora)
Problemas do consultor de produto
- O número de perguntas cresce — o escopo diminui
- O trabalho para sem você
- O time faz mais trabalho desnecessário
Você precisa verificar e estudar tudo. Caso contrário, será implementado de forma errada. Provavelmente sem um propósito claro.
Você busca ajuda no planejamento de roadmap, documentos de requisitos de produto e priorização do Backlog.
No entanto, mesmo se seu time ler tudo isso, eles percebem as tarefas de forma diferente.
Escrever ideias e estratégias, ou lê-las, não significa necessariamente compreendê-las.
Gestão de produto é um esporte de equipe
Uma captura de tela de Mind the Product em 2019
Em seu discurso na conferência Mind The Product, Sherif Mansour aponta o principal equívoco em toda a sua carreira — os gerentes de produto tomam todas as decisões.
Você precisa mudar essa mentalidade e capacitar seus times com tomada de decisão.
Um PM é responsável pela velocidade da tomada de decisão. A missão é aumentá-la construindo um entendimento compartilhado do time. Essa foi sua lição mais valiosa.
Os três P's do entendimento compartilhado
O time deve compreender claramente:
- Para quem — Eles têm contexto suficiente sobre para quem estão resolvendo
- O que — Eles compreendem qual problema estão resolvendo
- Por quê — Eles compreendem como isso se encaixa no panorama geral
Um dos sinais de entendimento compartilhado é que seu time funciona bem sem você tocar no Backlog. Eles não precisam que você escolha as tarefas certas para seus clientes e estratégia. Eles estão sempre plenamente cientes do que fazem, como e por quê.
Seus designers, engenheiros e analistas conseguem decidir soluções por conta própria?
Sinais de ótimo entendimento compartilhado
- Você não vê seu Backlog há meses, e seu time está executando bem
- Seu time te desafia sobre coisas que estão fazendo que não estão alinhadas com sua estrela norte
- Seu time referencia clientes pelo nome
- Seu time quer trabalhar em resultados em vez de entregas. Eles dizem "Isso vai nos ajudar a aumentar a retenção" e não "Preciso completar o épico para receber o bônus"
- As demonstrações do time são formadas em torno de "estamos construindo X para resolver o problema Y do cliente" sem nenhum estímulo
- Seus projetos paralelos estão todos alinhados com seu roadmap
Pense: Como PM/CEO/proprietário, você está pronto para não intrometer nos planos do time e não atribuir todas as tarefas você mesmo?
O que torna um gerente de produto distinto
Sherif aponta dois principais ofícios da gestão de produto:
- Construir entendimento compartilhado — fazer pesquisa com clientes, insights de dados, coleções, pesquisas, prototipagem rápida e assim por diante. É importante que você faça essas atividades juntos como um time. Isso ajuda você a compreender melhor o problema do cliente e a intenção e construir entendimento compartilhado juntos
- Identificar lacunas no entendimento compartilhado — perguntar ao seu time se eles compreendem claramente o O que, o Para quem e o Por quê. Converse com seu time ou faça pesquisas. Quando você encontra as lacunas, você conduz atividades para fechá-las
Exemplos de resultados na pesquisa "Os 3 P's"
Experiência pessoal na construção de entendimento compartilhado
Toda a história de como nosso time usa o hi.ducalis.io é uma tentativa de construir entendimento compartilhado no hi.ducalis.io.
1. Compartilhar emoções dos clientes com todo o time
Usamos o método "The Mom Test" para entrevistas com clientes. Tentamos não vender, não fazer uma demonstração ou dizer nada sobre nossas soluções. Apenas ouvimos como nossos clientes em potencial descrevem seu fluxo de trabalho, problemas e pontos de dor.
Pedimos permissão para gravar um vídeo para o resto do nosso time. É importante compartilhar os momentos mais vívidos da história do usuário com suas emoções e palavras. Esse exercício ajuda a ter uma noção dos problemas do cliente e não toma muito tempo do time.
2. Expressar objetivos do produto em critérios de avaliação
Costumávamos ter um documento com metas e objetivos da empresa. Mas era difícil lembrar métricas e objetivos-chave sem uma dica. Depois os transformamos em Critérios de avaliação de tarefas no Ducalis.
Temos três conjuntos de Critérios:
- Critérios comuns que todo o time deve compreender: Ativação, Retenção, Velocidade do Serviço e Assistência à Colaboração
- Critérios de desenvolvedores: Complexidade de Desenvolvimento
- Critérios de gerentes: Potencial de Vendas e Demanda de Funcionalidades
Um conjunto de Critérios para refinamento do Backlog
3. Avaliar o Backlog juntos às sextas-feiras
Cada membro do time deve estimar tarefas e Ideias do Backlog. Desenvolvedores e gerentes de produto têm Critérios ligeiramente diferentes. Atribuímos pontuações subjetivamente, então é fácil e rápido. O importante é fazer isso regularmente. Usamos Sprints semanais, e então refinamos o Backlog toda semana.
Avaliação de tarefa por Critérios no Ducalis
4. Planejar Sprints às segundas-feiras
Depois do refinamento, temos todas as nossas tarefas classificadas por prioridade. A lista de maior prioridade é consultiva. O time popula a Sprint de forma independente. No planejamento, explicamos o O que, o Para quem e o Por quê. Podemos ajustar nossos planos se o contexto mudou durante o fim de semana.
Itens do Backlog ordenados por prioridade
5. Encontrar lacunas no entendimento compartilhado
- Se não compreendemos como avaliar um Critério, colocamos um traço. Então discutimos o Critério juntos e podemos reescrever sua descrição. Se não compreendemos a tarefa, deixamos comentários no Jira. Isso ajuda o relator a encontrar confusão na Ideia ou falta de alinhamento com a visão
- As pontuações são descartadas 30 dias depois que a tarefa foi avaliada. Se não foi completada, estimamos e repensamos novamente. Com frequência, decidimos excluir a tarefa. A reavaliação é crítica. Isso nos ajuda a compreender a relevância do Backlog, já que regularmente recebemos novo contexto dos clientes
Tudo isso junto nos dá uma imagem do alinhamento do time. Vemos onde o time tem desacordos ou falta de entendimento compartilhado.
Os resultados da construção de entendimento compartilhado no time hi.ducalis.io
O sistema começou a dar frutos dentro de alguns meses. Aqui está o feedback do time:
- Na maioria das vezes, é ótimo. Tanto gerentes quanto desenvolvedores agora têm uma melhor compreensão do produto. Tentamos olhar de diferentes ângulos. Nossas discussões ficaram mais fundamentadas.
- O entendimento compartilhado parece estar em alto nível.
- Nos faltam indicadores de para onde estamos indo. Tipo, o número de clientes deveria ser X, receita K, e assim por diante. Isso ajudaria ao estudar prioridades. A tarefa contribui para os valores? (Este problema já corrigimos)
- Muitas coisas ainda dependem do Vit (CEO). Ele não delega ou confia muito na implementação de tarefas.
Como você vê, não podemos dizer que tudo está esplêndido. Mas fica melhor a cada semana. Construir entendimento compartilhado requer muito esforço. Mas vale a pena. Ainda pensamos às vezes "É mais rápido implementar do que explicar". Mas isso é apenas engavetar os problemas para o futuro.
Experimente nossos métodos no hi.ducalis.io
Cadastre-se e tente avaliar os Itens. O produto em si vai guiar você pela metodologia.
Lista de leitura
P.S. Síndrome de Steve Jobs — ser um gênio solitário que prevê o futuro. Uma pessoa que não está interessada nas opiniões de clientes ou colegas. Aquele que sabe o que fazer a seguir. Mas ainda assim, lembramos Steve dizendo "Contrate pessoas inteligentes e deixe-as dizer o que fazer."