Skip to content

🗺️Craft & Know-How

Gerente de Produto · Decide o que uma empresa deve construir a seguir e por quê – transformando as necessidades dos clientes, as metas de negócios e os limites de engenharia em um plano compartilhado que ninguém mais possui.

Share

A imagem de um gerente de produto esboçando uma visão ousada em um quadro branco é, em grande parte, errada. A maior parte do trabalho é uma síntese nada glamorosa: ler dados de pesquisas e análises, escrever um documento preciso o suficiente para que um engenheiro não possa interpretá-lo mal e assistir a reuniões onde o verdadeiro trabalho é fazer com que várias pessoas discordantes se comprometam com um plano.

A arte transmitida dentro da disciplina tem menos a ver com uma única ferramenta e mais com hábitos: como dizer não a uma boa ideia porque é a ideia errada no momento, como escrever uma especificação que sobreviva ao contato com um engenheiro real e quando confiar no que um cliente faz em vez do que ele diz preferir.

What the work demands

908278756858
Priorização
90
Comunicação escrita
82
Influência das partes interessadas
78
Análise de dados
75
Pesquisa de usuário
68
Fluência técnica
58

Priorização

Decidir o que não construir é a decisão diária mais importante – um roteiro é principalmente uma longa lista de boas ideias às quais um gerente de produto decidiu dizer não.

Comunicação escrita

Uma especificação, uma atualização do roteiro ou uma autópsia devem ser suficientemente precisas para que as pessoas que não estavam presentes possam agir corretamente.

Influência das partes interessadas

Fazer com que a engenharia, o design, as vendas e os executivos se comprometam com o mesmo plano, quase sem autoridade formal sobre nenhum deles – muitas vezes resumido como “liderar sem poder”.

Análise de dados

Ler dados de uso e resultados de experimentos bem o suficiente para diferenciar um sinal real de ruído e saber quando uma métrica está sendo manipulada em vez de genuinamente melhorada.

Pesquisa de usuário

Conversar diretamente com os clientes e observá-los usar um produto, em vez de confiar apenas no que uma pesquisa ou um relato de segunda mão da equipe de vendas diz que eles desejam.

Fluência técnica

Compreender o suficiente sobre como o sistema subjacente funciona para ter uma conversa real sobre as compensações com os engenheiros, sem necessariamente ser capaz de construí-lo sozinho.

A day in the life

Métricas de caixa de entrada, Slack e overnightStandups e sincronizações entre equipesTrabalho profundo: especificações e análisesAlmoçoReuniões e revisões das partes interessadasFora do horário (principalmente) 036912151821 24h
  1. 8–9 Métricas de caixa de entrada, Slack e overnight

    Acompanhar as mensagens e verificar os painéis noturnos em busca de algo que tenha quebrado ou movido inesperadamente antes do início das reuniões do dia.

  2. 9–11 Standups e sincronizações entre equipes

    Uma reunião diária com a equipe imediata do produto, além de reuniões recorrentes com líderes de design, engenharia ou uma equipe dependente para desbloquear o trabalho e resolver divergências.

  3. 11–13 Trabalho profundo: especificações e análises

    O bloco mais bem protegido do dia, gasto escrevendo ou revisando uma especificação, analisando os resultados de um experimento ou preparando um documento para uma decisão futura.

  4. 13–14 Almoço

    Uma pausa genuína num dia bom; em uma reunião ruim, ele desaparece em reuniões consecutivas que duram muito.

  5. 14–18 Reuniões e revisões das partes interessadas

    O bloco de reunião mais pesado do dia: revisões de roadmap, críticas de design, vendas ou ligações de clientes e as negociações que decidem o que realmente será enviado no próximo trimestre.

  6. 18–8 Fora do horário (principalmente)

    O tempo pessoal, embora uma semana de lançamento ou um escalonamento urgente do cliente possa atrair um gerente de produto de volta ao Slack bem depois do término oficial do dia de trabalho.

The know-how

Craft knowledge practitioners actually pass on — not motivation.

01

Escreva o problema antes da solução

Declare o problema do cliente e por que ele é importante em linguagem simples antes de propor qualquer recurso específico – forçar a equipe a concordar sobre o problema primeiro detecta soluções erradas antes que alguém escreva o código.

Prática padrão de PRD, amplamente ensinada pelo Grupo de Produtos do Vale do Silício de Marty Cagan
02

Converse com os usuários, não apenas faça pesquisas com eles

Uma pesquisa informa o que as pessoas dizem que desejam; observar alguém realmente tentar usar um produto, pessoalmente ou por meio de um compartilhamento de tela, revela o atrito que eles nunca pensaram em mencionar.

Ecoado na prática de pesquisa de usuários, notadamente no método de desenvolvimento de clientes de Steve Blank
03

Envie a menor coisa que teste o risco real

Antes de criar um recurso completo, reduza-o para a versão menor que testa a suposição com maior probabilidade de estar errada – às vezes, um único botão que mede os cliques antes que qualquer coisa por trás dele exista.

Eric Ries, The Lean Startup (2011), com base no conceito de produto mínimo viável
04

Ganhe a autoridade que o título não lhe dá

Defina a direção e tome a decisão final quando as pessoas discordarem, mas conquiste essa autoridade por meio de preparação e julgamento, em vez de presumir que ela vem com o título – um gerente de produto sem poder organizacional tem que estar certo com mais frequência do que um gerente que pode simplesmente dar uma ordem.

Ben Horowitz, memorando "Bom gerente de produto, gerente de produto ruim", Netscape, 1997
05

Diga não por escrito e diga por quê

Rejecting a feature request quietly breeds resentment; escrever uma frase explicando a compensação – por que isso e não aquilo neste trimestre – transforma um não em uma decisão que as pessoas podem realmente discutir ou aceitar.

Prática comum de gerenciamento de produtos, associada a ferramentas públicas de roadmap como ProdPad
06

Desconfie de uma métrica que ninguém pode mover

Se uma métrica de sucesso proposta não mudou visivelmente após vários esforços anteriores para movê-la, questione se é realmente a medida certa antes de apostar o roteiro de um trimestre na mudança.

Disciplina de experimentação padrão, refletida na prática de crescimento em empresas como Airbnb e Booking.com

Tools of the trade

Plataforma analítica

Ferramentas como Amplitude, Mixpanel ou um painel interno transformam registros de uso brutos em funis e coortes sobre os quais um gerente de produto pode realmente raciocinar.

Rastreador de problemas e roteiros

Jira, Linear ou uma ferramenta semelhante transforma uma lista de ideias em um backlog visível e priorizado que a engenharia, o design e a liderança podem ver ao mesmo tempo.

Especificação/modelo PRD

Um formato de documento estruturado – problema, objetivo, requisitos, casos extremos, métrica de sucesso – que mantém uma especificação legível o suficiente para um engenheiro construir sem adivinhar.

Plataforma de testes A/B

Ferramentas como o Optimizely ou uma estrutura de experimentação interna permitem que uma equipe envie duas versões de um recurso para usuários diferentes e avalie qual delas realmente tem melhor desempenho.

Assistente de desenho de IA

Ferramentas como ChatGPT ou Claude elaboram cada vez mais uma primeira versão de uma especificação, resumem entrevistas de usuários ou sintetizam respostas de pesquisas, mudando o trabalho para edição e julgamento em vez de digitação em uma página em branco.

How people fail at it

Síndrome da fábrica de recursos

Medir o sucesso pela quantidade de recursos fornecidos, em vez de se algum deles resolveu um problema real, o que produz um roteiro complicado e um produto que na verdade não melhora.

Construindo o que o cliente mais barulhento pediu

Tratar a solicitação de recurso específico de um cliente como uma necessidade representativa, em vez de verificar se ela reflete um problema compartilhado por uma parcela significativa de usuários.

Ignorando o 'porquê' na especificação

Escrever uma lista detalhada de requisitos sem explicar o problema ou objetivo subjacente deixa os engenheiros incapazes de tomar decisões acertadas, uma vez que a realidade inevitavelmente diverge do plano.

Similar professions

Continue exploring

Keep exploring

More in Business & Finance