Un PRD escrito a partir de una idea de una sola línea es pura ficción con cara de seguridad: tapa cada hueco con una suposición que suena bien y te deja un documento que parece terminado. Esta plantilla se niega a escribir hasta poner nombre a lo que no sabes: te entrevista por las piezas que faltan, le pone tope a las preguntas para que no la abandones a mitad de camino, y te exige una línea de corte de v1 que dice exactamente qué sale primero. Cópiala, ajusta las variables y deja de revisar PRDs montados sobre supuestos que nunca hiciste.
En resumen
- El defecto de fábrica de cualquier prompt de «escríbeme un PRD» es que el modelo nunca pregunta. Se inventa el usuario, la métrica y el alcance, y los deja escritos como si fueran verdad.
- Se arregla dándole vuelta al orden: el prompt primero entrevista, después escribe, y le pone tope a las preguntas (cinco es el número justo) para que de verdad llegues al final de la entrevista.
- Las secciones que no se tocan son No-metas y la línea de corte de v1. Son las que la gente borra y después lamenta, porque son las únicas que te obligan a entregar menos.
- Haz que el modelo te devuelva tus propias respuestas flojas en lugar de maquillarlas por debajo. Una ambigüedad señalada es una decisión que todavía te toca tomar a ti.
- Es una plantilla, no magia: dale un brief de un párrafo y se pone fino; dale una sola línea y va a tener que preguntar más.
La mayoría de los prompts de PRD producen ficción con cara de seguridad. Escribes "escríbeme un PRD para una función de notificaciones", el modelo rellena el usuario, la métrica de éxito y el alcance con la suposición más genérica que tiene a mano, y te devuelve un documento que se lee terminado pero que está armado entero sobre supuestos que tú nunca hiciste. La solución no es un mejor modelo. Es un prompt que se niega a escribir hasta que le pongas nombre a lo que no sabes. Abajo tienes la plantilla completa, luego cómo adaptarla, las variables que se cambian, algunas variantes, y los detalles a cuidar para que de verdad funcione.
01 · La plantilla
Esto es todo. Pégala en Claude Code (o en cualquier chat decente) como tu primer mensaje, cambia los dos placeholders entre corchetes, y deja que te entreviste antes de escribir una sola palabra.
Eres un product manager senior escribiendo un documento de requerimientos de
producto (PRD).
CONTEXTO (de mi parte):
- Idea: [UNA O DOS FRASES: qué quieres que se construya]
- Audiencia del documento: [QUIÉN LO LEE, p. ej. fundador en solitario,
equipo de ingeniería, un cliente]
REGLAS:
1. NO escribas el PRD todavía. Primero, hazme hasta 5 preguntas, solo
aquellas cuya respuesta cambiaría el documento. Prioriza, en este orden:
a. El usuario y cómo se las arregla HOY (¿qué hace sin esto?).
b. La ÚNICA métrica que nos dice que la v1 funcionó (un número, no una
sensación).
c. Qué queda explícitamente FUERA del alcance de la v1.
d. La restricción dura: fecha límite, presupuesto, plataforma, o una
dependencia que no controlas.
e. El supuesto más arriesgado: lo que, si está mal, hunde la idea.
2. Haz todas las preguntas en un solo mensaje, numeradas. Luego DETENTE y
espera.
3. Si respondo "no sé" o me quedo en lo vago, no te inventes una respuesta.
Pásala al PRD como Pregunta abierta y márcala.
CUANDO YA HAYA RESPONDIDO, escribe el PRD con exactamente estas secciones:
- Problema (2-3 frases, ancladas en cómo se las arregla hoy)
- Usuario objetivo (un usuario principal; nombra el trabajo que necesita
resolver)
- Metas (cada meta con su única métrica de éxito medible)
- No-metas (qué NO vamos a hacer a propósito en la v1, y por qué)
- Historias de usuario (3-6, en formato "Como X, quiero Y, para Z")
- Restricciones (los límites duros de arriba)
- Preguntas abiertas (lo que siga sin resolver, sé honesto)
- Línea de corte de v1: una división en dos columnas, "Sale en v1" vs
"Después", que muestre la rebanada más pequeña que podríamos poner frente
a un usuario real.
RESTRICCIONES SOBRE TU SALIDA:
- Que todo el PRD no pase de 600 palabras. Conciso le gana a exhaustivo.
- Después de cada sección, si algún dato detrás de ella iba flojo, agrega una
línea: "Supuesto, confirmar: <lo que asumiste>".
- Nada de lenguaje de marketing. Nada de "revolucionario", "sin fricción",
"robusto". Solo afirmaciones claras y falsables.
Consejo
La línea que más rinde es la regla 1b: "un número, no una sensación". Sin ella, el modelo escribe metas como "mejorar el engagement del usuario", que no es falsable y por lo tanto no sirve para nada. Con ella te obligas a comprometerte con algo que después puedas verificar.
02 · Por qué entrevistar primero le gana a escribir primero
Un PRD es decisiones comprimidas. Cuando el modelo escribe primero, toma esas decisiones por ti en silencio y solo te enteras al revisar, y normalmente ya alguien empezó a construir sobre ellas. Darle vuelta al orden mueve las decisiones al momento más barato posible: una pregunta que respondes en diez segundos.
Tres cosas que la entrevista arregla de raíz:
- El usuario fantasma. "Escríbeme un PRD para un dashboard" no trae usuario por ningún lado. El modelo va a elegir uno promedio. Preguntar por cómo se las arregla hoy (regla 1a) mete a una persona real en el documento, y eso suele ser una especificación más honesta que cualquier cosa que hubieras escrito tú.
- La métrica de sensación. Si lo dejas a su aire, el modelo se va a criterios de éxito blanditos. La pregunta de la métrica ancla el documento a algo medible, que es la única parte de un PRD que después te dice si tenías razón.
- La expansión silenciosa del alcance. Al modelo le da igual mantener la v1 pequeña. A ti no. Las secciones de No-metas y línea de corte (van enseguida) son donde lo recuperas.
Nota
Es el mismo instinto que hay detrás de herramientas como Proyección, donde lo que sirve es modelar al otro lado antes de actuar, en vez de lanzarte con un guion que suena bien. Un prompt de PRD que te entrevista te está modelando los huecos de tu propio razonamiento.
03 · Las dos secciones que la gente borra (y no debería)
Si recortas la plantilla, estas dos secciones son las que tienen que sobrevivir. Todo lo demás se recupera; estas no.
No-metas
Las No-metas no son por cortesía. Son el muro de carga. Una meta le dice al modelo y a tu yo del futuro qué construir; una no-meta les dice qué rechazar, que es la instrucción más difícil y más valiosa. La primera vez que alguien del equipo te diga "¿y no podemos meter también…?", la sección de No-metas es lo que señalas. Sin ella, cada PRD se va inflando en silencio hasta convertirse en un roadmap.
La línea de corte de v1
La línea de corte es una división en dos columnas, "Sale en v1" a la izquierda y "Después" a la derecha, y es la sección que todos quitan porque se siente como admitir que la cosa es pequeña. Justo por eso importa. Te obliga a quedarte con la rebanada más pequeña que podrías poner frente a un usuario real para aprender algo. Un PRD sin línea de corte es una lista de deseos; con una, es un plan.
Línea de corte de v1
Sale en v1 | Después
------------------------------------|------------------------------------
Notificaciones por email, un evento | Canales in-app + push
Toggle on/off por usuario | Preferencias por tipo de evento
Horario de envío fijo en código | Horario de resumen configurable
La disciplina no está en escribir la columna izquierda. Está en animarte a poner funciones reales, de esas que sí quieres, en la derecha.
04 · Variables y cómo adaptarla
La plantilla tiene dos placeholders entre corchetes y varias perillas más suaves. Los placeholders:
- [UNA O DOS FRASES] es tu idea en bruto. Una frase honesta le gana a tres rellenas de paja. Si puedes escribir un párrafo completo (quién, qué está en juego, cómo se ve "listo"), pega eso; el modelo hará menos preguntas y más al grano.
- [QUIÉN LO LEE] fija el tono. "Equipo de ingeniería" recibe más restricciones y criterios de aceptación; "un cliente" recibe más encuadre del problema y menos jerga; "solo yo" recibe la versión al hueso.
Las perillas que vale la pena mover:
- Tope de preguntas. Cinco es el valor por defecto y está calibrado: suficiente para quitar la peor ambigüedad, pero pocas como para que no abandones a mitad de la entrevista. Baja a tres para una función chiquita; nunca pases de siete.
- Límite de palabras. 600 palabras fuerzan un documento del tamaño de una v1. Súbelo a 900 solo para trabajo que de verdad toque varias superficies, y mantente atento a que no rellene de paja.
- Lista de secciones. Agrega "Plan de rollout" o "Instrumentación de métricas" si tu equipo las necesita, pero agrégalas a la sección de salida, nunca a la entrevista, o el número de preguntas se te dispara.
- La sintaxis de la marca. La línea "Supuesto, confirmar" es la parte que de verdad vas a usar. Convierte el documento en un checklist de decisiones que todavía te tocan a ti.
Importante
Mantén la entrevista y la salida como dos fases separadas en el prompt. La forma más común de romper esta plantilla es fusionarlas sin darte cuenta, con un "haz preguntas Y escribe el PRD", y ahí el modelo hace una pregunta de adorno y escribe la ficción igual. El "DETENTE y espera" de la regla 2 está haciendo trabajo de verdad; no lo borres.
05 · Variantes
Mismo esqueleto, salida distinta. Cambia el bloque de CUANDO YA HAYA RESPONDIDO:
- One-pager / pitch. Reemplaza la lista de secciones por: Problema, Para quién es, La idea clave, Qué vamos a construir, Cómo se ve el éxito (una métrica), Por qué ahora. Baja el límite a 300 palabras. Ideal para decidir si construir, antes de meterte en un PRD completo.
- Spec técnico. Mantén la entrevista, pero haz que la pregunta 1d "la restricción dura" sea obligatoria y agrega una 1f para el límite de integración (qué sistemas toca que tú no controlas). Las secciones de salida pasan a ser: Problema, Enfoque, Modelo de datos, Superficie de API, Modos de fallo, Fuera de alcance, Preguntas abiertas. Esto se parece mucho a cómo armarías el brief de un desarrollo para algo como Agent Orchestra, donde el límite de integración es casi todo el riesgo.
- Triage de bug o función. Cuando ni siquiera tienes claro si algo amerita un PRD, limita las preguntas a tres y haz que devuelva una sola línea de veredicto, "amerita PRD / amerita ticket / ahora no", con una razón de una frase. Forma barata de no escribir un documento entero para un cambio de dos horas.
06 · Detalles a cuidar
Los modos de fallo, más o menos en el orden en que suelen morder:
- Sin tope de preguntas, abandono. Quita el "hasta 5" y el modelo te interroga quince turnos seguidos. Vas a cerrar la pestaña. El tope es muro de carga.
- Fases fusionadas, ficción al instante. Ya lo dije, pero vale repetirlo: si escribe antes de que respondas, la entrevista no sirvió de nada.
- Respuestas flojas maquilladas. Si no fuerzas la regla de "no inventes una respuesta", el "no sé" se te convierte en un párrafo con cara de seguridad. Deja a la vista lo que no sabes; es lo más útil del documento.
- Tomar la salida como definitiva. No lo es. El PRD es un primer borrador con el que discutes, y la gracia es que ahora discutes sobre decisiones con nombre en vez de escondidas. Lee primero las marcas de supuesto; esa es tu lista de cosas por editar.
- Recargar la columna izquierda de la línea de corte. Si "Sale en v1" tiene ocho filas, no cortaste nada. Empuja funciones a la derecha hasta que la izquierda sea algo que podrías entregar esta misma semana.
Un buen prompt de PRD no hace el documento por ti. Pone a la vista las decisiones para que las tomes tú, más rápido. Haz la entrevista con honestidad, trata la línea de corte de v1 como el entregable de verdad, y lee los supuestos marcados antes que nada. El objetivo no es un documento terminado; es un borrador armado sobre decisiones que de verdad tomaste tú.
Puntos clave
- Dale vuelta al orden: primero entrevista, después escribe. El momento más barato para tomar una decisión es una pregunta que respondes en diez segundos, no una revisión tres semanas después.
- Ponle tope a las preguntas (cinco) y parte el prompt en dos fases firmes. Sin el tope lo abandonas, y sin el «DETENTE y espera» te escribe ficción antes de que respondas.
- No-metas y la línea de corte de v1 son las únicas secciones que te obligan a entregar menos. Consérvalas aunque recortes todo lo demás.
- Deja a la vista lo que no sabes: el «no sé» se vuelve una Pregunta abierta marcada, nunca un párrafo inventado. Lee las marcas de supuesto antes que nada.
- La salida es un primer borrador con el que discutes, no un documento terminado. Su valor está en que ahora discutes sobre decisiones que de verdad tomaste tú.
Preguntas frecuentes
¿Limitar a cinco preguntas no deja fuera algo importante?
De vez en cuando, sí, pero sin tope es peor. Sin límite, el modelo te hace quince preguntas de bajo valor, abandonas la entrevista, y te quedas sin nada. Cinco lo obligan a priorizar las respuestas que de verdad cambiarían el documento. La sección de Preguntas abiertas es la red de seguridad: lo que el modelo no alcanzó a preguntar cae ahí como un pendiente que retomas después.
¿Y si de verdad no sé la respuesta a una pregunta?
Dilo y ya. La plantilla le dice explícitamente al modelo que no se invente la respuesta y que pase ese «no sé» al PRD como Pregunta abierta marcada. Una incógnita que está a la vista es una decisión que todavía te toca tomar; una incógnita que el modelo rellenó por debajo es un bug que vas a encontrar en producción.
¿Puedo saltarme la entrevista y pegar directo un brief completo?
Sí, y deberías hacerlo cuando lo tengas. Pega un brief de un párrafo en el placeholder de Idea y el modelo hará menos preguntas y más al grano, porque ya le quitaste la mayor parte de la ambigüedad. La entrevista solo se alarga cuando tu input viene flaco, porque está ajustando sus preguntas a tu nivel de incertidumbre, que es exactamente lo que debe hacer.
¿Por qué sigue juntando las preguntas y el PRD en una sola respuesta?
Casi siempre es porque editaste el prompt y la instrucción de «DETENTE y espera» (regla 2) quedó suavizada o borrada. Los modelos tiran por defecto a resolverte todo de un solo tiro, así que sin un alto explícito te hacen una pregunta de adorno y escriben el documento igual. Mantén la entrevista y la salida como dos fases bien separadas y el alto se sostiene.
¿Vale la pena hacer un PRD para una función pequeña?
Muchas veces no, y la variante de triage de la sección 05 existe justo para decírtelo. Limítala a tres preguntas y haz que devuelva una sola línea de veredicto: «amerita PRD / amerita ticket / ahora no». Para un cambio de dos horas, la respuesta casi siempre es un ticket y una frase, no un documento.
¿Debo tomar como definitivo el PRD que produce?
No. Trátalo como un primer borrador con el que discutes. La gracia no es un documento terminado. Es que ahora la discusión gira en torno a decisiones con nombre en vez de supuestos escondidos. Lee primero las marcas «Supuesto, confirmar»; esa es tu lista de cosas por editar y el camino más rápido a un PRD que de verdad puedas defender.
¿Prefieres que lo hagamos por ti?
Esto mismo lo construimos para negocios como el tuyo. La primera conversación es gratis y sin compromiso.
Escríbenos por WhatsAppPrimera conversación gratis. Te responde el fundador.
Recursos relacionados
Rúbrica de LLM como juez (calibrada)
Un juez LLM sin calibrar es un generador de números aleatorios con buenos modales: dos corridas no coinciden porque "8 de 10" no quiere decir nada concreto. Aquí tienes un template de juez listo para copiar y pegar, con criterios anclados, evidencia obligatoria y un overall por mínimo (no por promedio), además de cómo adaptarlo y las trampas que te arruinan los evals sin que te enteres.
Generador de CLAUDE.md para un repo nuevo
Un CLAUDE.md inflado es peor que no tener ninguno. El agente lo lee por encima y se come el contexto que te hace falta para la tarea real. Este es un prompt de copiar y pegar que hace que Claude Code descubra las convenciones leyendo el código, en vez de que se las dictes de memoria, y después escriba un archivo corto y con mucha señal, marcando todo lo que le quedó en duda para que lo revises rápido. Te llevas el prompt, las variables para adaptarlo, variantes para monorepos y archivos que ya existen, y los detalles que vuelven malo un buen borrador.
Una especificación de workflow n8n desde una descripción de una línea
Lo difícil de un workflow de n8n nunca es el camino feliz: es el webhook que reintenta, el envío duplicado y el nodo que se cae a las 3am mientras duermes. Esta plantilla obliga a que todo eso quede en la especificación antes de que arrastres un solo nodo al canvas: trigger y payload, plan nodo por nodo, una estrategia de idempotencia explícita, rutas de error, secretos por nombre y una marca honesta de dónde ya superaste el editor visual. Cópiala, cambia dos placeholders y deja de descubrir tus fallos en producción.