Construindo produtos com IA: visão do PO Sênior

Nível: Sênior | Duração estimada de leitura: 40 minutos | Categoria: Trilha Sênior — Módulo 3 (IA para POs)

O módulo final. E o começo de tudo.

Você chegou ao último módulo do Backlogando.

Passou pela Trilha Iniciante, onde aprendeu o que é Product Ownership de verdade — não o cargo, mas a responsabilidade. Pela Trilha Júnior, onde desenvolveu os instrumentos do ofício: discovery, métricas, cerimônias, stakeholders, priorização, OKRs — e os primeiros passos com IA. Pela Trilha Pleno, onde aprofundou a dimensão estratégica: roadmap, dados, automatização, negócio. E agora, aqui na Trilha Sênior, navegou por liderança sem autoridade, cultura organizacional, times de alta performance, visão de negócio, mentoria e IA como vantagem competitiva.

Este módulo fecha esse ciclo — mas não como uma conclusão. Como uma abertura.

Porque o que vamos discutir aqui não é o passado da profissão. É a fronteira do presente e o território do futuro imediato. Construir produtos com IA — não usar IA para construir produtos mais rápido, mas colocar IA no coração do que o produto faz — é o desafio mais complexo, mais ambíguo e mais estimulante que um PO pode enfrentar hoje.

E é o desafio para o qual todo o aprendizado acumulado nas trilhas anteriores serviu de preparação.

A distinção que define tudo: usar IA versus construir com IA

Existe uma diferença fundamental que precisa ser estabelecida antes de qualquer outra coisa neste módulo, porque confundi-la leva a decisões estratégicas completamente equivocadas.

Usar IA para construir produtos é o que cobrimos nos módulos anteriores das trilhas Pleno e Sênior: usar Claude para escrever User Stories mais rápido, usar o ChatGPT Code Interpreter para analisar dados de produto, usar automações de IA para reduzir tarefas repetitivas. Nesses casos, a IA é uma ferramenta de produtividade do PO — ela está no processo de construção, não no produto entregue ao usuário.

Construir produtos com IA é o que este módulo trata: criar produtos onde a inteligência artificial é uma dimensão central da proposta de valor entregue ao usuário. O produto não apenas usa IA internamente — ele entrega IA como parte da experiência. O usuário interage com um sistema inteligente que aprende, adapta, recomenda, gera, prediz ou decide.

O Spotify não usa IA para fazer playlists mais rápido. Ele entrega IA como produto — a Discover Weekly é a proposta de valor. O Notion AI não usa IA para construir features mais rápido. Ele entrega IA ao usuário como capacidade dentro da ferramenta. O GitHub Copilot não usa IA internamente. É um produto cujo núcleo é IA.

Essa distinção muda tudo: o processo de discovery, os critérios de sucesso, a experiência do usuário, os modelos de monetização, os riscos e as dimensões éticas.

O que é diferente no discovery de produtos com IA

Discovery de produto tradicional parte de um problema bem definido — real, frequente, urgente — e busca soluções. O problema existe independentemente da solução. O PO vai a campo, encontra o problema, volta e o time imagina soluções.

O discovery de produtos com IA frequentemente inverte essa lógica. Às vezes, a capacidade tecnológica existe antes do problema claramente articulado. O modelo de linguagem capaz de sintetizar contratos jurídicos em segundos existiu antes que advogados articulassem formalmente esse como uma necessidade — porque advogados nunca haviam sonhado que isso fosse possível. A capacidade abre o espaço de possibilidade, e o discovery precisa descobrir quais problemas essa capacidade pode resolver melhor do que qualquer alternativa anterior.

Isso não significa que você começa pelo que a tecnologia pode fazer e depois inventa o problema. Significa que o processo de discovery precisa ser bidireccional: de um lado, a identificação de problemas reais de usuários; do outro, a exploração honesta de o que a capacidade de IA disponível consegue resolver com qualidade superior ao que existia antes.

Como fazer discovery para produtos com IA:

A primeira armadilha é pesquisar o que os usuários querem de IA. Usuários não sabem o que IA pode fazer. Perguntar "você gostaria que nossa ferramenta tivesse IA?" é metodologicamente inútil — a resposta vai ser quase sempre "sim" porque IA soa positivo, mas essa confirmação não revela nada sobre o que vale a pena construir.

O discovery eficaz para produtos com IA começa com a mesma pergunta de sempre: qual é o problema mais doloroso do usuário nesse contexto? Onde ele perde mais tempo? Onde comete mais erros? Onde as alternativas existentes falham de forma mais frustrante?

E então: qual dessas dores pode ser resolvida — ou resolvida de uma forma qualitativamente superior — por uma capacidade de IA disponível hoje?

A segunda armadilha é testar protótipos de IA com usuários que não têm expectativas calibradas. A maioria dos usuários que experimenta IA pela primeira vez sente uma mistura de fascínio com o que funciona e decepção desproporcional com o que não funciona. Se o modelo aluciná em um caso durante o teste, o usuário tende a generalizar que "a IA mente" — mesmo que na maioria dos casos ela funcione bem.

Calibrar expectativas antes dos testes de usabilidade — explicar o que a IA faz bem, o que faz com menos precisão e o que não tenta fazer — é parte do protocolo de research para produtos com IA, não um atalho para resultados melhores.

O Wizard of Oz como metodologia central:

Em produtos com IA, o Wizard of Oz testing é especialmente valioso. A ideia: simular o comportamento do sistema de IA com trabalho humano antes de construir a IA de verdade. O usuário pensa que está interagindo com um sistema automatizado. Na verdade, um humano está respondendo por trás.

Isso permite validar se a proposta de valor central — "o usuário quer receber esse tipo de output?" — funciona antes de investir meses em engenharia de ML. Se o Wizard of Oz não convencer o usuário de que o produto é valioso, a IA real certamente não vai.

Os princípios de UX que são únicos em produtos com IA

Experiência de usuário em produtos com IA é fundamentalmente diferente da UX em produtos determinísticos. Um produto convencional faz o mesmo em resposta ao mesmo input, sempre. Um produto com IA pode dar respostas diferentes ao mesmo input dependendo do contexto, do histórico e dos dados disponíveis. Isso cria desafios de UX que não existem em outros tipos de produto.

Princípio 1 — Gestão de expectativas como feature central

A decepção com produtos de IA frequentemente não vem de falha técnica — vem de expectativa mal calibrada. O usuário esperava algo que o sistema não fazia, ou não entendia o que o sistema estava tentando fazer.

Gestão de expectativas em produtos de IA não é uma preocupação de marketing — é uma decisão de produto. Como o sistema comunica o que pode e o que não pode fazer? Como comunica quando está incerto? Como comunica quando comete um erro?

O Google Maps não apresenta uma rota como "a rota perfeita". Apresenta como "a melhor rota com base nas condições atuais de tráfego" — com a implicação implícita de que as condições podem mudar. Essa calibração linguística não é trivial — ela define a relação do usuário com o sistema quando algo não sai como esperado.

Princípio 2 — Controle e agência do usuário

Quanto mais autônomo o sistema de IA, mais crítico é dar ao usuário mecanismos claros de controle e intervenção. Usuários toleraram muito melhor erros de sistemas de IA quando sentem que têm controle — quando podem corrigir, quando podem dar feedback que o sistema vai usar, quando podem delimitar o escopo de atuação da IA.

Sistemas que agem de forma autônoma sem transparência sobre o raciocínio e sem mecanismo de intervenção geram desconfiança mesmo quando a maioria das ações está correta. Sistemas que explicam seu raciocínio e permitem intervenção fácil geram muito mais tolerância a erros pontuais.

O PO que define a experiência de um produto com IA precisa responder: em que pontos o usuário pode e deve intervir? Como o sistema torna esses pontos visíveis? Como o feedback do usuário alimenta a melhoria do sistema?

Princípio 3 — Fallback gracioso

Todo sistema de IA vai falhar. Modelos de linguagem alucinam. Sistemas de recomendação recomendam itens irrelevantes. Sistemas de classificação classificam incorretamente. A questão não é se vai falhar, mas quando e como o produto se comporta quando falha.

O design de fallback gracioso — a experiência que o usuário tem quando a IA não consegue fazer o que devia — é uma das decisões de produto mais importantes e mais negligenciadas em produtos com IA.

O fallback gracioso não é uma mensagem de erro técnica. É uma experiência que mantém o usuário no produto, reconhece a limitação com transparência e oferece uma alternativa — seja uma versão menos automatizada da mesma tarefa, seja a opção de escalar para suporte humano, seja simplesmente uma explicação honesta de por que o sistema não conseguiu ajudar neste caso.

Princípio 4 — Progressividade e confiança acumulada

Usuários não confiam em sistemas de IA completamente no primeiro uso — e não deveriam. Confiança em sistemas de IA é construída progressivamente, através da experiência de ver o sistema funcionar bem em situações de baixo risco antes de confiar nele em situações de alto risco.

O produto que pede ao usuário para tomar uma ação de alto impacto baseado em recomendação de IA no primeiro uso vai ter conversão baixíssima. O produto que demonstra o valor da IA em contextos de baixo risco — onde o usuário pode avaliar facilmente se a recomendação foi boa — antes de pedir confiança em contextos de alto risco, vai construir adoção de forma mais sustentável.

Essa progressividade precisa ser desenhada intencionalmente — não esperada como consequência natural do uso.

Princípio 5 — Explicabilidade contextual

"Por que a IA fez isso?" é uma das perguntas mais frequentes de usuários de produtos com IA — e uma das menos respondidas adequadamente pela maioria dos produtos. Explicabilidade não significa expor os pesos do modelo neural. Significa dar ao usuário uma explicação na linguagem do domínio que faça sentido para ele.

"Estamos recomendando este conteúdo porque você consumiu materiais similares recentemente e outros usuários com perfil parecido ao seu avaliaram muito bem" é mais útil do que "confidence score: 0.87". A primeira explica em termos que o usuário pode avaliar e contestar. A segunda é tecnicamente mais precisa mas praticamente inútil para a relação do usuário com o sistema.

Como definir sucesso para produtos com IA

Métricas de sucesso para produtos com IA precisam capturar dimensões que métricas tradicionais de produto não cobrem.

Métricas de qualidade de output:

Taxa de aceitação de sugestões: em produtos que sugerem algo ao usuário (texto, código, diagnóstico, recomendação), qual percentual das sugestões é aceito sem modificação? Aceito com modificação menor? Rejeitado completamente? Esse trio de métricas revela a relevância real do output da IA para o usuário.

Taxa de override: quando a IA toma uma decisão ou faz uma recomendação, com que frequência o usuário a substitui por uma escolha própria? Taxa de override muito alta indica que a IA não está calibrada para as preferências do usuário. Taxa de override muito baixa pode indicar que o usuário não está se sentindo empoderado para contestar o sistema — o que é um sinal de alerta diferente.

Qualidade percebida: pesquisas periódicas simples com o usuário sobre a qualidade das sugestões ou decisões da IA. "A recomendação de hoje foi relevante para você?" (sim/não/mais ou menos) coletada de forma não intrusiva cria um sinal de qualidade que nenhuma métrica técnica consegue substituir.

Métricas de confiança e adoção:

Profundidade de uso: usuários que usam as features de IA de um produto tendem a ter padrões de uso diferentes dos que não usam. Comparar retenção, NPS e LTV entre os dois grupos revela o impacto real da IA na percepção de valor do produto.

Time to trust: quanto tempo um novo usuário leva, em média, para começar a usar as features de IA de forma consistente? Esse tempo é um indicador da eficácia do processo de demonstração de valor e da gestão de expectativas.

Métricas de aprendizado do sistema:

Performance do modelo ao longo do tempo: os modelos de IA estão ficando mais precisos conforme o produto acumula dados e feedback? Essa é a métrica que valida se o flywheel de dados está funcionando — se o produto está construindo vantagem competitiva crescente ou apenas mantendo o status quo.

Cobertura: qual percentual dos casos de uso reais dos usuários o sistema consegue atender com qualidade? Gaps de cobertura são oportunidades de melhoria e potencialmente de expansão de mercado.

A ética como decisão de produto — não como restrição externa

Construir produtos com IA coloca o PO Sênior em uma posição de responsabilidade ética que vai além do que qualquer outra geração de profissionais de produto enfrentou. As decisões de produto que você toma hoje — sobre o que o sistema otimiza, sobre quais dados coleta, sobre como comunica (ou não comunica) ao usuário que IA está sendo usada, sobre quem tem acesso e quem não tem — têm consequências que se multiplicam em escala de formas que produtos tradicionais nunca tiveram.

Viés algorítmico como problema de produto:

Sistemas de IA treinados em dados históricos replicam e frequentemente amplificam os vieses presentes nesses dados. Um sistema de triagem de candidatos treinado com histórico de contratações de uma empresa que historicamente contratou predominantemente homens brancos vai aprender a preferir perfis similares. Um sistema de crédito treinado com dados históricos de inadimplência que refletem desigualdades socioeconômicas vai perpetuar e amplificar essas desigualdades.

O PO Sênior que constrói produtos com IA tem a responsabilidade de:

Mapear explicitamente os grupos potencialmente afetados pelo produto e analisar se o sistema performa de forma equitativa entre eles. Uma feature de IA que funciona bem para 80% dos usuários mas é sistematicamente pior para um grupo específico não é aceitável — especialmente se esse grupo já enfrenta outras formas de desvantagem.

Definir o que o sistema está otimizando — e questionar se isso é o que deveria ser otimizado. Um sistema de recomendação de conteúdo otimizado para tempo de sessão vai aprender a recomendar conteúdo que mantém o usuário engajado — mesmo que esse conteúdo seja extremista, polarizador ou prejudicial ao bem-estar. Métricas de engajamento de curto prazo e métricas de saúde do usuário a longo prazo frequentemente conflitam de formas que só se tornam visíveis depois que o dano está feito.

Privacidade como valor de produto — não apenas como compliance:

O usuário tem o direito de saber o que o produto faz com seus dados, como eles alimentam os sistemas de IA, e de fazer escolhas informadas sobre isso. Isso não é apenas LGPD — é respeito pela autonomia do usuário.

Produtos que constroem confiança genuína ao redor de privacidade frequentemente têm vantagem competitiva em segmentos que se preocupam com isso — especialmente em mercados enterprise, em saúde, em finanças e em contextos onde o usuário está compartilhando informações sensíveis.

Transparência sobre limitações:

Um produto que exagera as capacidades da sua IA — que deixa o usuário acreditar que o sistema é mais preciso, mais completo ou mais confiável do que realmente é — está cometendo um erro ético que frequentemente se transforma em problema de negócio quando os usuários descobrem a realidade.

Transparência sobre limitações não é fraqueza de marketing. É a base da confiança de longo prazo que permite que produtos de IA construam a relação de dependência saudável que gera retenção duradoura.

O futuro do papel do PO na era de produtos com IA

Existe uma questão que POs fazem — geralmente com alguma ansiedade não expressa — quando o assunto de IA emerge com frequência crescente nas discussões de produto: a IA vai substituir o PO?

A resposta honesta é: em partes, sim. As partes do trabalho de PO que são mais mecanicamente repetitivas — geração de User Stories a partir de templates, categorização de feedbacks, extração de insights de dados estruturados, preparação de atas de reunião — já estão sendo automatizadas com eficácia crescente.

Mas a pergunta mais interessante não é o que a IA vai substituir. É o que o PO vai poder fazer quando não precisar mais fazer essas coisas.

O PO do futuro próximo:

Passa muito menos tempo em tarefas de produção de artefatos. Passa muito mais tempo em conversas, em julgamentos estratégicos e em construção de relacionamentos — as coisas que IA não consegue fazer bem.

Tem capacidade de processar muito mais sinais — porque IA analisa os dados brutos e entrega sínteses — e portanto pode ter uma perspectiva de produto mais abrangente e mais baseada em evidência do que qualquer PO anterior.

Precisa de habilidades de julgamento ético mais desenvolvidas — porque cada vez mais as decisões de produto têm dimensões éticas que emergem do uso de IA, e alguém precisa ter clareza de valores suficiente para navegar essas dimensões.

Atua como o elo entre a capacidade técnica de IA e o entendimento humano do problema — traduzindo o que a tecnologia pode fazer para o que o usuário precisa, e o que o usuário precisa para o que o sistema precisa ser capaz de fazer.

Tem responsabilidade crescente de alfabetização em IA para as organizações onde trabalha — não apenas para o time de produto, mas para stakeholders, para a liderança, para outros times que precisam entender o que IA pode e não pode fazer para tomar decisões estratégicas mais bem fundamentadas.

Construindo o produto com IA: o processo integrado

Para fechar este módulo, um processo integrado de como o PO Sênior aborda a construção de um produto com IA — do discovery ao lançamento.

Fase 1 — Discovery orientado por capacidade e problema:

Mapeie os problemas mais críticos dos seus usuários no contexto específico do produto. Para cada problema, avalie honestamente: qual capacidade de IA disponível hoje poderia resolver isso de forma superior às alternativas? Onde existe a interseção entre problema real urgente e capacidade de IA madura suficiente para resolver?

Valide a hipótese central com Wizard of Oz antes de comprometer recursos de engenharia de ML.

Fase 2 — Design da experiência com IA:

Defina explicitamente: o que o sistema faz, o que não faz, como comunica os dois para o usuário. Projete o fallback gracioso. Projete os pontos de controle e intervenção do usuário. Projete a progressividade — como o produto demonstra valor antes de pedir confiança.

Fase 3 — Mapeamento de riscos antes de desenvolver:

Quem pode ser negativamente impactado se o sistema errar sistematicamente? Quais são os vieses potenciais nos dados de treinamento? Quais são as implicações de privacidade do que o sistema coleta e processa? Quais são os riscos regulatórios no contexto específico do produto?

Essas perguntas não são perguntas para depois do lançamento. São perguntas para antes de escrever a primeira linha de código.

Fase 4 — Métricas de sucesso pré-definidas:

Antes de lançar, defina: qual é a taxa de aceitação de sugestões que tornaria esse produto bem-sucedido? Qual é o NPS mínimo entre usuários que usam a feature de IA? Qual é a melhora esperada no modelo ao longo de 90 dias? Defina os critérios de sucesso antes de ver os dados — não depois, quando a tentação de interpretar qualquer número como sucesso é irresistível.

Fase 5 — Lançamento progressivo com ciclo de feedback fechado:

Lance para um segmento pequeno. Colete feedback de qualidade — não apenas métricas de uso, mas qualidade percebida e casos de falha. Ajuste o modelo, o produto e a experiência. Expanda. Repita.

O lançamento progressivo em produtos com IA não é apenas gestão de risco técnico — é a forma como o flywheel de dados começa a girar. Cada interação de usuário com o sistema é dados que tornam o sistema melhor para o próximo usuário.

Onde aprofundar

Livros essenciais para construtores de produtos com IA:

Human Compatible, de Stuart Russell. O cofundador da área de IA moderna revisita os fundamentos e propõe um novo paradigma: sistemas de IA que são incertos sobre os objetivos humanos — e que aprendem o que os humanos querem através de observação e interação, em vez de otimizar objetivos fixos. Fundamental para entender por que os sistemas de IA atuais têm limitações estruturais e o que a próxima geração precisa ser.

The Alignment Problem, de Brian Christian. O jornalista e pesquisador investiga o que acontece quando sistemas de IA otimizam objetivos que não são exatamente o que queríamos que otimizassem — e por que isso é o problema mais difícil e mais importante da construção de IA. Escrito para não-técnicos, é o livro que muda a forma de pensar sobre o que significa "funcionar" para um produto com IA.

Weapons of Math Destruction, de Cathy O'Neil. A análise mais acessível e mais impactante sobre como sistemas algorítmicos — muitos dos quais são produtos de dados e IA — perpetuam e amplificam desigualdades. Obrigatório para qualquer PO que vai construir produtos que afetam decisões importantes na vida das pessoas.

Designing Human-Centric AI Experiences, de Akshay Sharma. Especificamente sobre UX para produtos com IA — um campo ainda em formação, mas com princípios emergentes sólidos que este livro sistematiza bem.

Para a dimensão técnica (sem precisar programar):

Grokking Artificial Intelligence Algorithms, de Rishal Hurbans. Explicação visual e acessível de como os principais algoritmos de IA funcionam — sem matemática avançada. O PO que entende os mecanismos básicos toma decisões de produto melhores porque sabe o que é possível e o que não é, e por quê.

The Coming Wave, de Mustafa Suleyman (já citado no módulo anterior — essencial o suficiente para citar duas vezes). A perspectiva de alguém que esteve no centro da construção de alguns dos sistemas de IA mais impactantes do mundo sobre para onde tudo isso está indo.

Referências de research e dados:

Stanford AI Index (publicado anualmente) — o estado da IA em dados: capacidades, adoção, impacto econômico, implicações de segurança e regulação. Citado em discussões de alto nível em toda a indústria.

MIT Technology Review — a publicação de tecnologia com cobertura mais rigorosa e equilibrada de IA. Nem evangelismo acrítico nem negativismo exagerado — análise fundamentada.

AI Now Institute Reports — a organização de pesquisa mais rigorosa sobre impactos sociais de IA. Essencial para a dimensão ética do trabalho de produto.

Comunidades e redes:

Product Led AI (comunidade no Slack) — profissionais de produto discutindo especificamente como construir produtos com IA. Cases reais, dúvidas reais, perspectivas diversas.

Lenny's Newsletter — tem coberto com crescente profundidade como os melhores times de produto estão integrando IA. Os posts mais recentes são especialmente relevantes para o contexto deste módulo.

Conclusão — e o que vem depois de tudo isso

Você chegou ao fim.

Não ao fim do aprendizado — esse não tem fim para quem escolheu Product Management como profissão. Mas ao fim desta jornada estruturada que começou com a pergunta mais básica ("o que é Product Ownership de verdade?") e chegou até a fronteira mais avançada do campo ("como o PO Sênior constrói produtos onde IA é a proposta de valor central?").

Olhe o caminho percorrido. Não em módulos — em perguntas.

Você aprendeu a perguntar: qual problema do usuário estou resolvendo, e como vou saber se resolvi? Aprendeu a perguntar: qual é a prioridade certa quando tudo parece urgente, e como defendo essa escolha com dados? Aprendeu a perguntar: como influencio pessoas e decisões sem ter autoridade formal para isso? Como crio uma cultura onde o produto é tratado como a questão estratégica que realmente é? Como formo outros profissionais que vão fazer perguntas melhores do que eu faço hoje? Como uso IA como alavanca estratégica — não como atalho tático? Como construo produtos com IA de forma que cria valor genuíno, que não prejudica os usuários que serve e que tem vantagem competitiva real?

Essas perguntas não têm respostas fixas. Têm respostas que dependem do contexto, do momento e do que você aprendeu desde a última vez que as fez.

O PO que aprende a fazer melhores perguntas — que entende quando uma resposta está incompleta, quando um pressuposto precisa ser questionado, quando uma métrica está enganando em vez de iluminando — esse PO vai continuar relevante independentemente das ferramentas que surgirem, dos frameworks que forem lançados e das mudanças que a indústria trouxer.

Porque produto, no fundo, não é sobre metodologia. É sobre curiosidade. Sobre a obsessão genuína com o problema do usuário. Sobre a disposição de estar errado e aprender. Sobre a coragem de decidir com informação incompleta. Sobre a humildade de reconhecer que o trabalho nunca está completamente feito.

Se você saiu daqui com a sensação de que ainda tem muito a aprender — ótimo. É o sinal mais honesto de que o aprendizado foi real.

E se tiver dúvidas no caminho, lembre: há uma comunidade de POs aprendendo as mesmas perguntas. Você não está sozinho nessa jornada.

Bem-vindo ao que vem a seguir.