Entre atenção e direção: como usei IA para ampliar o trabalho de produto

Como Product Manager do Sexlog, eu estava envolvido em diferentes frentes do produto e participava das decisões que definiam seus rumos. Isso me colocava em contato constante com discussões estratégicas, acompanhamento de entregas, problemas de experiência, dados, necessidades dos times, movimentos do mercado e oportunidades que poderiam entrar no roadmap.

Eu conhecia profundamente o produto e o negócio. O desafio estava em sustentar essa profundidade enquanto duas mudanças de cenário ganhavam escala ao mesmo tempo.

O problema

A primeira mudança vinha da escala da operação. Uma parte das decisões acontecia em reuniões, enquanto outras surgiam em conversas no Slack, mensagens diretas ou threads que continuavam evoluindo ao longo dos dias. Havia também compromissos que eu assumia, respostas que dependiam de outras pessoas e assuntos que não exigiam uma ação imediata, mas precisavam continuar no meu campo de visão.

Minha lista de tarefas começou a crescer, mas o problema não era apenas a quantidade. Uma lista tradicional conseguia registrar o que eu precisava fazer, mas não preservava necessariamente o contexto de cada assunto. Também não me ajudava a acompanhar uma pendência espalhada entre uma reunião, uma thread e uma conversa posterior.

Para atuar com profundidade, eu precisava manter visível não apenas que algo estava pendente, mas por que aquilo importava, quem estava envolvido, o que já havia sido decidido e qual deveria ser o próximo movimento. Eu não precisava de mais uma ferramenta genérica de gestão de tarefas. Precisava de uma forma simples de organizar minha própria atuação como PM.

A segunda mudança vinha da velocidade de entrega. Com os times ganhando capacidade de desenvolvimento por meio da IA, protótipos e soluções passaram a chegar à implementação em ciclos menores. Esse avanço tornava ainda mais importante ampliar a qualidade da descoberta. Roadmaps e backlogs são finitos, e construir mais rápido não garante que as decisões estejam direcionadas às oportunidades mais relevantes.

Analisar mercado e produtos comparáveis já fazia parte do meu trabalho, mas essa atividade acontecia de forma pontual. As informações estavam distribuídas entre diferentes fontes e cada análise começava a envelhecer assim que um produto alterava seus preços, lançava uma funcionalidade, mudava seu posicionamento ou recebia novos sinais dos usuários.

Ao mesmo tempo, eu tinha acesso a dados próprios do Sexlog, feedbacks de usuários, indicadores do negócio e materiais estratégicos que eu mesmo produzia. O potencial estava em relacionar esse contexto interno a sinais de mercado e produtos comparáveis, transformando informações dispersas em evidências capazes de qualificar oportunidades reais. Eu precisava aumentar minha capacidade de observar mudanças, confrontar percepções, identificar riscos e gerar novas teses sem transformar a maior velocidade dos times em incentivo para construir soluções apenas porque agora era possível entregá-las mais rápido.

Minha atuação

A partir desse diagnóstico, concebi e construí duas ferramentas complementares. Criei o Radar do PM como uma memória operacional para conversas, compromissos e dependências que exigiam minha atenção. Para ampliar a qualidade da descoberta, criei a Inteligência de Mercado, conectando sinais externos ao conhecimento que eu havia acumulado sobre produto, clientes, estratégia e negócio.

Defini quais fontes deveriam alimentar cada ferramenta, como os dados seriam organizados, quais informações precisavam permanecer rastreáveis e onde a revisão humana era indispensável. A IA ampliava minha capacidade de acompanhar, relacionar e interpretar contextos, mas a definição dos problemas, os critérios de análise e a decisão final continuavam sob minha responsabilidade.

As duas ferramentas respondiam a partes diferentes do mesmo desafio. O Radar do PM protegia minha atenção sobre tudo o que já estava em movimento. A Inteligência de Mercado ampliava minha capacidade de descobrir, estruturar e questionar o que deveria entrar em movimento a seguir. Uma organizava a operação sem reduzir sua complexidade. A outra transformava sinais dispersos em uma base mais sólida para decidir.

O que mudou

O Radar passou a atualizar diariamente meu horizonte operacional e reuniu assuntos envolvendo 25 pessoas em 11 frentes de produto e operação. Compromissos e dependências deixaram de depender apenas da minha memória ou de retomadas ocasionais para permanecerem visíveis.

A Inteligência de Mercado gerou e qualificou ao menos 12 oportunidades com potencial claro para avançar ao processo de Product Discovery. Como a ferramenta foi concluída depois do planejamento trimestral, essas oportunidades ainda não haviam sido levadas à discussão, e eu não atribuo a elas resultados de roadmap ou negócio.

O impacto naquele estágio foi ampliar duas capacidades centrais da minha atuação como PM: acompanhar com profundidade aquilo que já estava em curso e produzir material mais consistente para decidir o que deveria ser explorado a seguir.

O Radar do PM foi criado para reunir informações que antes estavam espalhadas entre diferentes ambientes da minha rotina.

As notas das reuniões traziam decisões, resumos e próximos passos. O Slack concentrava pedidos, compromissos e discussões que frequentemente continuavam em várias threads. Algumas demandas também surgiam por e-mail, enquanto outras precisavam ser registradas manualmente por mim.

A ferramenta passou a organizar essas informações em um único painel.

Agentes com IA percorriam as fontes autorizadas, identificavam itens atribuídos a mim e transformavam conversas em pendências acompanháveis. Durante esse processamento, itens repetidos eram consolidados e cada pendência recebia informações como origem, prioridade e situação.

Defini três estados simples para acompanhar os assuntos:

• o que ainda precisava ser iniciado;

• o que já estava em andamento;

• o que dependia de outra pessoa ou time.

Essa distinção era importante porque uma pendência nem sempre exige execução imediata. Em muitos casos, meu papel era manter o assunto visível, cobrar uma definição no momento certo ou garantir que uma dependência não desaparecesse entre outras conversas.

Também mantive a possibilidade de adicionar tarefas manualmente. Eu não queria que a automação definisse sozinha o que merecia minha atenção. A IA ajudava a encontrar e organizar os sinais, mas eu continuava podendo complementar, corrigir e priorizar o que entrava no radar.

Outra decisão importante foi preservar o estado dos itens já resolvidos. A cada atualização, novas informações podiam entrar no painel sem fazer com que pendências concluídas reaparecessem como se fossem novas. Para isso, as tarefas precisavam manter identificadores consistentes ao longo das atualizações.

Na prática, o fluxo funcionava assim:

1. 01.

   os agentes consultavam notas de reuniões, mensagens e conversas recentes;

2. 02.

   os compromissos relacionados a mim eram identificados;

3. 03.

   informações repetidas eram consolidadas;

4. 04.

   os itens eram classificados por prioridade e situação;

5. 05.

   tarefas adicionadas manualmente eram incorporadas;

6. 06.

   o painel era atualizado preservando o que já havia sido resolvido.

O resultado era uma interface pequena diante da complexidade que existia por trás dela. Essa simplicidade era intencional.

Eu não queria criar um novo sistema de gestão para toda a empresa. Queria diminuir o esforço necessário para acompanhar minha participação em diferentes frentes e preservar a profundidade que cada assunto exigia.

O Radar do PM não passou a decidir o que eu deveria fazer. Ele reduziu o trabalho de procurar, lembrar e reconstruir contexto para que eu pudesse dedicar mais atenção àquilo que realmente exigia julgamento.

Mais previsibilidade sem perder a visão do todo

Com o Radar em uso, os prazos ficaram mais sólidos. Os assuntos que envolviam outras pessoas ou times deixaram de permanecer estacionados simplesmente porque a próxima ação não estava comigo.

Ao separar o que dependia de mim daquilo que precisava ser acompanhado com terceiros, consegui perceber mais cedo quando uma discussão precisava ser retomada, quando uma resposta estava demorando e quando uma dependência poderia comprometer uma entrega.

O ganho também apareceu na velocidade de organização. Passei a ajustar tarefas, reorganizar demandas e rever prioridades com mais clareza, sem precisar reconstruir manualmente tudo o que estava acontecendo antes de cada decisão.

Mais importante, o Radar ampliou minha capacidade de enxergar o produto de forma sistêmica. Em uma mesma visão, eu conseguia perceber assuntos relacionados ao produto, à operação e ao negócio, mantendo o detalhe necessário para agir sem perder a perspectiva macro.

A ferramenta não reduziu a quantidade de decisões das quais eu participava. Ela aumentou minha capacidade de acompanhar essas decisões com consistência.

“Ao transformar conversas e compromissos dispersos em uma visão acompanhável, o Radar me ajudou a ganhar previsibilidade, destravar dependências e priorizar com mais clareza.”

Enquanto o Radar resolvia uma parte importante da minha rotina, acompanhar melhor aquilo que já estava acontecendo, a segunda mudança exigia aprofundar a capacidade de descoberta e direção.

Com o uso de IA no desenvolvimento, os times começaram a ganhar velocidade. Ideias podiam ser prototipadas mais rapidamente, soluções chegavam à implementação em menos tempo e a capacidade de entrega aumentava.

Esse avanço era positivo, mas também criava um risco.

Roadmaps e backlogs são finitos. Se a capacidade de desenvolvimento cresce sem que a capacidade de descoberta evolua junto, o time pode apenas consumir mais rapidamente as oportunidades que já conhece. Depois disso, a velocidade deixa de ser uma vantagem e pode se transformar em um incentivo para manter as pessoas ocupadas.

Nesse cenário, gerar novas ideias não seria difícil. O problema seria separar ideias interessantes de oportunidades que realmente faziam sentido para o produto.

Eu não queria que a maior velocidade proporcionada pela IA nos levasse a criar soluções apenas porque agora conseguíamos construí-las mais rápido. Precisávamos aumentar também nossa capacidade de observar o mercado, interpretar sinais, cruzar evidências e relacionar oportunidades aos objetivos do negócio e à estratégia de produto.

A pergunta deixou de ser apenas:

“O que conseguimos construir agora?”

E passou a ser:

“Como garantimos que essa nova capacidade seja direcionada para construir as coisas certas?”

Foi a partir dessa preocupação que comecei a desenvolver a Inteligência de Mercado.

Analisar mercado e concorrentes sempre fez parte do meu trabalho como Product Manager. O problema era que esse trabalho normalmente acontecia de maneira pontual.

Quando surgia uma pergunta, era necessário procurar informações em diferentes fontes, reconstruir o histórico e comparar dados que nem sempre tinham a mesma natureza. Ao final, a análise representava bem aquele momento, mas começava a envelhecer assim que um produto mudava seus preços, lançava uma funcionalidade ou alterava seu posicionamento.

Eu queria transformar essa atividade episódica em uma capacidade contínua de produto.

Por isso, prefiro chamar a ferramenta de Inteligência de Mercado. A intenção nunca foi observar concorrentes por curiosidade ou reproduzir suas decisões. O objetivo era entender melhor o ambiente em que o Sexlog estava inserido e criar uma base mais sólida para identificar riscos, oportunidades e mudanças de comportamento.

A ferramenta reunia duas perspectivas complementares:

• uma leitura do mercado e de seus movimentos;

• uma análise estruturada dos produtos que disputavam necessidades semelhantes.

Uma visão estruturada dos concorrentes

Para cada produto acompanhado, a ferramenta construía um dossiê organizado em diferentes dimensões.

A primeira delas era o próprio produto. O benchmark identificava funcionalidades observáveis e as classificava por categorias como descoberta, perfis, mensageria, conteúdo, comunidade, eventos, segurança, mídia e monetização.

A análise ia além de registrar se uma feature existia. Ela buscava compreender como a experiência era organizada:

• quais mecanismos eram usados para descobrir pessoas e conteúdos;

• quais filtros estavam disponíveis;

• como funcionavam as interações e a mensageria;

• quais tipos de conteúdo e comunidade eram suportados;

• como o produto trabalhava localização e proximidade;

• quais recursos estimulavam retorno e engajamento;

• quais mecanismos de segurança e verificação eram apresentados;

• quais funcionalidades estavam disponíveis gratuitamente ou protegidas por uma assinatura.

Cada item também recebia um nível de certeza. Uma característica poderia estar confirmada por uma evidência direta, ser inferida a partir de sinais do produto ou permanecer inconclusiva. Isso evitava que uma suposição fosse apresentada com o mesmo peso de algo explicitamente observado.

Preço, monetização e distribuição de valor

Outra camada acompanhava os modelos de monetização.

A ferramenta estruturava os planos oferecidos, periodicidades, moedas, testes gratuitos, benefícios associados e funcionalidades restritas a cada modalidade. Snapshots permitiam perceber mudanças ao longo do tempo sem depender da memória ou de comparações manuais.

Essa leitura ajudava a responder perguntas como:

• qual lógica de monetização cada produto utilizava;

• onde apareciam os principais paywalls;

• quais capacidades eram utilizadas como argumento de assinatura;

• como o valor era distribuído entre versões gratuitas e pagas;

• se o modelo privilegiava recorrência, compras pontuais ou sistemas de créditos;

• quais mudanças de preço ou composição poderiam indicar uma nova estratégia.

O aspecto relevante não estava em reproduzir valores ou comparar empresas de maneira superficial. Estava em compreender como diferentes produtos transformavam suas propostas de valor em modelos de receita.

Marca e posicionamento

A Inteligência de Mercado também analisava como cada produto se apresentava.

A partir de páginas públicas e materiais institucionais, a IA estruturava elementos como mensagem principal, proposta de valor, tom de voz, públicos declarados, jobs to be done e padrões visuais.

Isso permitia comparar não apenas funcionalidades, mas as diferentes maneiras de interpretar o mesmo mercado.

Dois produtos podem oferecer recursos semelhantes e, ainda assim, competir a partir de promessas muito diferentes. Um pode enfatizar comunidade; outro, discrição. Um pode falar sobre liberdade; outro, segurança, exclusividade ou resultado.

Essa perspectiva ajudava a perceber espaços de posicionamento e entender quais necessidades estavam sendo disputadas além da interface.

Voz dos usuários dos concorrentes

Avaliações públicas em lojas de aplicativos, plataformas de reputação e comunidades abertas alimentavam uma camada de Voz do Cliente.

Agentes com IA classificavam os relatos por sentimento e temas recorrentes, como descoberta, matching, cobrança, suporte, segurança, privacidade, desempenho e experiência de uso.

O objetivo não era selecionar reclamações isoladas para confirmar uma opinião. A ferramenta buscava padrões:

• quais dores apareciam com maior frequência;

• quais eram compartilhadas por vários produtos;

• onde havia elogios consistentes;

• quais temas estavam piorando ou melhorando;

• quais problemas pareciam específicos de um produto;

• quais permaneciam sem uma boa resposta em todo o mercado.

Também mantive uma diferença importante entre volume e intensidade. Uma reclamação muito dura não representa necessariamente um problema amplo. Reviews públicas possuem viés de minoria vocal e precisavam ser interpretadas como sinal, não como verdade completa sobre a base de usuários.

Os textos passavam por cuidados de privacidade, com remoção de informações pessoais e preservação apenas de identificadores não reversíveis para autores externos.

Saúde, tração e sinais externos

Similarweb e Semrush complementavam a análise com estimativas de tráfego, canais de aquisição, presença orgânica, palavras-chave, autoridade e distribuição geográfica.

Esses números não eram tratados como dados exatos da operação de outra empresa. Serviam para comparar ordens de grandeza, trajetórias e mudanças de direção.

A ferramenta também observava indicadores públicos como:

• interesse de busca e sazonalidade;

• avaliações e atividade nas lojas de aplicativos;

• velocidade de publicação e atualização dos produtos;

• desempenho técnico de páginas;

• notícias, campanhas e anúncios públicos;

• lançamentos, parcerias e movimentos estratégicos divulgados;

• mudanças regulatórias ou macroeconômicas relevantes para o nicho.

A combinação desses sinais ajudava a construir uma leitura de momentum: não apenas o que um produto oferecia, mas se parecia avançar, perder força ou mudar sua forma de competir.

Limites éticos da pesquisa

Desde o início, estabeleci que inteligência competitiva não significava acesso irrestrito.

As rotinas automáticas trabalhavam com fontes públicas, dados licenciados ou ambientes explicitamente autorizados. Fontes classificadas como manuais não eram processadas automaticamente. A coleta considerava restrições de acesso e limites de frequência.

Quando era necessário compreender partes autenticadas da experiência, o benchmark era realizado de forma controlada, com conta própria e navegação somente para leitura. O protocolo não enviava formulários, não interagia com pessoas e não abria conversas ou perfis de terceiros. O interesse estava na estrutura da experiência, não no conteúdo ou na identidade dos usuários.

Essa separação era essencial. A ferramenta deveria criar inteligência para decisões de produto sem ultrapassar os limites de privacidade ou acesso de outros produtos.

Coletar mais informações não resolveria o problema por si só. Sem um processo de síntese, eu apenas trocaria a fragmentação de reuniões e conversas por uma nova fragmentação de dashboards e bases de dados.

O valor da Inteligência de Mercado estava na forma como as diferentes evidências eram cruzadas.

A geração de oportunidades utilizava um pipeline de IA dividido em diferentes estágios. Em vez de enviar todos os dados para um único prompt e esperar uma resposta, cada agente recebia uma responsabilidade específica.

Primeiro, verificar se havia contexto suficiente

A ferramenta mantinha um manifesto das fontes que deveriam alimentar o processo. Ele verificava se cada dimensão possuía dados, quando havia sido atualizada e se alguma parte da análise estava vazia ou desatualizada.

Isso tornava a cobertura auditável. Se uma fonte importante estivesse ausente, o sistema sinalizava que aquela lente estava incompleta em vez de produzir uma conclusão com aparência de certeza.

Depois, construir dossiês comparáveis

Um primeiro grupo de agentes sintetizava o material de cada concorrente em quatro perspectivas:

• forças sustentadas por evidências;

• fragilidades observadas, especialmente a partir da voz dos usuários;

• momentum ou trajetória percebida;

• o playbook estratégico que parecia orientar aquele produto.

Esses dossiês transformavam dados heterogêneos em uma estrutura comparável, preservando a ligação com os documentos e registros que sustentavam cada leitura.

Analisar o problema por diferentes lentes

Em seguida, agentes especializados geravam candidatos a oportunidade a partir de recortes diferentes.

Alguns analisavam dimensões específicas, como produto, engajamento, onboarding, segurança ou monetização. Outros observavam mercado, comportamento de busca e contexto macroeconômico.

Havia também uma lente dedicada ao próprio Sexlog, responsável por relacionar dores dos nossos usuários, dados de negócio, experimentos anteriores, estratégia e iniciativas que já estavam no roadmap.

Para reduzir o risco de produzir apenas ideias óbvias, criei outras três formas de raciocínio:

• uma lente combinatória, obrigada a cruzar pelo menos duas fontes que, isoladamente, não revelariam a mesma oportunidade;

• uma lente contrária, criada para desafiar premissas que o time poderia estar tratando como verdade;

• uma lente de horizonte, dedicada a apostas estruturais e movimentos que poderiam importar nos anos seguintes.

O dado governava o diagnóstico, mas a IA tinha espaço para explorar diferentes mecanismos de solução. A regra era que o problema não poderia ser inventado. A solução podia ser original, desde que suas premissas, riscos e formas de validação estivessem explícitos.

Sintetizar, confrontar e eliminar repetições

Um agente de síntese recebia os candidatos produzidos pelas diferentes lentes. Sua função era combinar propostas complementares, descartar as mais frágeis e eliminar ideias que representassem apenas versões diferentes da mesma tese.

O sistema também considerava:

• oportunidades já existentes;

• decisões anteriormente aprovadas ou rejeitadas;

• iniciativas presentes no roadmap;

• resultados de experimentos anteriores;

• dimensões prioritárias da estratégia.

Se uma nova tese fosse parecida com algo já conhecido, ela precisava explicitar qual era o avanço real: um novo segmento, um mecanismo diferente, outra causa para o problema ou uma mudança de sequenciamento. Reescrever uma ideia antiga não era suficiente.

Além dessa comparação com o histórico, similaridade semântica ajudava a encontrar duplicidades entre diferentes execuções.

Evidência obrigatória, inclusive contra a própria tese

Cada oportunidade precisava estar apoiada por evidências rastreáveis. A ferramenta preservava a relação entre a tese e os registros que a originaram: funcionalidades, benchmarks, reviews, sinais de mercado, dados próprios ou documentos internos autorizados.

Oportunidades sem evidência válida eram descartadas.

A síntese também precisava procurar contraevidências. Se um dado relevante enfraquecesse a tese, ele deveria aparecer junto com a explicação de por que a oportunidade ainda merecia ser considerada.

Depois da síntese, uma etapa de crítica verificava fontes não utilizadas e cruzamentos importantes que poderiam ter sido esquecidos. Uma auditoria adicional procurava inconsistências de negócio, como interpretar correlação como causalidade, usar amostras pequenas como se representassem toda a base ou dimensionar uma oportunidade a partir de uma métrica inadequada.

A intenção não era tornar a IA infalível. Era fazer com que suas limitações ficassem visíveis antes que uma sugestão chegasse a uma discussão de roadmap.

O resultado não era uma lista de ideias geradas por IA. Cada oportunidade era apresentada como um pequeno dossiê de decisão.

Ela precisava explicitar:

• o problema e o job do usuário;

• a hipótese de produto;

• as evidências que sustentavam o diagnóstico;

• a principal contraevidência;

• onde os concorrentes acertavam ou deixavam espaço;

• o timing de mercado;

• uma sugestão de iniciativa ou primeiro experimento;

• o impacto potencial;

• o esforço estimado;

• a confiança no diagnóstico;

• a força e a cobertura das evidências;

• a métrica de sucesso e uma meta sugerida;

• o tamanho do prêmio;

• o custo de não agir;

• premissas, riscos e dependências;

• o racional do esforço;

• o horizonte da oportunidade;

• o encaixe sugerido nos objetivos do negócio e no roadmap.

Impacto, esforço e confiança eram avaliados em uma escala comum. A prioridade era calculada pela relação:

“impacto × confiança ÷ esforço”

Confiança, nesse caso, não representava a certeza de que a solução funcionaria. Ela media o quanto o problema estava sustentado pelas evidências disponíveis.

Essa diferença permitia que uma aposta original tivesse incerteza sobre a solução sem ser confundida com uma tese baseada em um diagnóstico frágil.

Para apostas maiores, a ferramenta também exigia um sinal capaz de invalidar a hipótese em um período determinado. Assim, uma iniciativa ambiciosa não entrava apenas com uma narrativa inspiradora. Ela precisava declarar antecipadamente qual resultado mostraria que a aposta deveria ser interrompida ou revista.

O tamanho do prêmio relacionava a oportunidade a indicadores reais do negócio, enquanto o custo de não agir tornava explícita a consequência de manter o cenário atual. Já o encaixe sugerido conectava a tese aos objetivos e subobjetivos existentes, evitando que uma boa ideia surgisse desconectada da estratégia.

Mesmo com toda essa estrutura, nenhuma oportunidade entrava automaticamente no roadmap. Eu podia aprovar, rejeitar, registrar o motivo da decisão ou promover a tese para uma iniciativa.

Essa revisão humana também alimentava as próximas gerações. O sistema passava a conhecer o que já havia sido considerado, quais padrões de qualidade eu aprovava e quais caminhos não deveriam ser reapresentados sem uma evidência ou abordagem realmente nova.

A IA ampliava o espaço de análise e reduzia o trabalho necessário para conectar as fontes. A responsabilidade pela decisão continuava sendo minha.

“A ferramenta não foi criada para preencher o roadmap. Foi criada para aumentar a qualidade das escolhas que disputariam espaço nele.”

As duas ferramentas foram desenvolvidas com o Claude Code, mas seguiram arquiteturas diferentes porque resolviam problemas diferentes.

Meu ponto de partida não era uma tecnologia que eu queria experimentar. Era uma necessidade concreta da minha rotina. Eu descrevia o problema, definia como esperava que a ferramenta se comportasse e utilizava a IA para transformar essas regras em uma solução funcional.

O Claude Code acelerava a implementação, mas as decisões de produto continuavam comigo: quais fontes utilizar, quais informações eram relevantes, como os dados deveriam ser organizados, que erros precisavam ser evitados e onde a revisão humana era indispensável.

Radar do PM: conectando minha rotina de trabalho

No Radar do PM, utilizei integrações autorizadas com ferramentas como Slack, Google Drive e Gmail.

Essas fontes representavam lugares diferentes onde compromissos e decisões apareciam:

• reuniões e documentos no Drive;

• discussões, pedidos e threads no Slack;

• mensagens e acompanhamentos no Gmail;

• tarefas registradas manualmente por mim.

A partir dessas integrações, agentes identificavam assuntos que exigiam minha participação, extraíam próximos passos e consolidavam itens relacionados.

O desafio não era simplesmente resumir mensagens. Era transformar informações não estruturadas em algo que pudesse ser acompanhado.

Para isso, precisei definir regras como:

• reconhecer quando uma tarefa estava atribuída a mim;

• separar uma informação de uma ação necessária;

• identificar quando dois registros falavam sobre o mesmo assunto;

• distinguir o que dependia de mim do que estava aguardando terceiros;

• atribuir prioridade sem transformar toda menção em urgência;

• preservar itens adicionados manualmente;

• manter o estado do que já havia sido resolvido entre as atualizações.

Essas regras foram essenciais para que o Radar não se transformasse em mais uma fonte de ruído.

A IA funcionava como uma camada de leitura e organização sobre ferramentas que já faziam parte da minha rotina. O resultado era uma interface simples, mas alimentada por um processo capaz de reunir informações dispersas e manter o contexto atualizado.

Inteligência de Mercado: conectando mercado, produto e negócio

A Inteligência de Mercado exigiu uma arquitetura mais ampla.

Criei crawlers e agentes com rotinas direcionadas de pesquisa. Para cada concorrente acompanhado, eu fornecia as URLs relevantes e definia quais dimensões deveriam ser observadas.

Esses agentes buscavam e estruturavam informações sobre produto, funcionalidades, monetização, posicionamento, percepção dos usuários e movimentos públicos do mercado. A coleta não era uma busca aberta sem objetivo. Cada rotina respondia a perguntas e critérios previamente definidos.

A ferramenta também precisava compreender profundamente o próprio Sexlog. Sem esse contexto, qualquer análise competitiva correria o risco de produzir recomendações genéricas ou desconectadas da realidade do produto.

Por isso, organizei as fontes em duas grandes perspectivas.

Contexto externo

O contexto externo reunia:

• páginas e experiências observáveis dos produtos analisados;

• dados de tráfego e canais de aquisição do Similarweb;

• informações de busca, presença orgânica e autoridade do Semrush;

• avaliações públicas e feedbacks sobre produtos do nicho;

• interesse de busca, notícias, tendências e movimentos públicos de mercado.

Contexto interno

O contexto interno conectava:

• feedbacks dos usuários do Sexlog, utilizados como um termômetro contínuo de percepção e NPS;

• dados do Cortex, a central de inteligência da empresa, que mantinha o contexto do produto, da estratégia e das iniciativas em andamento;

• dados e métricas do Sexlog vindos do Snowflake;

• objetivos do negócio, direcionadores estratégicos e iniciativas presentes no roadmap, todos materiais que eu já produzia no exercício da minha atuação como PM e que também passaram a funcionar como insumos para a Inteligência de Mercado.

Esse contexto estratégico era anterior à ferramenta. Eu já estruturava a visão do produto, os direcionadores, as prioridades e as iniciativas que orientavam o trabalho dos times.

A Inteligência de Mercado passou a utilizar esse material para interpretar os sinais coletados e avaliar se uma oportunidade fazia sentido para a direção que eu havia definido.

Essa distinção era importante: a IA não criava a estratégia do Sexlog. Ela utilizava o contexto estratégico produzido por mim para encontrar conexões, expor lacunas, questionar premissas e sugerir onde uma oportunidade poderia se encaixar.

Assim, o sistema não analisava apenas o que seria possível construir. Ele confrontava cada tese com aquilo que o produto e o negócio já estavam tentando alcançar.

Essa separação também permitia que a IA não olhasse para o mercado de forma isolada. Uma tendência externa só ganhava relevância quando encontrava uma dor, uma oportunidade ou um objetivo real do Sexlog.

Uma arquitetura de contexto antes da geração

O fluxo da Inteligência de Mercado pode ser resumido em cinco camadas:

1. 01.

   Coleta: crawlers, APIs e integrações acessavam as fontes autorizadas.

2. 02.

   Estruturação: os dados eram normalizados em dimensões comparáveis.

3. 03.

   Contextualização: informações externas eram relacionadas ao estado atual do Sexlog.

4. 04.

   Síntese: agentes especializados formulavam e confrontavam teses de oportunidade.

5. 05.

   Decisão: eu revisava as evidências, aprovava, rejeitava ou conectava uma oportunidade ao roadmap.

Esse desenho evitava pedir diretamente a uma IA que gerasse ideias para o Sexlog. Sem contexto, esse tipo de comando tende a produzir respostas genéricas, difíceis de diferenciar de um brainstorming comum.

Primeiro, eu construí uma base capaz de explicar:

• o que estava acontecendo no mercado;

• como produtos comparáveis estavam se movimentando;

• o que seus usuários valorizavam ou rejeitavam;

• qual era a situação atual do Sexlog;

• quais dores nossos usuários estavam relatando;

• o que já havia sido testado;

• quais iniciativas estavam planejadas;

• quais objetivos o negócio precisava mover.

Somente depois disso os agentes eram convidados a formular oportunidades.

“Antes de pedir boas respostas à IA, eu precisava construir o contexto necessário para que ela fizesse perguntas melhores.”

Meu papel na construção

Embora o Claude Code tenha sido utilizado para implementar as ferramentas, meu trabalho não se limitou a solicitar telas ou funcionalidades.

Atuei na definição do sistema:

• transformei problemas da minha rotina em requisitos;

• determinei quais fontes eram confiáveis e autorizadas;

• desenhei as dimensões de análise;

• defini os critérios de classificação e priorização;

• estabeleci regras contra duplicidade e alucinação;

• determinei quando a evidência era insuficiente;

• criei limites para privacidade e exposição de dados;

• conectei as análises aos objetivos do produto;

• mantive a decisão final sob responsabilidade humana.

A IA acelerou a transformação dessas decisões em software. Mas foi o conhecimento do produto, do negócio e da rotina de Product Management que definiu o que deveria ser construído.

Isso também mudou minha relação com a criação de ferramentas internas. Eu não precisava esperar que um problema individual competisse por espaço no roadmap de um time de desenvolvimento para começar a resolvê-lo.

Com IA, consegui prototipar sistemas adaptados ao meu próprio contexto, utilizá-los em situações reais e evoluí-los conforme novas necessidades apareciam.

“Eu não comecei pela pergunta “o que consigo construir com IA?”. Comecei pelos pontos da minha rotina em que mais contexto poderia melhorar a qualidade do meu trabalho.”

O principal impacto da Inteligência de Mercado não apareceu na quantidade de dados coletados ou de oportunidades geradas. Ele apareceu na qualidade das discussões que esses dados passaram a provocar.

Ao confrontar percepções históricas com diferentes fontes de evidência, a ferramenta ajudou a questionar vieses antigos e culturais da empresa. Premissas que haviam se consolidado ao longo dos anos podiam ser revisitadas a partir do comportamento dos usuários, de indicadores do negócio e de mudanças observadas no mercado.

Isso não significava que toda crença anterior estava errada. Significava que ela deixava de ser aceita apenas porque sempre havia orientado as decisões.

A estrutura das oportunidades também aumentou a assertividade das apostas. Em vez de chegar ao roadmap apenas como uma ideia ou uma solução desejável, cada tese precisava explicar o problema, as evidências, o impacto esperado, o esforço, as premissas, os riscos e a forma de medir o resultado.

Essa mudança melhorava a qualidade da conversa antes mesmo de qualquer desenvolvimento começar.

O time podia discutir não apenas se uma proposta parecia interessante, mas:

• se o problema estava suficientemente comprovado;

• se a oportunidade tinha relação com a estratégia;

• se o tamanho do prêmio justificava o investimento;

• quais riscos o produto e o negócio assumiriam;

• qual seria o custo de não agir;

• que evidência poderia invalidar a aposta;

• o que precisaríamos aprender antes de aumentar o investimento.

Ao tornar essas dimensões explícitas, a ferramenta ajudava a diminuir o risco de decisões orientadas apenas por urgência, opinião ou entusiasmo com uma solução.

Encontrando o que análises triviais não mostravam

Outro ganho importante foi a identificação de blind spots.

Uma análise tradicional de concorrentes poderia terminar em uma matriz de funcionalidades: quem possui determinada feature, quanto cobra e como organiza seus planos. Esse tipo de comparação era útil, mas insuficiente.

Os pontos mais relevantes muitas vezes apareciam nos cruzamentos.

Uma mudança de comportamento de busca poderia ganhar outro significado quando relacionada a reclamações recorrentes. Uma diferença de monetização poderia revelar uma oportunidade quando confrontada com dados próprios de conversão ou retenção. Uma funcionalidade presente em vários produtos poderia parecer uma necessidade de paridade, mas a voz dos usuários mostrar que ninguém havia resolvido bem o problema por trás dela.

Ao combinar lentes diferentes, a Inteligência de Mercado trouxe para discussão assuntos que ainda não haviam sido formulados dentro da empresa.

Alguns não estavam no backlog porque não eram visíveis a partir das fontes que utilizávamos normalmente. Outros estavam escondidos por premissas antigas ou apareciam fragmentados em análises que nunca haviam sido relacionadas.

A ferramenta não apenas respondia perguntas. Em muitos momentos, ela ajudava a descobrir perguntas que ainda não estávamos fazendo.

Mais preparo diante dos movimentos do mercado

O acompanhamento contínuo também aumentava nossa capacidade de perceber riscos externos.

Mudanças de posicionamento, monetização, aquisição, produto ou percepção dos usuários podiam ser avaliadas em conjunto, sem depender de uma observação isolada. Isso nos ajudava a entender quais movimentos realmente mereciam atenção e quais eram apenas ruído.

O objetivo não era reagir automaticamente a tudo o que outro produto fazia. Reagir dessa forma seria permitir que os concorrentes determinassem nosso roadmap.

A intenção era compreender se determinado movimento alterava uma dinâmica relevante do mercado, ameaçava uma vantagem do Sexlog ou revelava uma necessidade que também existia para nossos usuários.

Essa leitura ajudava a proteger o produto e o negócio sem transformar acompanhamento competitivo em imitação.

O resultado foi mais clareza para decidir

A Inteligência de Mercado trouxe mais clareza sobre oportunidades reais de produto e de negócio.

Ela ajudava a distinguir:

• um movimento de mercado de uma tendência relevante;

• uma reclamação isolada de uma dor recorrente;

• uma feature popular de um problema que valia resolver;

• uma ideia interessante de uma oportunidade alinhada à estratégia;

• uma aposta ousada de uma aposta sem critérios;

• uma reação ao concorrente de uma decisão que fazia sentido para o Sexlog.

Nem toda oportunidade gerada deveria avançar. Esse nunca foi o objetivo.

O valor estava em aumentar a qualidade do material sobre o qual as decisões eram tomadas, trazer perspectivas que antes permaneciam fora das discussões e reduzir o risco de acelerar na direção errada.

“A Inteligência de Mercado não eliminava a incerteza. Ela tornava mais visíveis as evidências, premissas e riscos que precisávamos considerar antes de decidir.”

O Radar do PM e a Inteligência de Mercado nasceram em momentos diferentes e resolviam problemas distintos, mas faziam parte da mesma evolução na minha maneira de trabalhar com IA.

O Radar protegia minha atenção.

Ele reduzia o risco de perder compromissos, deixava dependências visíveis, dava mais solidez aos prazos e ampliava minha capacidade de acompanhar simultaneamente produto, operação e negócio.

A Inteligência de Mercado protegia a direção.

Ela reduzia o risco de transformar velocidade em produção sem propósito, confrontava vieses, estruturava apostas e ampliava nossa capacidade de identificar oportunidades relevantes.

Uma ferramenta me ajudava a não perder de vista o que já estava em movimento. A outra ajudava a questionar o que deveria entrar em movimento a seguir.

Construir essas ferramentas também reforçou um princípio importante para mim: a qualidade da resposta de uma IA depende diretamente da qualidade do contexto, das regras e das perguntas que construímos ao redor dela.

Sem contexto, a IA tende a produzir generalidades. Sem critérios, pode transformar correlações em certezas. Sem evidências, pode criar narrativas convincentes para problemas que não existem. Sem revisão humana, pode priorizar algo plausível, mas incompatível com a realidade do produto e do negócio.

Por isso, nas duas ferramentas, meu papel não terminou quando a primeira versão começou a funcionar.

Eu continuei responsável por definir os problemas, selecionar as fontes, criar limites, avaliar evidências, revisar resultados e decidir o que deveria acontecer a partir deles.

A IA assumia parte do trabalho de encontrar, organizar, relacionar e sintetizar informações. O julgamento permanecia humano.

O principal ganho não foi simplesmente conseguir construir duas ferramentas internas com mais rapidez. Foi criar novas capacidades para meu próprio trabalho como Product Manager.

Uma delas aumentava minha capacidade operacional. A outra aumentava minha capacidade de descoberta e decisão.

“Ganhar velocidade com IA não deveria significar apenas executar mais rápido. Para mim, significava também acompanhar melhor e escolher com mais clareza.”