Conteúdo originalmente publicado aqui.
Este post faz parte de uma série sobre como se preparar para um processo seletivo de Gerente de Produto. Confira a série completa:
- Em busca do emprego ideal
- Encontre e seja encontrado
- Avaliação de fit cultural – RH ou time
- Avaliação técnica — entrevistas ou cases
Existe uma sensação extra de frustração em ser reprovado na etapa de avaliação técnica.
Se a reprovação por fit cultural pode ser subjetiva, a insuficiência técnica tende a não ser, ou ser bem menos.
Exceto em casos de pessoas muito fora da curva, a falta de afinidade cultural é apenas um detalhe. Significa que a empresa procura uma pessoa mais competitiva (ou menos), mais formal (ou menos) etc. — e como eu mencionei antes, não adianta forçar a barra para ser alguém que você não é, apenas para conquistar um emprego que talvez vá lhe trazer mais problemas depois, pela falta de afinidade de estilo.
Por outro lado, ser reprovado na etapa técnica traz aquela sensação de que “deveria ter me preparado melhor”, “deveria ter me dedicado mais”, “deveria ter estudado”.
E deveria mesmo.
Sempre fico decepcionado de entrevistar candidatos ou avaliar provas de pessoas que visivelmente não estudaram para estar ali.
Por isso, neste artigo vou dar algumas dicas sobre:
- Como se preparar para a etapa de avaliação técnica
- Os 3 tipos mais comuns de cases para avaliação técnica
- Dicas para resolver os cases
- Como apresentar cases
- Dicas finais de entrevistas técnicas
1. Como se preparar (ou “o que eu avalio?”)
Tem duas coisas importantes para avaliar na etapa técnica:
- Nível de conhecimento
- Experiência prática
Idealmente, eu gostaria de saber o seu nível de conhecimento a respeito de:
- Mercado em que o produto está inserido (modelos de negócio, principais players)
- Desenvolvimento ágil (processos, técnicas, práticas)
- Técnicas de discovery (investigação de problemas e oportunidades, entrevistas exploratórias ou delimitadas, como lidar com problemas complexos)
- Técnicas de desenho de solução (levantamento de hipóteses, testes e validações)
- Técnicas de análise de dados quantitativos (estatística básica, interpretação dos dados)
- Técnicas de priorização
- Negócios (cálculo de ROI, desenho de modelo de negócio)
- Gestão de stakeholders (negociação, administração de conflitos, buy-in, storytelling)
- Habilidades comportamentais (empatia, visão sistêmica, curiosidade, abertura a críticas, honestidade intelectual)
Além disso, eu quero saber disso tudo o que você tem de experiência prática: que técnicas já aplicou, como aplicou, o que aprendeu, o que faria diferente.
É claro que o grau de exigência muda conforme a senioridade da vaga. Mas resumidamente, é isso.
Dá para estimar que eu demoraria alguns meses para avaliar qualquer candidatura.
Como isso é completamente inviável (por favor, recrutadores, nem tentem), é preciso priorizar!
Toda etapa de avaliação técnica de PM de que já participei — como contratante ou candidato — avaliou alguns desses critérios por meio de cases, entrevistas ou sabatinas. A aposta é que se o candidato resolve bem o case e/ou responde bem às perguntas, está apto a desempenhar a função de Product Manager.
Se você é uma pessoa interessada e dedicada em aprender mais sobre gestão de produto, idealmente você já está se preparando para qualquer avaliação técnica mesmo que não esteja em um processo seletivo específico. O aprendizado constante é essencial para PMs.
Por isso, deixe para estudar “de última hora” apenas aquilo que for específico da empresa que está contratando: modelo de negócio, tendências do mercado etc. O restante eu espero que você já venha estudando há algum tempo — e, dependendo das exigências da vaga, aplicando à prática também.
Mas o que eu realmente quero ver…
…é qual o seu maior ponto forte e se eu preciso dele para a vaga que tenho aberta.
E aí, não tem muito “gabarito” de avaliação técnica. No máximo, você pode pegar a lista acima e realizar uma autoavaliação. Quais seus pontos fortes dali? Onde você já aplicou aquelas coisas? Qual foi o resultado? O que precisa estudar mais?
Sua carreira deveria ser um preparo constante para o próximo case. Porque afinal, todos os dias você está trabalhando em um case de produto.
2. Estilos de cases
A primeira dica e a mais importante é: preste muita atenção em tudo que é pedido no case e não deixe de responder / entregar nada.
Já fiz e corrigi muitos cases e acredito que existem 3 estilos:
- “Entenda o contexto, proponha algo.”
- “Como podemos resolver tal problema?”
- “Dados, dados, dados”
Vamos a cada um deles:
“Entenda o contexto, proponha algo”
Cases de empresas B2B cujo produto não possui free / trial geralmente vão precisar passar um pouco mais de contexto para você resolver o case. Geralmente explicam o que é o produto e algo breve sobre o mercado.
Dicas para obter mais informações:
- “Varrer” o site da empresa;
- Se encontrar cases no site, veja todos que puder;
- Procurar vídeos do produto no YouTube;
- Fazer tudo isso acima nos sites dos concorrentes.
Diante de tudo isso, é natural que você tenha que simular um processo de discovery, portanto vai ter que inventar algumas verbalizações de clientes ou algum dado quantitativo que faça certo sentido no contexto. Isso é parte do roleplay e totalmente esperado se o case pede que você “simule um discovery” ou algo assim.
Esse tipo de case é particularmente difícil tanto para quem faz quanto para quem avalia.
Como avaliador, não tenho expectativa de ver uma grande novidade no case. A ideia pode ser ruim, mas se a hipótese foi bem construída, está ótimo!
Sei bem que a pessoa não tem tanto contexto e dificilmente vai surgir com uma ideia que nós já não tivemos. O que eu avalio aqui é a capacidade da pessoa “se virar com o que tem”, correr atrás e ser capaz de tomar decisões com dados limitados. É igual fazer produto!
São cases que avaliam principalmente a sua forma de pensar.
“Como podemos resolver tal problema?”
Cases de empresas B2C geralmente não dão muito contexto do produto e do(s) problema(s).
Como você tem fácil acesso ao produto, talvez até já o utilize, a empresa vai entender que é seu papel correr atrás do máximo de informações que puder.
Aqui eu não sou muito fã de simular dados. Prefiro trabalhar só com dados reais e extrair dali as informações para construir meu caso.
Se você achar que deve fazer uma SWOT, por exemplo, certifique-se de usar Oportunidades e Ameaças reais, mesmo que pelo seu ponto de vista. O mesmo para Forças e Fraquezas: procure defini-las por engenharia reversa, não por mera simulação.
O ponto é que esse tipo de case dificilmente estará avaliando apenas a sua forma de identificar problemas e propor hipóteses de solução. Como você tem mais contexto do que é o produto e como ele funciona, é bom trazer boas ideias, que façam sentido na realidade.
Mais do que a sua maneira de pensar, esses cases avaliam também a qualidade das suas propostas. Quem está corrigindo seu teste deveria pensar algo como “faz sentido, eu me vejo implementando algo assim no produto”.
“Dados, dados, dados”
Alguns cases vão te dar um problema curto e bem definido e um monte de planilhas com dados de todo tipo para você analisar.
É comum em cases de empresas que competem por transações, especialmente e-commerces e marketplaces. Produtos assim precisam fazer análises constantes de funil, para entender onde a taxa de conversão precisa ser otimizada, e de correlações entre métricas.
Mesmo com a popularização dos cientistas de dados em times de produto, tais empresas não podem se privar de PMs que entendam muito de análise de dados e experimentações (principalmente Testes A/B).
Em muitos casos, os dados não são realistas, pois a empresa não vai se expôr. Independente disso, o seu case precisa ser consistente com os dados que lhe foram oferecidos. Inclusive não é incomum os dados terem inconsistências. Na vida real, eles vão ter. Por que não teriam no case também?
O que eu avalio em cases assim é se a pessoa sabe o que procurar quando está diante de uma planilha gigante. Sabe fazer perguntas aos números? Tem a capacidade de transformar esses dados em algo visual que permita tomar decisões bem embasadas?
Quero ver algo que me deixe confiante de que a pessoa vai tomar decisões bem embasadas.
Em uma apresentação, é possível que eu pergunte algo como: “O que você queria com esse gráfico? No que estava pensando? Qual era a sua pergunta?”
3. Dito isso, vamos às dicas que valem para os 3 tipos de cases…
Construa uma história com “começo, meio e fim”.
Eu quero — ou melhor, eu preciso — saber se você entendeu o que está acontecendo e sabe explicar. Construa bem a história. Faça uma boa transição de problema (ou oportunidade) para solução (ou experimentação / intervenção).
Suas conclusões precisam começar a ser construídas desde as primeiras frases. Coesão é a palavra chave aqui.
Você não precisa usar o case para mostrar tudo que você sabe fazer e fez. Já avaliei cases que quase metade dos slides eram gráficos que não provavam ponto algum e sequer eram utilizados para embasar as hipóteses propostas de solução.
Se não faz sentido, corte. No máximo, se estiver com dó de cortar, reserve um slide para “hipóteses descartadas” e mostre os “becos sem saída” que você encontrou durante o estudo.
Demonstre que entendeu muito bem o problema.
Quem tem o problema? Quando ele aparece? Qual o contexto que faz com que ele apareça? Qual impacto ele causa quando aparece?
Quais as causas do problema? Qual a real necessidade do cliente? Como ele resolve o problema atualmente?
Por que ele é um problema? Por que você entende que deveríamos resolvê-lo?
Tenha clareza sobre esses questionamentos.
Eu sei, é um case. Você fez em algumas horas durante a noite. Vá até onde for possível. O seu julgamento de “até onde era possível” também pode estar sob avaliação.
Proponha uma ou mais hipóteses que façam sentido para resolver o problema.
De novo a questão da transição do problema para a solução.
Já avaliei alguns cases que tinham propostas de solução que não eram necessariamente ligadas ao problema identificado. A impressão que dá é que você pensou primeiro em uma solução “legal, criativa, inovadora” e depois ficou tentando achar um problema para embasá-la.
Obviamente, se você fizer isso no dia a dia como PM, vai ser uma catástrofe.
Use o tipo certo de gráfico ou tabela.
Linhas para valores que têm continuidade. Barras para comparações entre séries. Gráficos “pizza” para proporções. Funil para etapas sucessivas. Coortes para… coortes!
Não precisa inovar tanto aqui. Sua prioridade é que o leitor entenda o que você está dizendo com aquele gráfico.
Deixe claro o que você não sabe.
É um case, portanto vão lhe faltar muitas informações para tomar decisões de qualidade.
PMs precisam ter honestidade intelectual: reconhecer o que sabem e o que não sabem, ter clareza sobre o grau de certeza que têm sobre uma certa informação.
Desconfio de quem chega cheio de certezas.
Deixe claro onde você buscaria a informação que lhe falta.
Se você deixar claro o que não sabe, eu obviamente vou lhe perguntar onde você buscaria a informação que falta.
Pode se adiantar e deixar isso evidente logo no case: “não sabemos tal coisa, provavelmente uma consulta no banco de dados resolveria essa dúvida”.
Esqueça as buzzwords e os frameworks.
Recebi um case uma vez que, em 10 ou 12 slides, citava uns 6 frameworks diferentes.
Nem vou entrar no mérito de que estavam sendo utilizados, em sua maioria, da maneira errada.
Meu ponto é que você não precisa dizer que conhece os frameworks da moda. Se você aplicar só um deles e muito bem, nem precisa citar o nome. Provavelmente quem está avaliando já conhece.
4. Apresentação de cases
Eu gosto da etapa de apresentar o case para o time. Ela me permite avaliar melhor o storytelling, a capacidade de conquistar buy-in e o domínio do tema.
Às vezes a entrega do case já é uma apresentação, mas na maioria dos casos, você primeiro entrega, depois marca a apresentação.
Pessoalmente, sou pouco impactado por formatos mega inovadores de apresentação. O que eu sempre considero é a formatação do documento e dos slides: alinhamento, tamanho de fonte, erros de digitação etc. O mínimo de atenção é esperado de qualquer PM.
Você pode não ter habilidades de roteiro, postura de palestrante, oratória exemplar e tudo mais. Pode até demonstrar nervosismo e timidez. Isso não desqualifica.
Só tem duas coisas que importam aqui:
- Demonstrar domínio do tema estudado durante a apresentação.
- Demonstrar domínio do tema estudado durante as perguntas.
Se você estudou aquilo, se você se dedicou, isso vai ficar evidente na apresentação.
Eu quero terminar com a sensação de que “essa pessoa sabe do que está falando”.
Liderando PMs, eu raramente cobro que saibam “por que não estamos fazendo tal coisa”. Mas é obrigatório saber “por que estamos fazendo o que estamos fazendo”. E espero uma resposta bem embasada. Você estudou aquilo, pô! Tem que saber!
Vale o mesmo para processo seletivo. Saiba do que você está falando! E vice-versa: fale do que você sabe!
Eu certamente vou fazer perguntas sobre pontos específicos do seu case. Alguns exemplos reais:
- Você afirmou “tal coisa”. O que te levou a pensar isso?
- Se ao final dessa apresentação eu dissesse que ainda não estou convencido, o que você faria para provar seu ponto? Por onde começaria?
- Você diz que usaria de “entrevista com o cliente” para obter essa informação. Finge que eu sou um cliente agora. Pode me perguntar o que você quiser. (E aí engato uma breve simulação de entrevista para ver como a pessoa entrevista um cliente.)
- Por que você acredita que isso é um problema?
- Se sua hipótese se comprovar, qual será o próximo passo?
- (Para uma solução que envolva serviço / tarefa manual / etc.) Como você faria para operacionalizar algo dessa magnitude?
- (Para uma solução que pareça muito grande) Se o time disser que vai levar X meses para implementar essa ideia e eu te disser que X meses é tempo demais, o que você faria?
- Supondo que temos pouco tempo para começar a provar valor, como você dividiria sua proposta de solução em fases?
Essas perguntas serão para avaliar sua forma de pensar. Todas elas são baseadas em ocorrências reais da vida de PMs.
O que eu espero é que você demonstre algumas das características que mencionei no início deste artigo.
5. Entrevistas técnicas
Costumo reservar metade da entrevista para a apresentação do case e a outra metade para uma avaliação técnica, com perguntas não relacionadas ao case.
Eu não tenho um roteiro específico para essa etapa. Ao longo do processo, fui formando uma opinião sobre o candidato e quando chega neste ponto, já sei mais ou menos o que explorar.
Certamente vou fazer perguntas sobre suas experiências reais a respeito de algo da lista que fiz no início do artigo. Alguns exemplos reais de perguntas que já utilizei:
Mercado em que o produto está inserido.
- Como você enxerga esse mercado?
- Se tivesse que fazer uma previsão para ele, diria que está indo por qual caminho?
- Você acha que tal player vai dominar tudo?
Desenvolvimento ágil
- Quais práticas ágeis você costuma usar no dia a dia?
- Quais você já tentou usar e não gostou ou não teve o resultado esperado?
Técnicas de discovery
- Se eu colocar você em um time recém-criado, por onde você começa?
- Que técnicas de discovery você conhece? Quais já usou?
- Como você costuma compilar os dados das entrevistas realizadas?
Técnicas de desenho de solução
- Conte sobre um experimento que você realizou.
- Como você costuma validar se a solução proposta de fato entrega o valor que você imagina?
Técnicas de análise de dados quantitativos
- Conte sobre algumas métricas que já ficaram sob sua responsabilidade. O que você fez para melhorá-las?
- Como você mede engajamento no produto que gerencia atualmente? Que outras métricas e técnicas conhece para isso? Quais já usou?
Técnicas de priorização
- Que técnicas de priorização já utilizou?
Gestão de stakeholders
- Conte sobre uma evolução de produto que envolveu muitas áreas da empresa. Como você gerenciou isso? Que dificuldades enfrentou? Como tentou resolvê-las?
Como deixei bem claro no início do artigo, é impossível avaliar tudo isso de uma vez.
O que eu não vou fazer: explorar um ponto fraco seu. Porque, de novo, eu quero contratar você pelo que você tem de melhor, não por ausência de falhas.
Então, primeiro vou priorizar a avaliação de pontos que são importantes para a minha empresa e para o contexto da vaga que eu quero preencher.
Depois, vou priorizar a avaliação de pontos sobre os quais eu não consegui formar uma opinião até aquele momento do processo seletivo.
Tudo isso em uma hora de entrevista.
É pouco? Sim.
É subjetivo? Bastante.
Por isso, não desanime se você não passou! Peça feedbacks e procure fazer uma autoavaliação nos pontos do feedback recebido. Onde pode melhorar? Como?
Essa capacidade de avaliar suas próprias limitações e trabalhar nelas vai fazer toda a diferença na sua carreira, como fez na minha!
Com este artigo, encerro minha série sobre processos seletivos.
Longe de ser um “guia” ou um “passo a passo”, procurei reunir um pouco da minha experiência participando de processos seletivos ou avaliando candidaturas.
Talvez você siga tudo isso e ainda não passe no processo. Talvez seus avaliadores pensem completamente diferente de mim.
Mas como disse no início, meus objetivos eram:
- Auxiliar as pessoas a encontrar empregos que satisfaçam suas necessidades pessoais e de carreira.
- Auxiliar empresas a melhorar seus processos seletivos para preencher suas vagas com profissionais capacitados
Espero ter conseguido.
Obrigado pela leitura e pela paciência!
Mais conteúdos que você pode se interessar:
