Perguntas de entrevista para product manager sobre o que foi matado, não sobre o que subiu
Todo product manager consegue descrever algo que subiu. Bem menos conseguem descrever algo que mataram, e essa é a história mais preditiva. Porque a restrição em produto quase nunca é ideia, é decidir quais não fazer e sustentar isso contra gente acima de você. A entrevista deveria então ser quase toda sobre recusa, evidência, e o que aconteceu depois de uma decisão se mostrar errada.
O que o trabalho envolve de verdade
O product manager decide o que é construído e, mais consequente ainda, o que não é. O dia é reunir evidência, escrever, discutir prioridade com design, engenharia e quem responde pelo número, e depois explicar a decisão resultante para quem queria outra coisa.
Quase nenhuma autoridade vem com o cargo. PM não manda em engenharia, não sobrepõe design e não define sozinho a estratégia comercial, então tudo funciona por acertar com frequência suficiente para as pessoas irem junto. Isso faz disciplina de evidência e capacidade de discordar bem serem os dois traços que mais valem triar.
As perguntas, e como soa uma boa resposta
Use as perguntas como estão. Cada uma vem com o que é uma resposta forte, para que duas pessoas avaliando o mesmo candidato cheguem à mesma conclusão pelo mesmo motivo.
1. Me conta de algo que você matou.
Uma boa resposta: Algo específico, com o que mudou a cabeça dele e como contou para quem estava investido. Resposta forte inclui matar a própria ideia. PM sem nenhuma morte está descrevendo um roadmap que só cresce, que é a falha mais comum da função.
2. Alguém sênior quer uma funcionalidade que você acha errada.
Uma boa resposta: Pergunta qual problema a pessoa está resolvendo, traz evidência, propõe um teste menor em vez de recusa seca, e assume se for vencido. Os dois extremos falham. Construir calado e recusar de cara são igualmente ruins.
3. A sua evidência é fraca e a decisão precisa sair esta semana.
Uma boa resposta: Decide, declara o nível de confiança, e diz o que mudaria a cabeça dele. Esperar certeza também é uma decisão, e candidato forte fala isso.
4. Você subiu algo e a métrica não mexeu.
Uma boa resposta: Investiga se a coisa funcionou, se a métrica era a certa, e se a mudança foi pequena demais para detectar, e depois age. Resposta fraca declara aprendizado e segue, ou culpa a adoção.
5. Como você decide entre duas funcionalidades quando as duas estão bem argumentadas?
Uma boa resposta: Um critério declarado — reversibilidade, tamanho do grupo afetado, aderência à estratégia, custo do atraso — em vez de quem argumentou mais forte. O critério importa mais que qual foi escolhida.
6. Engenharia diz que o seu requisito leva um trimestre e você imaginava duas semanas.
Uma boa resposta: Pergunta o que torna caro e procura a versão que preserva o resultado. PM que negocia escopo em vez de prazo entrega mais.
7. Como você sabe o que o usuário precisa em vez do que ele pede?
Uma boa resposta: Cita métodos e a distinção entre pedido e problema. Resposta forte cita uma vez em que algo muito pedido acabou não importando.
8. O que está no seu roadmap só porque alguém importante quer?
Uma boa resposta: Resposta honesta, e consciência do custo. Todo roadmap tem uma; quem afirma que não tem ou não está sendo franco ou não sabe o que tem no próprio.
Uma ficha de avaliação para pontuar
Dê de 1 a 4 em cada linha, e anote a nota antes de assistir ao próximo. A nota escorrega quando ela é dada em relação a quem você acabou de ver.
| Critério | Como é uma nota 4 |
|---|---|
| Disposição de matar | Nomeia algo matado, de preferência próprio. Nota 2 só subiu coisas. |
| Discordar para cima | Traz evidência e propõe teste menor, depois assume. Nota 2 constrói calado ou recusa. |
| Decidir sob incerteza | Decide com confiança declarada e um falseador. Nota 2 espera mais dado. |
| Honestidade pós-lançamento | Investiga métrica parada direito. Nota 2 chama de aprendizado e segue. |
| Critério de priorização | Aplica um critério declarado. Nota 2 segue quem argumentou mais forte. |
Como rodar a triagem
- Comece pelo que a pessoa matou. É a pergunta de maior sinal em entrevista de produto e é muito difícil de inventar com detalhe.
- Peça um documento curto sobre um problema real seu. Produto é trabalho de escrita e fala não testa isso.
- Não faça pergunta de estimativa maluca nem enigma. Medem compostura sob pressão artificial e correlacionam mal com julgamento de produto.
- Use a rodada gravada especificamente para as perguntas de discordância. Como a pessoa narra discordar de alguém sênior é quase amostra de trabalho.
- Contrarie ao vivo na rodada final. PM que não sustenta posição diante de um entrevistador não vai sustentar diante de um stakeholder.
Rodar isso numa pilha grande de inscritos é onde a conta cresce. A VoxScreen manda essas perguntas num link só, transcreve e avalia cada resposta pelos critérios que você definiu e devolve a lista ranqueada — de graça para 50 candidatos por mês, sem cartão.
Erros comuns ao contratar para esta vaga
- Entrevistar sobre funcionalidade entregue. Todo mundo tem, e depende muito do time e do mercado que a pessoa recebeu.
- Não perguntar sobre o que foi matado. Roadmap falha por acúmulo, e a capacidade de remover é mais rara e mais valiosa que a de adicionar.
- Usar enigma de estimativa. É proxy ruim de julgamento e seleciona quem treinou o formato.
- Pular a amostra de escrita. A maior parte das decisões de produto é transmitida por escrito, e resposta gravada testa outra habilidade.
- Confundir confiança com julgamento. A função premia acertar, não soar certo, e entrevista premia sistematicamente a segunda.
Perguntas frequentes
O que perguntar para um product manager?
Comece por algo que a pessoa matou e como contou para quem estava investido. Depois pergunte o que faz quando alguém sênior quer uma funcionalidade que ela acha errada, como decide com evidência fraca, e o que está no roadmap dela só porque alguém importante quer. Essas quatro testam recusa, evidência e franqueza.
Entrevista de PM deve ter pergunta de estimativa ou enigma?
Não. Elas medem compostura sob pressão artificial e treino no formato, não julgamento de produto, e os melhores candidatos recusam cada vez mais processos montados em cima disso. Um documento curto sobre um problema real dá muito mais sinal sobre como a pessoa realmente pensa.
Como separar PM bom de PM confiante?
Pergunte o que ele matou e o que está no roadmap só por motivo político. Confiança se sai bem nas duas e franqueza não vem naturalmente em nenhuma. PM que consegue citar uma decisão ruim que tomou e um acordo que está no plano dele está mostrando o julgamento que confiança normalmente substitui.
Rodada gravada serve para product manager?
Para as perguntas de discordância, sim: como a pessoa narra ter discutido com um stakeholder sênior é quase amostra de trabalho e é difícil de ensaiar. Junte um exercício escrito, porque decisão de produto é transmitida por escrito e é esse o artefato com que o seu time vai conviver.