Entendimento Partilhado: O Que Distingue As Melhores Equipas de Produto
O entendimento partilhado é a principal competência de uma excelente equipa de produto. É o que distingue as boas equipas das melhores. De acordo com um Product Manager da Atlassian com onze anos de experiência, o melhor product manager não é aquele que conhece todas as respostas. É aquele que garante que a sua equipa compreende O Quê fazem, para Quem, e Porquê. Este artigo partilha a experiência da equipa hi.ducalis.io ao adotar o entendimento partilhado—um processo longo e complexo com resultados incríveis.
Como ser um bom product manager
De acordo com discussões no Quora, existem duas listas principais de competências:
- Competências específicas: análise, UX/UI, entrevistas, pesquisa, testes A/B
- Competências gerais: empatia, pensamento estratégico, proatividade, adaptabilidade, capacidade de prever consequências não intencionais
O conjunto de competências de um bom PM não é difícil de determinar e aprender.
Mas a gestão de produto não é apenas sobre competências. É sobre tomar decisões.
Duas formas de tomar decisões
Após centenas de horas de entrevistas com PMs, identificámos duas abordagens:
- Super-herói—um PM que sabe tudo e é omnipotente, que responde a cada pergunta da equipa e toma todas as decisões
- Facilitador—um PM que ajuda a equipa a compreender problemas e tomar decisões
A armadilha do consultor de produto
As histórias sobre Steve Jobs inspiram as pessoas a serem super-heróis.
O super-heroísmo coloca-nos numa armadilha. Em vez de ser um gestor, tornamo-nos consultores—pessoas que respondem a qualquer pergunta sobre o produto.
Ser um super-herói de produto é uma ladeira escorregadia
Sherif Mansour, um Distinguished Product Manager na Atlassian, partilha uma história de experiência valiosa.
Imagem de "What is product management?"
No início da sua carreira, acreditava que um PM é um super-herói com respostas a todas as perguntas. Eventualmente, isto levou a um problema: tinha de responder a todas e cada uma das perguntas sobre o produto. Até perguntas como "colocar o botão aqui", "colori-lo de azul", "fazer pedidos de API desta forma", e assim por diante. Ficou sobrecarregado com tarefas do dia a dia.
Numa reunião individual com o seu gestor, descreveu dezenas de pormenores sobre o que a equipa estava a fazer. Que botões colocavam e quão sobrecarregado se sentia. Mas o que ouviu foi que deveria focar-se em aspetos mais estratégicos.
Esta é uma das maiores armadilhas na gestão de produto:
Rebaixamo-nos de Product Manager para Consultor de Produto ao responder constantemente a cada vez mais perguntas dos colegas de equipa. (ideia de Ivan Spasojevic da discussão no Quora)
Problemas do consultor de produto
- O número de perguntas cresce—o âmbito diminui
- O trabalho para sem nós
- A equipa faz mais trabalho desnecessário
É necessário verificar e estudar tudo. Caso contrário, será implementado incorretamente. Provavelmente sem um objetivo claro.
Procuramos ajuda no planeamento de roadmap, em documentos de requisitos de produto e na priorização do backlog.
No entanto, mesmo que a equipa leia tudo isso, percebe as tarefas de forma diferente.
Escrever ideias e estratégias, ou lê-las, não significa necessariamente compreendê-las.
A gestão de produto é um desporto de equipa
Imagem do Mind the Product em 2019
Na sua apresentação na conferência Mind The Product, Sherif Mansour destaca a principal ideia errada de toda a sua carreira—os Product Managers tomam todas as decisões.
É necessário mudar essa mentalidade e capacitar as equipas para a tomada de decisões.
Um PM detém a velocidade da tomada de decisões. A missão é aumentá-la através da construção do entendimento partilhado da equipa. Essa foi a sua lição mais valiosa.
Os três Q's do entendimento partilhado
A equipa deve compreender claramente:
- O Quem—Têm contexto suficiente sobre para quem estão a resolver
- O Quê—Compreendem que problema estão a resolver
- O Porquê—Compreendem como se enquadra no panorama geral
Um dos sinais de entendimento partilhado é que a equipa funciona bem sem tocarmos no backlog. Não precisam de nós para escolher as tarefas certas para os clientes e estratégia. Estão sempre plenamente conscientes do que fazem, como, e porquê.
Os designers, engenheiros e analistas conseguem decidir sobre soluções sozinhos?
Sinais de excelente entendimento partilhado
- Não vê o backlog há meses, e a equipa está a executar bem
- A equipa desafia-nos em aspetos que não estão alinhados com o objetivo principal
- A equipa refere clientes pelo nome
- A equipa quer trabalhar em resultados em vez de entregas. Dizem "Isto vai ajudar-nos a aumentar a retenção" em vez de "Preciso de concluir o epic para receber um bónus"
- As demonstrações da equipa são formadas em torno de "estamos a construir X para resolver o problema Y do cliente" sem qualquer instrução
- Os seus projetos paralelos estão todos alinhados com o roadmap
Reflexão: Como PM/CEO/proprietário, está pronto para não interferir nos planos da equipa e não atribuir todas as tarefas pessoalmente?
O que torna um product manager distinto
Sherif destaca dois principais ofícios da gestão de produto:
- Construir entendimento partilhado—fazer pesquisa de clientes, análise de dados, coleções, inquéritos, prototipagem rápida, e assim por diante. É importante fazer estas atividades em conjunto como equipa. Isto ajuda a compreender melhor o problema e a intenção do cliente e a construir entendimento partilhado em conjunto
- Identificar lacunas no entendimento partilhado—perguntar à equipa se compreendem claramente o Quê, o Quem e o Porquê. Falar com a equipa ou fazer inquéritos. Quando encontramos lacunas, conduzimos atividades para as colmatar
Exemplo de resultados do inquérito "Os 3 Q's"
Experiência pessoal na construção de entendimento partilhado
Toda a história de como a nossa equipa usa hi.ducalis.io é uma tentativa de construir entendimento partilhado em hi.ducalis.io.
1. Partilhar emoções dos clientes com toda a equipa
Usamos o método "The Mom Test" para entrevistas com clientes. Tentamos não vender, não fazer uma demonstração nem dizer nada sobre as nossas soluções. Apenas ouvimos como os nossos potenciais clientes descrevem o seu fluxo de trabalho, problemas e pontos de dor.
Pedimos permissão para gravar um vídeo para o resto da equipa. É importante partilhar os momentos mais vívidos da história do utilizador com as suas emoções e palavras. Esse exercício ajuda a ter uma noção dos problemas do cliente e não leva muito tempo da equipa.
2. Expressar objetivos do produto em critérios de avaliação
Costumávamos ter um documento com objetivos e metas da empresa. Mas era difícil lembrar as métricas e objetivos principais sem uma ajuda. Mais tarde transformámo-los em Critérios de avaliação de tarefas em Ducalis.
Temos três conjuntos de Critérios:
- Critérios Comuns que toda a equipa deve compreender: Ativação, Retenção, Velocidade de Serviço e Assistência à Colaboração
- Critérios de Programadores: Complexidade de Desenvolvimento
- Critérios de Gestores: Potencial de Vendas e Procura de Funcionalidade
Um conjunto de Critérios para grooming do backlog
3. Avaliar o backlog em conjunto às sextas-feiras
Cada membro da equipa deve estimar tarefas e Ideias do backlog. Programadores e product managers têm Critérios ligeiramente diferentes. Atribuímos pontuações subjetivamente, por isso é fácil e rápido. O importante é fazer isto regularmente. Usamos sprints semanais, e por isso fazemos grooming do backlog todas as semanas.
Avaliação de Tarefa por Critérios em Ducalis
4. Planear sprints às segundas-feiras
Após o grooming, obtemos todas as nossas tarefas ordenadas por prioridade. A lista de Prioridade Máxima é consultiva. A equipa preenche o sprint de forma independente. No planeamento, explicamos o Quê, o Quem e o Porquê. Podemos ajustar os nossos planos se o contexto mudou durante o fim de semana.
Items do Backlog ordenados por prioridade
5. Encontrar lacunas no entendimento partilhado
- Se não compreendemos como avaliar um Critério, colocamos um traço. Depois discutimos o Critério em conjunto e podemos reescrever a sua descrição. Se não compreendemos a tarefa, deixamos comentários no Jira. Isto ajuda o autor a encontrar confusão na Ideia ou falta de alinhamento com a visão
- As pontuações são descartadas 30 dias após a tarefa ter sido avaliada. Se não foi concluída, estimamos e repensamos novamente. Com bastante frequência, decidimos eliminar a tarefa. A reavaliação é crítica. Isto ajuda-nos a compreender a relevância do backlog, pois recebemos regularmente novo contexto do cliente
Tudo isto em conjunto dá-nos uma imagem do Alinhamento da Equipa. Vemos onde a equipa tem desacordos ou falta de entendimento partilhado.
Os resultados da construção de entendimento partilhado na equipa hi.ducalis.io
O sistema começou a dar frutos em poucos meses. Eis o feedback da equipa:
- Na maioria das vezes, é ótimo. Tanto gestores como programadores têm agora uma melhor compreensão do produto. Tentamos olhar de diferentes ângulos. As nossas discussões tornaram-se mais fundamentadas.
- O Entendimento Partilhado parece ser de nível elevado.
- Faltam-nos indicadores de para onde vamos. Por exemplo, o número de clientes deveria ser X, a receita K, e assim por diante. Isto ajudaria ao estudar prioridades. A tarefa contribui para os valores? (Este resolvemos)
- Muitas coisas ainda dependem do Vit (CEO). Não delega nem confia muito a implementação de tarefas.
Como vê, não podemos dizer que está tudo esplêndido. Mas fica melhor cada semana. Construir entendimento partilhado requer muito esforço. Mas vale a pena. Ainda pensamos por vezes: "É mais rápido implementar do que explicar." Mas isso é apenas guardar os problemas para o futuro.
Experimente os nossos métodos em hi.ducalis.io
Registe-se e experimente avaliar os Items. O produto em si vai guiá-lo através da 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 a dizer: "Contrate pessoas inteligentes e deixe-as dizer-lhe o que fazer."