Da spec ao merge: o fluxo em que engenharia entra por último

Na Laurel, o cliente vê o protótipo funcionando antes de engenharia escrever uma linha de código de produção. Não é detalhe de processo — é a inversão que reorganiza todo o resto.

O fluxo antigo era spec → engenharia → protótipo → cliente. O deles é estratégia → protótipo → cliente → engenharia. Engenharia entra tarde, e entra tarde de propósito.

Isso veio do webinar Product Management Fundamentals in the AI Era, da Reforge, com Jiaona Zhang (CPO da Laurel) e Anand Subramani. A JZ abriu o processo deles etapa por etapa, com um exemplo real: a área de billing, construída esse ano. Documentei aqui porque quero levar pro meu time — e porque a parte replicável não é a ferramenta. É a ordem.

Se você quer o porquê antes do como: o raciocínio está no post sobre o que sobra do papel de produto. Resumo de uma linha — a premissa era escassez de engenharia, ela caiu, e não dá pra trocar só uma peça do sistema.

O fluxo, etapa por etapa

Convicção antes de qualquer tela. Conversas com cliente, calls de vendas, análise de mercado. Antes de seguir, três coisas na mão: problema real, mercado grande, ponto de vista próprio sobre o que construir. A JZ é explícita: essa parte é mais difícil que o protótipo.
Documento de estratégia — o novo spec. Toda decisão e trade-off escritos, com o porquê de cada caminho ter vencido o outro. A razão é agêntica: agentes e gente nova vão pendurar trabalho nessas premissas, e premissa errada derruba tudo depois. Na prática, é antecipar no papel o "opa, isso é um problema" que antes só aparecia numa sala com engenheiro.
Protótipo de visão, construído pelo captain. Quem constrói ponta a ponta é o responsável pelo projeto — na Laurel, costuma ser o PM, mas por mérito, não por cargo. Sai em dias, com Claude Code ou equivalente, sem designer e sem engenheiro, porque o design system já está carregado na ferramenta. Quem fez o de billing não é engenheiro; é formado em gestão esportiva.
Cliente, com o protótipo clicável na mão. Eles colocaram na frente de CFOs de verdade, antes de existir código de produção. O sinal que procuram: a pessoa perguntar quando entra no beta. É esse feedback que refina o spec — não o contrário.
Engenharia entra, e entra pelo backend. Frontend o PM faz quase inteiro. Backend é emaranhado e precisa de engenharia de verdade pra amarrar o protótipo na arquitetura.
Dois branches, nunca um. O de visão continua andando e serve pra teste com usuário. O do MVP é separado e deliberadamente menor. O protótipo nunca vira MVP 1:1 — ele vai mais longe de propósito, pra validar o quadro inteiro.
Review, comentário e merge. A revisão de engenharia é feita pelo PM. O engenheiro entra só pra comentar no PR final, tarde, de propósito — assim ele nunca vira lixeira de PR ruim. E quem aperta o merge é o PM.

O que segura o fluxo por baixo

Nada disso funciona no vácuo. A parte que quase não aparece nos posts de LinkedIn é a fábrica:

Teste automatizado, condição de entrada e não item de backlog.
Agente de code review treinado na base, que responde comentário e itera.
"Babysit PR": um agente que conduz o não-engenheiro pelo processo de PR passo a passo — exatamente o trabalho de babá que um engenheiro faria.
Plantão: todo PM e designer que shipa está na escala — quebrou de madrugada, o telefone que toca é o dele.

Junto com isso, engenharia mudou de posto: menos frontend, mais backend, confiabilidade, testes e limpeza de base pra desenvolvimento agêntico. Engenharia não saiu do fluxo — saiu do meio dele e foi construir o chão.

O que eu levo disso pro meu time

Três coisas dão pra adaptar já, e nenhuma depende de a gente estar no nível deles.

A ordem. Mostrar algo clicável pra cliente antes de passar spec pra engenharia. Essa é a mudança de maior alavanca e a mais barata: não exige fábrica nenhuma, exige disciplina de não fazer handoff cedo demais.

O documento de estratégia com os trade-offs escritos. Isso independe de IA — só ficou mais urgente, porque agora tem agente lendo. É o que a gente já vem construindo no ClickBus-OS, e faltava essa justificativa pra manter o hábito. É também o que sobra do papel de produto quando a decisão descentraliza: garantir que todo mundo tenha contexto pra decidir bem.

A pergunta que precede o protótipo. No billing, a Laurel queria aprender uma única coisa: dá pra substituir o trabalho do billing partner por agentes de um jeito que pareça complementar, e não ameaça? Toda decisão de protótipo era julgada contra isso. É um filtro brutal — se a tela não responde a pergunta, ela morre.

E o que eu não levo por enquanto: o merge do PM e a escala de plantão. Não porque seja exagero, mas porque é a última peça, não a primeira. Enquanto a resposta pra "o que segura um merge meu" for "um engenheiro revisando com cuidado", alargar a porta é transferir trabalho, não criar capacidade.

A etapa que dá pra copiar na segunda-feira não custa ferramenta nenhuma. É parar de mandar spec pra engenharia antes de ter mostrado alguma coisa clicável pra um cliente de verdade.