Entrevista de Product Owner: priorize um backlog e defenda suas decisões

Na entrevista de Product Owner, “eu uso uma matriz de priorização” é apenas o começo da resposta. Explique qual problema merece atenção, o que ficaria para depois e como você avaliaria o resultado.

Proposta editorial: defenda uma ordem de backlog ligando objetivo, evidência, dependências e custo da escolha. O caso deste artigo é original e fictício: um produto por assinatura que ajuda cafeterias a montar escalas de trabalho. Dados, estimativas e falas foram criados para prática; não são relatos de candidatos nem informações de uma empresa real.

Base oficial: usamos o Scrum Guide para delimitar responsabilidades e qualidade, e materiais do Scrum.org para discutir resultados. A ordenação e os critérios do caso são sugestões de raciocínio, não um método obrigatório do Scrum ou uma previsão da sua entrevista.

Comece por How would you prioritize and test features? no PracHub. Antes de escolher uma fórmula, diga qual decisão você precisa tomar e qual resultado ela pretende melhorar.

Delimite a responsabilidade antes de prometer uma entrega

Fato oficial: no Scrum Guide, o Product Owner responde por maximizar valor e pela gestão eficaz do Product Backlog, incluindo objetivo, comunicação e ordenação. Os Developers são responsáveis pelo dimensionamento do trabalho e pelo plano de execução. Isso não transforma o PO em distribuidor individual de tarefas técnicas.

Na entrevista, você pode escolher a investigação e explicar a prioridade sem determinar sozinho quanto cabe ou como a solução será construída. Uma resposta coerente convida engenharia e design a esclarecer riscos, preservando a responsabilidade pela escolha de produto.

Se a empresa não trabalha com Scrum, confirme o significado do cargo naquele contexto. Aqui usamos suas responsabilidades como referência explícita; não presumimos que todas as vagas de PO adotem os mesmos eventos, ferramentas ou poderes de decisão.

Defina um resultado antes de olhar a lista de pedidos

Caso fictício: novas cafeterias criam uma conta, mas muitas não publicam sua primeira escala. O objetivo de produto é aumentar a proporção de novas contas que chega a esse primeiro valor, sem piorar erros de dados ou a necessidade de suporte.

A pergunta inicial seria: “Publicar uma escala significa que a pessoa conseguiu organizar o trabalho, ou apenas clicou em um botão?” No exercício, definimos uma publicação válida como uma escala salva e publicada para ao menos um turno, com pessoa responsável e período válido. Essa definição é uma escolha do caso, não uma métrica padronizada do mercado.

O guia de Evidence-Based Management orienta a atenção a resultados e valor. Aplicação editorial: concluir três funcionalidades não demonstra, sozinho, que mais clientes alcançaram o resultado. Precisamos observar o comportamento que a entrega deveria facilitar.

Use este contrato de métrica original:

Na coorte fictícia madura, há 1.000 contas elegíveis e 300 publicações válidas: 30%. Outras 100 contas clicaram em “publicar”, mas a operação falhou. Somar esses cliques ao numerador produziria 40%, descrevendo um resultado diferente do que queremos medir.

Há ainda 450 contas recentes sem sete dias completos. Incluí-las agora no denominador reduziria artificialmente a comparabilidade. Você pode acompanhar seu progresso separadamente, mas não misturá-las silenciosamente à coorte madura. O total de cadastros não substitui a janela de observação definida.

Ordene cinco itens com evidência e dependências visíveis

Suponha que a equipe tenha uma previsão inicial de seis dias de trabalho disponíveis para este recorte, sujeita a refinamento. Dias aqui são estimativas fictícias fornecidas pelos Developers, não uma conversão universal de pontos nem uma promessa do PO.

Ordem editorial inicial: B, A, C, D, E. B vem antes porque a leitura atual confunde resultado e intenção. A tem uma barreira concreta e precisa ser validado com quem falhou. C oferece um teste pequeno da etapa seguinte. D e E continuam visíveis; adiar não significa declarar que nunca terão valor.

A soma B+A+C é seis dias nas estimativas iniciais. Isso não garante que os três itens caberão ou que geram a maior receita possível. A equipe precisa refinar o recorte, riscos e qualidade antes de assumir uma previsão. Também pode haver trabalho de medição realizado em paralelo; a ordem comunica a lógica, não uma atribuição rígida de pessoas.

O dado de 120 contas não é uma promessa de 120 novas ativações. Algumas poderiam abandonar por outras razões. Para sustentar a hipótese de A, procure a reprodução do erro e o que essas pessoas tentaram fazer depois. Para C, confirme se a dificuldade observada é comum no segmento escolhido.

Defenda por que um número de prioridade não resolve tudo

Uma pontuação pode ajudar a explicitar pressupostos. Ela não torna verdadeiros alcance, impacto ou esforço que foram apenas estimados. No caso, dar uma nota alta a D porque “o cliente é grande” esconderia a falta de confirmação do compromisso comercial.

Você pode dizer: “Eu compararia impacto no objetivo, evidência, risco e dependências. Usaria uma pontuação como apoio se as entradas forem compreensíveis, mas preservaria as razões e as incertezas de cada item.” Essa resposta mostra como o método apoia a decisão.

Pergunte também o que acontece se nada for feito. Um erro conhecido que impede a primeira escala pode ter um custo diferente de uma melhoria visual. Por outro lado, um compromisso contratual real e próximo poderia mudar a escolha. É necessário confirmar esse fato, não supô-lo para agradar a vendas.

Mostre também o custo da alternativa: reservar quase toda a capacidade para D deixaria pouco espaço para reparar a barreira observada e a medição. Esse é o custo da opção, mesmo que exista uma oportunidade comercial legítima.

Recorte a importação até um comportamento que possa ser conferido

Uma história como “melhorar importação” deixa várias interpretações abertas. No exercício, o recorte de A é permitir mapear as colunas nome e identificador de equipe de um CSV, revisar erros e só então confirmar uma importação válida. Engenharia define a implementação com as restrições relevantes.

Estes são critérios originais para discussão, não regras universais de importação:

A regra de recusa integral é uma escolha de produto deste caso. Outra equipe poderia preferir importação parcial, mas teria de tornar claras as linhas aceitas, recusadas e o comportamento ao tentar novamente. Não deixe essa decisão escondida no código.

O último critério depende de identificar a mesma operação e preservar seu resultado. Pergunte à equipe como essa fronteira será garantida, inclusive em requisições concorrentes ou falhas. Não declare idempotência comprovada apenas porque o botão foi desabilitado na tela.

Fato oficial: o Scrum Guide exige que o Increment atenda à Definition of Done. Aplicação ao exercício: critérios específicos do item não substituem o padrão de qualidade do produto. A equipe também precisa verificar integrações e outros requisitos acordados, mesmo que a prévia pareça correta.

Responda a vendas e suporte sem simular consenso

Considere esta conversa fictícia antes do planejamento:

Vendas: “O prospect quer a marca dele na próxima apresentação. Podemos colocar a personalização primeiro?”

PO: “Qual é o compromisso confirmado, a data e a consequência de não entregar? Hoje priorizei a primeira escala e a correção de uma barreira observada. Se houver um compromisso comercial verificável, comparo esse custo com o adiamento da importação. Sem essa confirmação, mantenho a ordem e proponho uma demonstração com o produto atual.”

A resposta não promete que uma demonstração atende à necessidade; oferece uma alternativa a validar. Também não desqualifica vendas. O objetivo é tornar a informação que poderia mudar a decisão acessível.

Agora suporte pergunta: “Os clientes ativos estão esperando o relatório. Por que E ficou por último?” Você pode responder: “Neste recorte, o objetivo é a primeira escala. Vamos dimensionar a frequência e o impacto do pedido de relatório para comparar com os próximos objetivos. Não quero usar a dúvida sobre sua demanda como justificativa para esquecê-la.”

Não é preciso obter concordância de todos para ter uma decisão clara. Registre a preocupação, a escolha e a condição de revisão. Prometer “no próximo Sprint” sem uma previsão viável apenas adia o conflito.

Mostre o que faria você alterar a ordem

A ordem depende das evidências deste caso. Se a reprodução mostrar que o erro de importação foi atribuído a uma configuração externa já corrigida, a evidência para A muda. Se a maioria das contas afetadas pertence a um segmento fora do objetivo atual, o alcance relevante também muda.

Se B revelar que a métrica anterior estava errada, não apresente a nova taxa como melhora causada pela entrega. Uma correção de instrumentação pode alterar a medição sem alterar a experiência. Preserve as duas definições e reconcilie os dados antes de comemorar.

Imagine que, depois de uma entrega, outra coorte madura tenha 360 publicações entre 1.000 contas elegíveis: 36%. A diferença observada é de seis pontos percentuais, não de seis por cento. Ela não prova que A ou C causou o aumento; composição de clientes, campanha e sazonalidade podem ter mudado.

Os materiais de Product Metrics do Scrum.org relacionam medidas ao valor e à inspeção das decisões. Recomendação editorial: combine um desenho de avaliação adequado com análise das proteções. Um experimento bem planejado pode ajudar quando for viável; uma comparação antes/depois sem controle exige limites explícitos.

Na entrevista, diga o que faria se a publicação aumentasse e os chamados também. Você investigaria gravidade, concentração e mecanismo antes de decidir ampliar, ajustar ou interromper o recorte. Um indicador principal positivo não elimina efeitos indesejados.

Prepare uma conclusão que outra pessoa consiga revisar

Um registro curto do caso poderia conter: objetivo de primeira escala em sete dias; métrica por conta e coorte madura; ordem B-A-C-D-E; hipótese de barreira na importação; recorte de validação integral; previsão sujeita a refinamento; D condicionado à confirmação comercial; revisão após evidência de uso e qualidade.

Esse registro permite discordar de uma premissa específica. “A deveria vir depois porque as 120 contas não são do segmento alvo” é uma discussão melhor do que “minha demanda é mais importante”. A decisão ganha qualidade quando suas condições ficam visíveis.

Fato oficial: no Scrum Guide, o escopo pode ser esclarecido e renegociado conforme o aprendizado, sem colocar o Sprint Goal em risco nem reduzir qualidade. Não use “agilidade” para prometer mudanças ilimitadas ou tratar a previsão como um contrato imutável.

As questões abaixo têm contextos próprios e servem para prática. Não são uma lista confirmada de perguntas para uma empresa, nem indicam que Product Owner e Product Manager são cargos equivalentes em todas as organizações.

Pratique priorização e teste de funcionalidades apresentando a ordem em voz alta. Acrescente uma evidência nova e explique qual decisão muda, qual permanece e o custo da revisão.

Sources and Further Reading

• Scrum Guide: responsabilidades, backlog, qualidade e adaptação
• Scrum.org: Evidence-Based Management Guide
• Scrum.org: Product Metrics