Entrevistas de product manager sondam o pensamento de produto, a familiaridade com métricas, e como você decide o que não construir. Aqui estão as perguntas mais comuns com respostas modelo. Junior: teoria básica, definições e casos práticos simples.
Um projeto tem um fim definido — um escopo, uma data, e um momento em que é entregue. Um produto continua, e seu sucesso é medido depois da entrega por se as pessoas continuam usando. A consequência são perguntas diferentes: um projeto pergunta se foi lançado no prazo, um produto pergunta se lançá-lo mudou alguma coisa.
O product manager decide o que deveria ser construído e por quê; o project manager garante que o trabalho acordado seja entregue. Um é dono do resultado, o outro é dono do plano. Em times pequenos a mesma pessoa faz ambos, o que é ok até os dois objetivos entrarem em conflito — e entram, toda vez que um prazo esbarra em uma descoberta de discovery.
É uma declaração de intenção sobre problemas e sua ordem, útil porque deixa todo mundo planejar em torno dele. Não é um compromisso com datas e features para um ano — um roadmap tratado como contrato transforma discovery em teatro, porque nada que se descubra pode mudar algo. A versão honesta tem menos certeza quanto mais longe vai.
O menor produto que testa se a suposição se sustenta. É confundido com uma versão barata do produto completo, por isso times lançam algo incompleto, não aprendem nada, e prejudicam a marca no processo. A pergunta que mantém isso honesto é o que você faria diferente dependendo do resultado — se a resposta é nada, não vale a pena construir.
ARPU é a receita média por usuário em um período; LTV é a receita total esperada de um cliente durante todo o relacionamento, menos o que custa atendê-lo. ARPU pode parecer saudável enquanto o LTV está caindo, porque ARPU não diz nada sobre quanto tempo as pessoas ficam. LTV é o número que decide quanto você pode gastar para adquirir alguém.
Decidindo antes do lançamento o que contaria, depois revisando adoção, retenção dessa adoção, e a métrica de resultado que ela deveria mover. Uma feature pode ser amplamente usada e ainda ser um fracasso se canibaliza um fluxo melhor ou eleva o volume de suporte. Escolher a métrica depois de ver os dados é como tudo parece um sucesso.
É o trabalho de descobrir se o problema é real, se a solução o resolve, e se vale a pena fazer — através de entrevistas, protótipos, dados. Vem primeiro porque construir é a forma mais cara de aprender, e porque um time que pulou isso vai descobrir as mesmas coisas depois do release, tendo pagado por elas.
Numa entrevista de verdade você fala sob pressão. O Cam faz essas mesmas perguntas, avalia cada resposta e mostra exatamente o que melhorar.
Praticar entrevista de Junior Product Manager →