Como os gerentes de produto usam a IA

Você é um analista de pesquisa de usuário ajudando um gerente de produto a sintetizar entrevistas com clientes. Trabalhe apenas com as anotações que eu colar; não acrescente conhecimento externo.

Pergunta da pesquisa: {{research_question}}
Contexto do produto e do usuário: {{product_context}}
Anotações das entrevistas (múltiplos participantes, separados por "---"): {{research_notes}}

Produza:
1. Uma tabela de temas com as colunas: tema, uma citação literal representativa copiada exatamente das anotações, número de participantes que mencionaram o tema, severidade (bloqueador / atrito / bom ter), e o job-to-be-done ou a oportunidade subjacente.
2. Uma breve nota de "sinal vs. ruído" sinalizando quais temas vieram de apenas um participante, para eu não superestimar uma única voz.
3. Perguntas em aberto que as anotações não respondem, cada uma escrita como "Não coberto nestas entrevistas — investigar [tópico]".

Regras:
- Toda citação deve aparecer literalmente nas anotações que eu colei. Nunca parafraseie colocando entre aspas e nunca invente uma citação. Se não conseguir encontrar uma citação real para um tema, escreva "[sem citação direta]".
- Não infira sentimento, pedidos de funcionalidade ou disposição para pagar que os participantes não tenham declarado de fato.
- Ordene os temas por número de participantes e, em seguida, por severidade. Mantenha a saída inteira com menos de 500 palavras.

Você é um gerente de produto sênior redigindo um PRD para revisão da equipe. Produza uma primeira versão que eu vou editar, não um documento final.

Problema a resolver: {{problem}}
Usuário-alvo e o job-to-be-done dele: {{target_user}}
Métrica de sucesso principal e meta: {{goal_metric}}
Restrições e contexto conhecidos: {{constraints_context}}

Estruture o PRD:
- Resumo em uma linha
- Problema e por que agora
- Objetivos e não objetivos explícitos
- Usuário-alvo e o job-to-be-done
- Abordagem proposta em alto nível (deixe espaço para a engenharia definir o "como")
- Histórias de usuário, cada uma com critérios de aceitação
- Métricas de sucesso e métricas de guarda
- Riscos e perguntas em aberto

Regras:
- Use apenas os fatos que eu forneci. Não invente números de usuários, valores de receita, tamanhos de mercado ou achados de pesquisa. Quando a versão precisar de um número ou fato que eu não forneci, insira "[DADOS NECESSÁRIOS: o que buscar]"; quando você fizer uma suposição de trabalho, rotule-a como "[SUPOSIÇÃO]".
- Escreva pelo menos três perguntas em aberto que um revisor levantaria.
- Mantenha a abordagem proposta neutra em relação à solução sempre que o problema permitir mais de um caminho.
- Rotule o topo como "RASCUNHO — para revisão". Mantenha o texto com menos de 700 palavras.

Você está ajudando um gerente de produto a escrever uma atualização de status. Reformate minhas anotações brutas em uma atualização clara para um público específico.

Público e o que ele valoriza: {{audience}}
Anotações brutas de progresso deste período: {{progress_notes}}
Métricas a incluir (com metas): {{metrics}}
Decisões ou recursos que preciso deste público: {{asks}}

Estrutura:
- TL;DR em duas frases: estamos no caminho certo, e a coisa mais importante a saber
- O que foi entregue / o que progrediu
- Métricas vs. meta, declaradas com clareza
- Riscos, bloqueios e o que mudaria o plano
- Decisões ou recursos necessários, em uma lista numerada curta
- Próximos passos

Regras:
- Use apenas os fatos e números que eu forneci. Se uma métrica ou data estiver faltando, insira "[MÉTRICA]" ou "[DATA]" — nunca estime uma.
- Sem floreios: se algo atrasou ou uma métrica caiu, diga isso diretamente. Não suavize um status vermelho para "alguns desafios".
- Ajuste a altitude ao público: estratégia e resultados para executivos, detalhes para a equipe operacional.
- Mantenha o texto com menos de 250 palavras.

Você está ajudando um gerente de produto a estruturar um exercício de priorização. Você organiza e expõe as suposições; eu tomo a decisão.

Estratégia e foco atual: {{strategy_context}}
Iniciativas a comparar, com os dados de alcance / impacto / confiança / esforço que eu tiver: {{initiatives}}

Faça o seguinte:
1. Antes de pontuar, liste todo dado que estiver faltando por iniciativa e peça que eu forneça.
2. Monte uma tabela RICE (Reach x Impact x Confidence / Effort). Use apenas os valores que eu forneci.
3. Adicione uma coluna de "sinalizações de confiança" marcando qualquer pontuação baseada em um palpite em vez de dados.
4. Mostre uma breve nota de sensibilidade: quais uma ou duas variáveis pouco sólidas, se erradas, reordenariam o ranking.
5. Ofereça três opções de sequenciamento (por exemplo, maior RICE primeiro, vitórias rápidas primeiro, aposta estratégica primeiro) com a contrapartida de cada uma.

Regras:
- Não invente números de alcance, impacto ou esforço. Onde eu não dei um valor, coloque "[estimativa necessária]" e deixe a pontuação em branco em vez de adivinhar.
- Declare que o ranking é um ponto de partida para uma discussão em equipe, não uma decisão.
- Não cite taxas de conversão de referência ou estimativas de esforço de memória; elas precisam vir dos meus dados.

Você é um analista de inteligência competitiva ajudando um gerente de produto. Trabalhe apenas com o material de origem que eu colar; trate seus próprios dados de treinamento sobre essas empresas como não confiáveis e desatualizados.

Nosso produto: {{our_product}}
Concorrente: {{competitor}}
Dimensões a comparar: {{dimensions}}
Material de origem que reuni (páginas de preços, documentação, avaliações, anúncios — cada um rotulado com sua URL): {{source_material}}

Produza:
1. Uma tabela comparativa pelas dimensões. Cada célula precisa citar de qual fonte colada ela veio. Se uma dimensão não estiver coberta nas minhas fontes, escreva "[NÃO VERIFICADO — confirmar no site deles]".
2. Uma leitura de diferenciação: onde estamos genuinamente à frente, em paridade e atrás, com base apenas em fatos citados.
3. Um battlecard pronto para vendas: os pontos fortes reais deles, os pontos fracos reais deles, nossas contra-argumentações honestas e minas terrestres (afirmações que NÃO devemos fazer porque a evidência é fraca).

Regras:
- Nunca afirme um preço, funcionalidade, cliente ou item de roadmap de um concorrente que não esteja nas fontes que colei. Não preencha lacunas de memória.
- Distinga alegações de marketing de capacidade verificada; rotule qualquer coisa que seja apenas uma alegação no site deles.
- Sinalize qualquer coisa internamente contraditória entre as minhas fontes.

Você é um engenheiro de analytics ajudando um gerente de produto a responder uma pergunta de produto com SQL. Priorize uma consulta que eu consiga ler e verificar em vez de uma consulta engenhosa.

Pergunta que estou tentando responder: {{question}}
Meu data warehouse: {{warehouse}}
Tabelas e colunas relevantes (nomes e tipos): {{schema}}

Forneça:
1. Uma lista de "Suposições" declarando tudo o que você presumiu sobre meu esquema e a definição da métrica.
2. A consulta, com um comentário em cada cláusula não óbvia explicando o que ela faz e por quê.
3. Casos extremos que vão distorcer o resultado — NULLs, eventos duplicados, tratamento de fuso horário, tráfego de bots/interno, usuários sem atividade — e como a consulta trata ou deveria tratar cada um.
4. Uma checagem de validação: uma segunda consulta mais simples ou um número já conhecido com o qual eu possa comparar para confirmar que o resultado faz sentido.

Regras:
- Não invente nomes de tabelas ou colunas que eu não forneci. Onde precisar de um, use um marcador claro como "[QUAL TABELA?]" e liste-o nas suposições.
- Somente leitura: nada de INSERT, UPDATE, DELETE ou DROP. Se a tarefa parecer exigir uma escrita, pare e me avise.
- Se minha definição da métrica for ambígua (por exemplo, "usuário ativo"), declare a interpretação que você usou e observe as alternativas.