Falha 2 — demo sintética vendida como cliente real

Sintoma: “clientes aceitaram 81,8% das sugestões”. O PE06 tem esse percentual em fixture sintética, não clientes. Uma palavra trocada muda a classe da evidência. Uma demo com colegas ou dados fabricados pode verificar apresentação e parser; não valida demanda ou utilidade no turno de suporte.

Causa: falta de rótulo no número e pressão para mostrar tração. A solução não é esconder toda medição. É preservar denominador, população e contexto no ponto da afirmação. Se o percentual vem de 14 tickets de fixture, diga isso. Se o dado falta, escreva “não medido” e desenhe o protocolo que permitiria medi-lo.

Resposta: registrar claims em claims.json, manter external_outcome vazio até existir fonte verificável e testar a fixture inválida. O checker rejeita “clientes reais ficaram 30% mais produtivos” sob local_measurement, inclusive pela falta de denominador/janela. Ele pode ser enganado por um arquivo falso; por isso revisão humana, autorização e proveniência continuam parte do gate. Essa limitação deve estar no próprio portfólio, não escondida na implementação do checker.

Falha 3 — carreira reduzida a prompts

Sintoma: o profissional mostra um catálogo de prompts e versões de modelos como se a quantidade provasse capacidade de produto. Prompts podem acelerar escrita ou código; não definem qual ticket deve ser priorizado, qual risco merece um no-go, quem atende incidente ou se comprador aceita custo.

Causa: ferramentas geram output visível mais rápido que discovery, negociação e operação. A página da PostHog sobre product engineers descreve como aquela empresa espera participação em suporte, roadmap e experiência. É uma prática declarada de uma empresa, não uma norma universal nem uma promessa de carreira. O DORA 2025 descreve IA como amplificadora das forças e fraquezas de um sistema organizacional; a página de resumo não autoriza inferir que uma pessoa com mais prompts terá salário ou produtividade maior.

Resposta: mostrar o que o prompt não decide. No DeskPilot, um teste de RLS, o restore como papel de aplicação e a matriz no-go são mais informativos que o texto que gerou o primeiro rascunho. Saber usar IA continua útil; a competência demonstrada é pedir evidência, corrigir desvio e assumir o limite do sistema que a ferramenta ajudou a construir.

Falha 4 — acumular cargos sem limites

Sintoma: “Product Engineer faz PM, design, suporte, segurança, jurídico e engenharia.” A frase pode soar autônoma, mas transforma colaboração em carga ilimitada e dilui quem decide valor, usabilidade, operação de dados e orçamento. Um indivíduo sem acesso a usuários ou poder de decisão não resolve essa lacuna por esforço pessoal.

Causa: confundir responsabilidade por entender o produto com autoridade sobre todo o produto. O SVPG contrasta equipes focadas em output com equipes orientadas a problemas e outcomes. É um framework autoral; nele PM, design e engenharia colaboram e enfrentam riscos diferentes. Seu uso aqui é lembrar que engenharia precisa participar da decisão, não substituir especialistas por padrão.

Resposta: negociar interfaces de trabalho. PM abre a pergunta de valor, priorização e acesso a participantes. Design conduz observação de uso e linguagem da UI. Engenharia responde por factibilidade, instrumentação, testes e reversão. Suporte ensaia incidente; segurança/legal revisam dados e finalidade; liderança define teto e responsável pelo risco. Em equipe pequena, pessoas podem acumular funções, mas o acordo deve nomear tempo, decisão, revisão e limite. Autonomia significa poder propor e interromper com evidência, não ser dono solitário de tudo.

Uma matriz de competências sem número mágico

A matriz CSV enumera dez áreas: discovery, domínio, UX, engenharia, IA/eval, analytics, economia, operação, comunicação e influência. Cada linha descreve comportamento inicial, comportamento em prática, evidência do DeskPilot e lacuna que pede feedback. Ela não atribui nota de 0 a 10 à pessoa. Um número único sugeriria precisão que a série não tem.

Observe a linha de UX: o artefato existe, mas a tela não renderiza a sugestão. A célula de evidência não deve dizer “domínio de UX”; deve indicar o gate bloqueado e a revisão com design/agente ainda necessária. A linha de operação registra restore local e runbook, ao lado de alertas duráveis e operador real pendentes. Essa forma permite que uma pessoa em início de carreira mostre aprendizado real sem alegar senioridade por decreto.

O comportamento também muda com contexto. Júnior pode formular uma hipótese e testar um caso com mentoria; pleno/sênior pode fechar um gate de ponta a ponta e negociar suporte; staff pode desenhar guardas reutilizáveis sem virar aprovação central; consultoria precisa separar comprador, operador e cliente final e obter acordo de dados antes de testar. A mesma evidência do DeskPilot não vale da mesma forma para todas as vagas. Mostre quem tomou qual decisão, não apenas que a tarefa apareceu no repositório.

Plano 30/60/90: entregas, responsáveis e feedback

Nos primeiros 30 dias, audite o case: para cada afirmação, há path? A medição tem denominador, janela e ambiente? O trabalho de discovery tem pessoa real autorizada ou somente roteiro? Peça a PM crítica da hipótese de valor, a design crítica da tarefa e a suporte exceções do fluxo. A entrega observável é um problema formulado com alternativas e um registro honesto do acesso disponível. Sem acesso, a entrega é protocolo pendente, não entrevista inventada.

Nos 31–60 dias, feche gates técnicos necessários ao piloto: custo faturado e reconciliação, operação de dados reais, UI de revisão e consentimento. A responsabilidade não cabe em um nome só. Engenharia mede e corrige; segurança revisa threat model; design testa compreensão; suporte executa runbook. Se qualquer gate falhar, a saída é pausa com dono e próxima verificação. O marco não é “lançar porque o calendário chegou ao dia 60”.

Nos 61–90 dias, somente com gates fechados e autorização, PM recruta participantes opt-in; engenharia e design observam o fluxo; suporte recebe reclamações; a equipe compara com o baseline manual e usa critérios de parada. Se isso não puder ocorrer, registre “piloto não executado” e escolha outra evidência obtível. A versão detalhada do plano inclui quatro contextos de carreira e quem dá feedback em cada janela. Nenhum prazo promete promoção ou contratação.

O próximo produto pode exigir menos IA

O case DeskPilot ensina a mudar o desenho conforme usuário e risco. Em produto interno, o agente interno quer menos retrabalho e pode tolerar sugestão revisável com fallback manual, mas dados e processo ainda têm dono. Em growth, clique ou aceite é proxy perigoso: o outcome é ativação útil com guardrail de retenção, e automação de mensagem não consentida não entra por atalho. Numa plataforma para devs, o usuário é o integrador; contrato estável, idempotência e limites de custo importam mais que uma demo de UI. No B2B regulado, rastreabilidade, permissão e revisão de finalidade podem exigir ainda menos autonomia da IA e mais evidência operacional.

Cada variação muda usuário, outcome, risco e grau de automação. Se agentes não quiserem a sugestão ou o custo superar o valor, a próxima iteração pode ser triagem manual melhor instrumentada, regras determinísticas ou abandono da hipótese de IA. “Hero” profissional, se o termo for útil, é quem aprende e opera com responsabilidade, inclusive quando a resposta é parar. Lucro e PMF continuam perguntas externas à série.

Qual evidência falta para mudar o case?

Um case bom deixa claro o que o próximo experimento poderia refutar. Antes de convidar agentes, a equipe precisaria observar o caminho manual, estimar volume e frequência da tarefa e combinar com o gestor quais tickets podem entrar no piloto. Isso estabelece uma linha de base sem IA. A hipótese pode então ser escrita de forma contestável: com sugestão revisável, agentes concluem a triagem com menos retrabalho, sem aumentar reabertura, exposição de dados ou custo por tarefa útil. “Menos retrabalho” precisa virar evento e janela; “qualidade” precisa de revisão de casos, não apenas de aceitação da sugestão.

Mesmo após fechar os gates técnicos, o primeiro piloto produziria principalmente evidência de uso e operação: o agente consegue perceber a sugestão? Sabe quando ela está indisponível? Consegue rejeitá-la sem punição? O gestor entende o gasto e a regra de parada? Que erro chega ao canal de suporte? Uma amostra pequena pode revelar falhas graves e ainda ser insuficiente para estimar efeito médio ou PMF. Relatar “três agentes tiveram dificuldade na revisão” exigiria três agentes reais, consentimento e registro; não é algo que possamos deduzir da fixture atual.

O experimento deve admitir saídas diferentes. Se o fluxo manual já for rápido, talvez o melhor produto seja organizar fila e SLA sem IA. Se a sugestão reduzir tempo mas aumentar reabertura, a equipe pode restringir categorias ou pedir revisão adicional. Se custo faturado escapar da reserva, o piloto pausa independentemente da satisfação declarada. Se agentes não confiarem no resumo, reformular a experiência pode ser mais útil que trocar modelo. Essas decisões são um backlog orientado por evidência, não uma promessa de que um roadmap específico vencerá.

Para o portfólio profissional, essa seção funciona como compromisso público de método. Ela mostra que o candidato sabe que teste local, pesquisa de uso e resultado comercial respondem perguntas diferentes. Também revela onde precisa de colaboração: PM para valor e recrutamento, design para compreensão, suporte para exceções, segurança para dados e liderança para custo. Se uma vaga não oferece acesso a essas fontes, o trabalho possível muda; a narrativa de impacto precisa mudar junto. Isso evita transformar limitação organizacional em falha moral do engenheiro ou em claim fabricado.

Roteiro de entrevista: contar sem vender demais

Comece com o problema proposto e o papel do usuário. Mostre uma decisão técnica ligada à experiência: “mantivemos ticket manual quando o provedor cai”. Abra o teste; diga que é falha injetada. Mostre a alternativa rejeitada: resposta automática ao cliente. Apresente o achado inesperado do restore, sua correção e o limite. Termine no no-go e no experimento que mudaria a decisão. Isso dá ao entrevistador algo para desafiar em cada passo.

Pergunte também sobre a vaga: quem dá acesso a usuários? Quem decide cortar uma feature após feedback? O time tem design, PM e suporte disponíveis ou espera acumulação sem tempo? Há teto de custo e dono de incidentes? Como se mede uma tarefa útil, não só deploys? São perguntas práticas, não teste ideológico de “time de produto” versus “time de features”. Sinal de expectativa irreal: exigem impacto em receita sem acesso a dados, chamam opinião de pesquisa, ou colocam on-call e consentimento sobre uma pessoa sem autoridade para pausar.

Avaliação e checklist final

Antes de publicar um case ou levá-lo à entrevista, execute o checker e abra os paths que ele aponta. Confirme que números trazem denominador e natureza sintética; que o texto diz “piloto não executado”; que a UI e o teto faturado seguem bloqueados; que nenhum link chama draft de página live. Peça revisão a PM/design/suporte para as interpretações que são deles. Um script verde é condição de consistência do registro, não prova de impacto.

• Básico: reescreva “construí IA e aumentei produtividade” usando problema, decisão, teste e limite. Critério: nenhuma pessoa ou ganho real aparece sem fonte. Solução comentada: “adicionei sugestão em modo sombra; eval e fallback passaram em fixtures; impacto no trabalho do agente não foi medido”.
• Intermediário: encontre no índice um número que parece forte e escreva sua versão completa. Critério: denominador, janela, população e método aparecem na mesma frase. Solução comentada: “76/76 testes offline no ambiente local do PE07” prova regressão naquele snapshot, não SLO nem adoção; para 81,8%, use os recortes e a fixture do PE06.
• Avançado: proponha uma decisão de piloto para um tenant B2B regulado. Critério: responsável por dado/consentimento, teto faturado, UI de revisão, rollback, feedback e condição de no-go. Solução comentada: mantenha no-go enquanto gates 6–8 e 10 estiverem abertos; só convide sob opt-in e operador identificado, sem converter esse protocolo em resultado executado.

Glossário e fechamento

Output é entrega produzida; outcome é mudança observada na tarefa ou negócio. Claim é uma afirmação do case que precisa de classe de evidência. Gate é condição verificável para avançar ou pausar. Modo sombra gera sugestão sem automatizar a decisão. PMF é uma hipótese sobre aderência produto-mercado que este exercício não mediu.

O portfólio final do DeskPilot não termina com “produto lançado”. Termina com um case que qualquer colega pode auditar e um próximo experimento que ainda precisa de pessoas, autorização e operação real. Esse é um ponto de partida mais útil para uma carreira de Product Engineer do que trocar o título no perfil: quando alguém perguntar “como você sabe?”, há um arquivo, um teste, um denominador e uma resposta honesta sobre o que ainda falta.

Fontes

• PostHog — What is a product engineer? — prática declarada da empresa, consultada em 2026-09-29.
• SVPG — Product vs Feature Teams — Marty Cagan, 2019; framework autoral de colaboração e outcomes.
• DORA — State of AI-assisted Software Development 2025 — resumo do estudo, sem extrapolação para efeito individual.
• Evidências internas e seus limites: sources.md, case-study.md e portfolio-index.md.