De desenvolvedor a Product Engineer: assuma o problema antes da stack

O ticket dizia: “Adicionar um chatbot para agilizar o suporte”. A equipe entregou um widget bem construído. Abre rápido, passa nos testes e registra conversas. Na segunda-feira, o agente continua lendo cada solicitação, tentando descobrir a qual fila ela pertence e procurando alguém disponível. O gestor pergunta por que a demora na atribuição permanece. O desenvolvedor responde que o chatbot foi entregue conforme o ticket. Ambos dizem a verdade.

Essa cena é demonstrativa. Não descreve um cliente do Lemon nem um produto em operação. Serve para expor uma lacuna: software correto pode deixar intacto o problema que motivou sua construção. A pergunta de produto começa antes da stack: que decisão permitiria atribuir um ticket à pessoa certa mais cedo, sem aumentar erros ou transferir custo oculto ao suporte?

Minha tese: Product Engineering começa quando uma pessoa de engenharia assume, junto com PM, design, suporte e negócio, responsabilidade por formular o problema, escolher uma intervenção e observar suas consequências. Isso não exige abandonar profundidade técnica nem acumular todas as funções. Exige uma fronteira de decisão explícita. Um título novo, sem acesso a usuários, critérios e autoridade, não produz essa fronteira.

Vamos construir o primeiro artefato do DeskPilot, um produto didático de triagem assistida para suporte B2B. Neste capítulo ele ainda não tem cliente, entrevistas, receita, aplicação em produção ou benefício comprovado. A saída é um brief v0 que qualquer equipe pode contestar e um checker offline que detecta campos essenciais ausentes. O capítulo seguinte investigará se o problema e o segmento propostos sobrevivem ao contato com usuários reais.

O menor exemplo: trocar a solução por uma hipótese

“Adicionar chatbot” é uma especificação de entrega. Ela não identifica quem sofre, qual comportamento muda nem como saberemos se houve melhora. Para iniciar, escreva duas alternativas concorrentes:

Em ambos os casos, o resultado de interesse é tempo até atribuição correta, medido desde a chegada até a primeira atribuição confirmada como correta por uma regra de revisão definida antes do teste. A hipótese inicial é refutável: “Num piloto autorizado com tickets elegíveis de uma equipe B2B, triagem assistida e revisada por humano reduz a mediana desse tempo frente ao fluxo sem IA, sem elevar reatribuições ou incidentes de tenant.” O brief v0 propõe 20% de redução relativa da mediana ao longo de duas semanas como meta didática de experimento, não resultado observado nem critério já aprovado para piloto. Volume, sazonalidade, qualidade do baseline e custo aceitável de erro ainda precisam ser discutidos com suporte e owner antes de fixar qualquer limiar operacional.

Uma feature entregue é verificável por deploy, teste e aceite técnico. Adoção exige observar se agentes a usam no trabalho real, em quais casos, e por quê. Resultado exige comparação da medida de interesse com baseline e efeitos adversos. “O modelo produziu uma categoria válida” verifica um contrato de dados. “O agente aceitou a sugestão” mostra comportamento. Nenhum dos dois demonstra que o cliente recebeu resposta melhor. Essa separação muda arquitetura: registramos sugestão, revisão, atribuição e correção como eventos distintos, sujeitos a permissão e retenção definidas.

O que muda no trabalho de engenharia

“Product Engineer” não é uma promoção automática de “software engineer”. São recortes de responsabilidade que variam por organização. Um engenheiro de software pode dominar confiabilidade, dados ou infraestrutura e influenciar produto profundamente. Um fullstack cobre camadas técnicas. Product Engineer costuma participar mais diretamente da formulação da experiência, da escolha do que construir e da observação do uso. O handbook da PostHog, consultado em 27/09/2026, descreve essa prática dentro da PostHog; não estabelece uma definição universal nem prova que um cargo é superior.

Uma pessoa pode cobrir mais de uma coluna em equipe pequena. Isso não torna dispensável a competência dos demais nem transfere autoridade por osmose. O modelo de Marty Cagan para equipes orientadas a outcome descreve colaboração entre produto, design e engenharia; o próprio autor avisa que sua nomenclatura não é padrão. Use o modelo para perguntar quem decide e quem responde pelas consequências, não para classificar pessoas como “menos produto”.

AI-native também precisa de duas camadas. Na primeira, IA ajuda a desenvolver: esboçar código, gerar variações de testes, resumir documentação. O engenheiro ainda define requisito, revisa diff, testa limites e assume operação. Na segunda, IA aparece na experiência do usuário: o DeskPilot pode sugerir uma categoria e um resumo. Nesse caso, os erros atingem o trabalho do agente e potencialmente o cliente final; revisão humana e validação pelo backend passam a integrar o produto. O relatório DORA 2025 sobre desenvolvimento assistido por IA, consultado em 27/09/2026, é contexto de pesquisa sobre adoção e efeitos organizacionais, não evidência de que este experimento funcionará ou de que um indivíduo será promovido.

Três pessoas, interesses que não coincidem

DeskPilot é uma hipótese de triagem para equipes de suporte B2B, não um mercado validado. O usuário direto é o agente que lê o ticket, consulta contexto autorizado e decide se aceita a sugestão. O comprador potencial é o gestor de suporte, que precisa justificar custo, qualidade e integração com o fluxo da equipe. O afetado é o cliente final que espera encaminhamento e resposta. O mesmo atraso tem custos diferentes para cada um.

“Provável” importa. Não entrevistamos essas pessoas. O mapa é uma lista de perguntas, não descoberta concluída. Velocidade pode conflitar com precisão: uma atribuição rápida e errada cria mais uma transferência. A autonomia do agente pode conflitar com padronização desejada pelo gestor. Mais contexto pode melhorar sugestão e, ao mesmo tempo, elevar custo de processamento e exposição de dados. O brief precisa mostrar essas tensões antes que uma demo elegante as esconda.

O recorte inicial também é uma escolha reversível: começar com uma única equipe de suporte B2B, um canal de entrada autorizado e tickets que possam ser tratados sem dados especialmente sensíveis. Não há tamanho de mercado conhecido. A alternativa atual ainda precisa ser observada; para o exercício assumimos uma fila manual como fixture de continuidade sintética, sujeita a correção após a primeira investigação. Se a equipe já usa regras eficientes, talvez não exista oportunidade para IA.

Brief v0 do DeskPilot

O brief é curto porque deve caber numa conversa com quem opera o suporte. Curto não significa vago. Uma versão concreta está em examples/product-brief.md; o mapa de interesses em examples/stakeholder-map.md; decisões e condições de revisão em examples/decision-log.md. Os arquivos usam dados sintéticos e um checker local. Nenhuma linha equivale a entrevista real.

Campos ausentes são falhas de decisão. Se o brief diz “usuário: suporte” e omite comprador/afetado, uma equipe pode otimizar segundos na interface enquanto transfere risco ao cliente. Se diz “usar IA” sem alternativa sem IA, não há comparação honesta. Se não nomeia owner, ninguém sabe quem interrompe o piloto quando surgem erros. O script examples/check-brief.mjs deve aceitar a fixture completa e rejeitar uma versão sem esses contratos. Ele verifica estrutura e separação entre hipótese e evidência; não valida se a hipótese é verdadeira, nem se alguém autorizou uso de dados. Consulte verification.md para comandos e resultado efetivamente executados.

Uma versão copiável do núcleo do brief pode ser esta. Os valores são hipóteses do tutorial:

Problema: tempo até atribuição correta possivelmente alto; baseline desconhecido.Usuário: agente de suporte. Comprador potencial: gestor. Afetado: cliente final.Sem IA: campos estruturados + regras de fila + revisão humana.Com IA: categoria e resumo sugeridos; agente confirma ou rejeita.Outcome: mediana do tempo até atribuição correta por ticket elegível.Guardrails: proporção de reatribuições, erros graves e carga de revisão.Evidência faltante: volume, timestamps, baseline, entrevistas e consentimento.Owner: a designar com suporte e produto antes de piloto real.Rollback: desativar sugestão; preservar fluxo manual e log mínimo redigido.

Mesmo esse bloco precisa de condições antes de virar teste. “Atribuição correta” deve ser definida por quem opera e auditada em amostra; ticket sem atribuição até o corte de observação continua no denominador de elegíveis e aparece na proporção de pendentes. A mediana descritiva dos tickets atribuídos usa apenas tempos observados e informa esse denominador menor; sozinha, pode parecer melhor quando casos difíceis seguem pendentes. Para decidir, a equipe deve acompanhar também a proporção corretamente atribuída até um prazo fixado antes do piloto, ou usar análise de tempo até evento com censura explícita. Falta saber se o timestamp registra chegada real ou importação atrasada, se tickets complexos se concentram num turno e se uma reatribuição é erro ou parte normal do atendimento. O brief obriga a nomear ignorância útil.

Do documento ao experimento: toy e produção

O primeiro incremento não precisa ser um chatbot. Para aprender se o brief captura o problema, bastam fixtures de tickets sintéticos, um fluxo manual descrito, exemplos de sugestões opcionais e um checker determinístico. Essa escolha economiza integração antes de saber se a dor existe. Ela também preserva uma alternativa sem IA capaz de ganhar no teste.

No toy offline, examples/check-brief.mjs lê o documento e falha se faltar papel, hipótese refutável, owner, alternativa sem IA, evidências ausentes ou rollback. Um teste negativo deliberado demonstra que o checker não aceita um brief ornamental. A implementação não mede tempo de atendimento. Isso é uma lacuna explícita, não um defeito escondido. Futuros incrementos podem usar TypeScript, Node.js LTS, PostgreSQL e interface web simples como stack didática, com versões fixadas na sessão que construir o app. Escolher essas ferramentas hoje não valida a oportunidade.

Num piloto autorizado, o contrato seria mais exigente. Regras determinísticas do backend controlariam tenant, autorização, SLA, estados e atribuição. IA apenas sugeriria categoria e resumo com base em texto permitido. O agente veria a origem, poderia corrigir ou rejeitar e confirmaria a ação. O backend validaria qualquer comando, independentemente do que a interface ou modelo disser. Não haveria resposta externa automática, cobrança real nem deleção de dados de terceiros. PII seria minimizada; logs, redigidos; retenção e acesso, aprovados antes de ingestão. Um prompt não é controle de isolamento entre tenants.

Cada efeito precisa de dono, permissão, evidência e reversão. Alterar categoria exige permissão do agente, evento auditável sem texto sensível e retorno ao valor anterior quando viável. Abrir um piloto exige consentimento da organização, owner operacional e botão de desligamento. Mesmo uma interface “somente sugestão” tem efeito: pode induzir decisão errada. A pessoa que opera precisa poder perceber incerteza e manter o caminho manual.

Não temos evidência de que uma arquitetura com modelo seja necessária. Primeiro, compare uma taxonomia simples e campos melhores com o fluxo atual. Se a maior parte do atraso vier de falta de agente disponível, nenhuma classificação automática resolve o gargalo. Se o problema estiver na definição de filas, melhorar a regra pode superar o modelo com menor custo e risco. Essa possibilidade deve permanecer aberta até observarmos o trabalho.

Autonomia negociada, em dois contextos

Uma equipe de tickets recebe demandas fechadas. Uma equipe de produto tende a receber um problema e negociar solução. A distinção ajuda, mas organizações reais misturam os dois modos. É possível começar discovery em uma equipe de tickets sem fingir que recebeu mandato para mudar política, falar com clientes ou gastar orçamento.

Na equipe de tickets, proponha uma conversa curta com quem prioriza e quem opera suporte: “Posso gastar uma janela definida para mapear fluxo e comparar uma alternativa sem IA antes de estimar o chatbot? Preciso de acesso supervisionado a agentes, sem dados sensíveis, e retorno na sexta. Trago brief e incertezas; a decisão de prioridade continua com você.” O acordo deve registrar tempo de investigação, pessoas autorizadas, dados permitidos, limite de gasto, decisão que você pode tomar sozinho e quem aprova piloto. Se não houver acesso a usuários, trabalhe com fluxo documentado e marque a evidência como ausente. Não substitua entrevista por imaginação.

Na equipe de produto, PM, designer, engenharia e suporte podem formular juntos a hipótese e os guardrails. Engenharia pode decidir implementação reversível e viabilidade; design, como agente identifica e corrige erro; PM, prioridade e coerência com estratégia; suporte, adequação à operação e escalonamento. O owner do piloto responde pelo go/no-go depois de ouvir essas perspectivas. O contrato não deve diluir responsabilidade até ninguém poder interromper o experimento. Em ambos os contextos, combine uma agenda de feedback: revisão do brief antes de construir, observação após cada rodada, decisão escrita de continuar, alterar ou parar.

Um contrato mínimo de autonomia responde: qual problema podemos investigar; quais dados e usuários podemos acessar; quais decisões são nossas; quais exigem aprovação; que efeito está proibido; quem decide conflito; em que data revisitamos. Ele protege tanto a equipe quanto o engenheiro. “Seja mais dono” sem essas respostas geralmente aumenta cobrança sem ampliar capacidade de agir.

Quatro modos de falha que merecem nome

1. Título novo sem autonomia

Sintoma: alguém recebe o título de Product Engineer, mas só descobre demandas após priorização e não pode conversar com suporte. Causa: mudança de nomenclatura sem contrato de acesso, decisão e responsabilidade. Resposta: negociar uma pequena janela de descoberta, um interlocutor operacional e um limite claro de decisão. Registre recusas e alternativas. Se a organização não autorizar, avalie trabalho dentro da fronteira disponível; não assuma resultados fora dela. O custo para o usuário é uma interface construída a partir de suposições que ninguém pode corrigir.

2. IA escolhida antes do problema

Sintoma: time compara modelos e custos de tokens antes de observar por que tickets aguardam. Causa: demo de tecnologia vira definição de problema. Resposta: mapear fluxo e baseline, testar formulário/regras e descrever condição em que IA seria melhor. Talvez a espera seja causada por escala de trabalho ou política de fila. Se for, classificador nenhum a remove. Para o cliente final, automação irrelevante pode tornar a experiência mais opaca.

3. Feature confundida com impacto

Sintoma: “100% dos tickets classificados” vira sucesso, mesmo com mais reatribuições. Causa: output é barato de contar; correção e efeito adverso exigem observação. Resposta: separar contrato técnico, adoção e outcome no painel; definir denominador e guardrails antes do piloto; revisar amostra de erros. A equipe pode concluir que o protótipo funciona tecnicamente e que não melhorou serviço. Essa conclusão evita custo recorrente desnecessário.

4. Decidir sem consultar quem suporta consequências

Sintoma: engenharia muda categorias e fluxo sem envolver agentes, gestor, design, privacidade ou quem atende reclamações. Causa: “ownership” interpretado como licença para absorver a decisão alheia. Resposta: mapear afetados, pedir revisão antes do efeito, nomear owner final e canal de escalonamento. Uma sugestão incorreta afeta agente e cliente; uma retenção longa afeta risco da empresa; uma nova taxa afeta comprador. Ouvir não elimina discordância, mas torna trade-offs visíveis.

Avaliar sem fabricar sucesso