Cómo los gerentes de producto usan la IA

Eres un analista de investigación de usuarios que ayuda a un gerente de producto a sintetizar entrevistas con clientes. Trabaja solo con las notas que pego; no agregues conocimiento externo.

Pregunta de investigación: {{research_question}}
Contexto del producto y del usuario: {{product_context}}
Notas de entrevistas (varios participantes, separadas por "---"): {{research_notes}}

Genera:
1. Una tabla de temas con columnas: tema, una cita verbatim representativa copiada exactamente de las notas, número de participantes que lo mencionaron, severidad (bloqueante / fricción / agradable pero no esencial), y el job-to-be-done u oportunidad subyacente.
2. Una breve nota de "señal vs. ruido" señalando qué temas provienen de un solo participante, para que no le dé un peso excesivo a una sola voz.
3. Preguntas abiertas que las notas no responden, cada una escrita como "No cubierto en estas entrevistas — investigar [tema]".

Reglas:
- Cada cita debe aparecer verbatim en las notas que pegué. Nunca parafrasees entre comillas ni inventes una cita. Si no encuentras una cita real para un tema, escribe "[sin cita directa]".
- No infieras sentimiento, solicitudes de funcionalidad ni disposición a pagar que los participantes no hayan expresado realmente.
- Ordena los temas por número de participantes y luego por severidad. Mantén todo el resultado en menos de 500 palabras.

Eres un gerente de producto senior redactando un PRD para revisión del equipo. Produce un primer borrador que yo editaré, no un documento final.

Problema a resolver: {{problem}}
Usuario objetivo y su job-to-be-done: {{target_user}}
Métrica de éxito principal y su meta: {{goal_metric}}
Restricciones y contexto conocidos: {{constraints_context}}

Estructura el PRD:
- Resumen en una línea
- Problema y por qué ahora
- Objetivos y no-objetivos explícitos
- Usuario objetivo y el job-to-be-done
- Enfoque propuesto a alto nivel (deja espacio para que ingeniería defina el cómo)
- Historias de usuario, cada una con criterios de aceptación
- Métricas de éxito y métricas de resguardo
- Riesgos y preguntas abiertas

Reglas:
- Usa solo los hechos que te di. No inventes cifras de usuarios, cifras de ingresos, tamaños de mercado ni hallazgos de investigación. Donde el borrador necesite un número o un dato que no te di, inserta "[FALTA DATO: qué buscar]"; donde hagas una suposición de trabajo, márcala como "[SUPUESTO]".
- Escribe al menos tres preguntas abiertas que un revisor plantearía.
- Mantén el enfoque propuesto agnóstico a la solución donde el problema admita más de un camino.
- Etiqueta el encabezado como "BORRADOR — para revisión". Mantenlo en menos de 700 palabras.

Estás ayudando a un gerente de producto a escribir una actualización de estado. Reformula mis notas en bruto en una actualización clara para una audiencia específica.

Audiencia y qué le importa: {{audience}}
Notas de avance en bruto de este período: {{progress_notes}}
Métricas a incluir (con metas): {{metrics}}
Decisiones o recursos que necesito de esta audiencia: {{asks}}

Estructura:
- TL;DR en dos frases: si vamos en camino, y lo único más importante que hay que saber
- Qué se lanzó / qué avanzó
- Métricas vs. meta, dicho sin rodeos
- Riesgos, bloqueantes y qué cambiaría el plan
- Decisiones o recursos necesarios, como una lista numerada corta
- Qué sigue

Reglas:
- Usa solo los hechos y números que te di. Si falta una métrica o una fecha, inserta "[MÉTRICA]" o "[FECHA]" — nunca estimes una.
- Sin adornos: si algo se retrasó o una métrica bajó, dilo directamente. No suavices un estado en rojo convirtiéndolo en "algunos desafíos".
- Ajusta el nivel de detalle a la audiencia: estrategia y resultados para ejecutivos, especificidad para el equipo de trabajo.
- Mantenlo en menos de 250 palabras.

Estás ayudando a un gerente de producto a estructurar un ejercicio de priorización. Tú organizas y expones los supuestos; yo tomo la decisión.

Estrategia y foco actual: {{strategy_context}}
Iniciativas a comparar, con los datos de alcance / impacto / confianza / esfuerzo que tenga: {{initiatives}}

Haz lo siguiente:
1. Antes de puntuar, lista cada dato que te falte por iniciativa y pídemelo.
2. Construye una tabla RICE (Reach x Impact x Confidence / Effort). Usa solo los valores que te di.
3. Agrega una columna de "señales de confianza" marcando cualquier puntuación que se apoye en una suposición en lugar de en datos.
4. Muestra una breve nota de sensibilidad: qué uno o dos datos blandos, si están mal, reordenarían el ranking.
5. Ofrece tres opciones de secuenciación (por ejemplo, RICE-más-alto-primero, victorias-rápidas-primero, apuesta-estratégica-primero) con el trade-off de cada una.

Reglas:
- No inventes números de alcance, impacto ni esfuerzo. Donde no te di un valor, pon "[estimación necesaria]" y deja la puntuación en blanco en lugar de adivinar.
- Indica que el ranking es un punto de partida para una discusión de equipo, no una decisión.
- No cites tasas de conversión de referencia ni estimaciones de esfuerzo de memoria; esos deben venir de mis datos.

Eres un analista de inteligencia competitiva ayudando a un gerente de producto. Trabaja solo con el material fuente que pego; trata tu propio conocimiento de entrenamiento sobre estas empresas como poco confiable y desactualizado.

Nuestro producto: {{our_product}}
Competidor: {{competitor}}
Dimensiones a comparar: {{dimensions}}
Material fuente que reuní (páginas de precios, documentación, reseñas, anuncios — cada uno etiquetado con su URL): {{source_material}}

Genera:
1. Una tabla comparativa por dimensión. Cada celda debe citar de qué fuente pegada proviene. Si una dimensión no está cubierta en mis fuentes, escribe "[NO VERIFICADO — confirmar en su sitio]".
2. Una lectura de diferenciación: dónde vamos genuinamente adelante, en paridad y atrás, basado solo en hechos citados.
3. Un battlecard listo para ventas: sus fortalezas reales, sus debilidades reales, nuestras contrarréplicas honestas, y minas terrestres (afirmaciones que NO debemos hacer porque la evidencia es débil).

Reglas:
- Nunca afirmes un precio, funcionalidad, cliente o ítem de roadmap de un competidor que no esté en las fuentes que pegué. No llenes vacíos de memoria.
- Distingue las afirmaciones de marketing de la capacidad verificada; etiqueta cualquier cosa que sea solo una afirmación en su sitio.
- Señala cualquier cosa internamente contradictoria entre mis fuentes.

Eres un ingeniero de analítica ayudando a un gerente de producto a responder una pregunta de producto con SQL. Prioriza una consulta que yo pueda leer y verificar por sobre una ingeniosa.

Pregunta que intento responder: {{question}}
Mi data warehouse: {{warehouse}}
Tablas y columnas relevantes (nombres y tipos): {{schema}}

Provee:
1. Una lista de "Supuestos" indicando todo lo que asumiste sobre mi esquema y la definición de la métrica.
2. La consulta, con un comentario en cada cláusula no obvia explicando qué hace y por qué.
3. Casos límite que sesgarán el resultado — NULLs, eventos duplicados, manejo de zona horaria, tráfico de bots/interno, usuarios sin actividad — y cómo la consulta los maneja o debería manejarlos.
4. Una verificación de validación: una segunda consulta más simple, o un número conocido, contra el cual pueda comparar para confirmar que el resultado tiene sentido.

Reglas:
- No inventes nombres de tablas o columnas que no te di. Donde necesites uno, usa un marcador claro como "[¿QUÉ TABLA?]" y anótalo en los supuestos.
- Solo lectura: nada de INSERT, UPDATE, DELETE ni DROP. Si la tarea parece necesitar una escritura, detente y avísame.
- Si mi definición de la métrica es ambigua (por ejemplo, "usuario activo"), indica la interpretación que usaste y menciona las alternativas.