IA redefine gestão de produtos: foco em decidir o que construir

O problema que IA não resolve

Rich Mironov, veterano de gestão de produtos, descreve uma conversa com um cofundador de IA que construiu software interessante, mas não conseguiu nenhum interesse de compradores. O problema não era técnico: faltava público-alvo definido, problema claro e mensagem de valor econômico convincente. O cofundador tentava vender sua própria visão do que os clientes "deveriam precisar".

A metáfora do haltere (barbell)

Mironov argumenta que, à medida que a IA acelera a produção de código, o trabalho mais valioso de produto migra para as extremidades - como um haltere. Historicamente, PMs gastavam 60-100% do tempo no desenvolvimento central (SDLC, roadmaps, tickets), apenas 20% na descoberta (o "fuzzy front end") e 10-20% em go-to-market. Com código 10x mais rápido, a pressão será pular a descoberta e ir direto para a codificação - o que ele considera um erro.

As três zonas do novo papel

Descoberta (fuzzy front end): Mironov defende que 40%+ do tempo de produto deve ir para recomendações baseadas em evidência sobre poucas apostas grandes de receita. IA pode acelerar partes do processo (identificar usuários com tickets similares, transcrever entrevistas, escanear concorrentes), mas não substitui julgamento, contexto nem a capacidade de identificar a ideia realmente brilhante entre o ruído. Ele sugere focar descoberta apenas em apostas estratégicas arriscadas e difíceis de reverter, descartando 80% dos backlogs.

Desenvolvimento central: Engenheiros fazem mais que escrever código - entendem sistemas, antecipam gargalos, aplicam aprendizado sobre segurança e escalabilidade. O papel de produto aqui é manter times focados em resultados e valor de mercado, escrever briefs que capturem intenção estratégica e fazer perguntas maiores que o código (arquitetura, suportabilidade, concept drift).

Go-to-market: Se não conseguimos explicar em termos econômicos simples por que alguém deveria considerar nosso produto, a receita não flui. Com ciclos de desenvolvimento comprimidos para semanas, GTM precisa ser planejado desde as chamadas de descoberta - perguntando sobre benefícios, alternativas tentadas, justificativa de gasto e aprovadores de compra. Mironov sugere usar "money stories" para estimar receita futura e priorizar lançamentos conforme a capacidade real de vendas e marketing.

Contraste com "product engineers"

Mironov se posiciona contra a tendência de product engineers: na visão dele, isso é majoritariamente engenheiros fazendo pensamento de produto superficial a caminho de entregar código. A exceção é quando engenheiros de IA constroem ferramentas para outros engenheiros de IA - aí são seu próprio público.

Síntese

A barra fica mais pesada nas duas pontas: mais julgamento sobre o que construir, mais músculo em como vender. A engenharia fica com o meio.