Cómo escribir un product requirements document cuando no eres PM
Una fundadora con la que trabajamos nos envió un PRD de catorce páginas el verano pasado. Carátula, glosario, OKRs, tres personas, fragmentación por sprint, métricas de éxito, un prototipo en Figma que el equipo aún no había construido, y una sección llamada “non-functional requirements” que parecía copiada de una plantilla enterprise la noche anterior. El equipo al que iba a entregar el brief tenía tres ingenieros y una diseñadora de medio tiempo en un estudio con el que ella nunca había trabajado. La primera call de alcance duró dos horas y no resolvió nada.
Ese documento no era un product requirements document. Era un artefacto de PM escrito en el vacío, por una fundadora que había leído suficientes guías de Atlassian y Notion para saber qué títulos de sección poner, y había pensado demasiado poco sobre sus propias restricciones para saber qué secciones realmente necesitaba.
Si estás buscando cómo escribir un product requirements document, casi seguro estás en una de dos situaciones. Eres product manager en una empresa que ya tiene equipo de ingeniería, y en ese caso las guías que existen en internet están escritas para ti. O eres founder no técnico que va a hacer el brief de un desarrollador, un estudio pequeño, o tu primera contratación de ingeniería, y las guías que existen asumen un contexto que no tienes. Este texto es para el segundo grupo.
La definición honesta de un PRD
Un product requirements document es un acuerdo escrito entre la persona que decide qué se construye y las personas que lo construyen. Ese es todo el trabajo. Todo lo demás, las personas y las user stories y los dashboards de analytics, es evidencia de apoyo. La mayoría de las guías de PRD en internet infla la evidencia de apoyo hasta convertirla en el documento, porque la mayoría está escrita para un contexto donde alinear una organización de producto de quince personas es el problema real.
Tu problema es otro. No estás alineando a quince stakeholders. Le estás dando a un equipo pequeño de build una imagen lo bastante clara de qué construir y por qué, para que puedan tomar las decenas de decisiones pequeñas que van a tomar en tu ausencia sin mandarte un mensaje en Slack cada veinte minutos. El documento tiene que hacer dos cosas bien: decir qué debe poder hacer el cliente, y decir qué trade-offs ya decidiste, para que no te sorprendan después.
Ese es un documento mucho más pequeño de lo que sugieren las plantillas. La mayoría de los founders no técnicos con los que trabajamos termina en cuatro a siete páginas, no en veinte. El documento se reduce cuando entiendes qué secciones se ganan su lugar.
Seis secciones que se ganan su lugar
Cada PRD de founder que vimos funcionar en los últimos tres años tiene estas seis piezas, más o menos en este orden. Los títulos pueden cambiar. La sustancia tiene que estar.
1. El cliente y el momento
Un párrafo, no más. Quién es el usuario, y qué está haciendo en los treinta segundos antes de toparse con tu producto. No es un deck de personas. Es una escena.
Una contadora autónoma de un estudio pequeño acaba de recibir catorce facturas de clientes en el mes, cada una en un formato distinto. Necesita registrarlas todas en QuickBooks antes de la conciliación de fin de semana. Hoy esto le toma tres horas. Está en su escritorio con las facturas abiertas en catorce pestañas del navegador.
Ese párrafo trabaja más que tres páginas de personas. El equipo que va a construir el producto ya sabe qué tipo de fricción importa y cuál no. La velocidad de upload importa. Las animaciones bonitas, no. La contadora no va a recomendar el producto a una amiga en una hoja de comparación de features, así que el pulido en la superficie de marketing no es prioridad para el v1.
2. La decisión que ya tomaste
Los founders saltan esta sección porque les parece obvia. No es obvia para el equipo de build. Dilo claro: qué entra en el build, qué no, y cuáles son las premisas que se rompen si alguien las cambia.
Si estás pagando a un vendor, cada premisa que no escribes se convierte en una pregunta que te hace después, que se vuelve atraso, que se vuelve re-scope. Escribir las premisas es más barato que volver a abrirlas a mitad del proyecto.
Una versión limpia se lee así: vamos a construir un web app, no una app móvil, porque nuestros usuarios trabajan en escritorio. Vamos a integrar con QuickBooks Online, no con Xero, no con Sage, porque el ochenta por ciento de nuestro pipeline es QBO. No vamos a construir sistema de cobranza en el v1; vamos a cobrar facturas a mano los primeros seis meses. El target es Chrome y Safari en desktop. Mobile y Edge no son v1.
Ese párrafo te ahorra cuatro horas de reuniones.
3. La versión más pequeña que gana dinero o aprendizaje
Esto es lo que la gente real de producto llama MVP, y es la parte que la mayoría de los founders no técnicos hace mal. Un v1 no es “todo lo de la visión a largo plazo, pero más chico.” Un v1 es la mínima superficie que permite cobrarle a un cliente real o matar la idea. La mayoría de las cosas que querés meter en el v1 no van en el v1.
Escribe esta sección como una lista de jobs visibles para el usuario que el v1 tiene que completar de punta a punta. No features. Jobs. “Subir una factura y verla en QuickBooks en cinco minutos” es un job. “Subida con drag-and-drop” es una feature. El equipo de build puede elegir la feature correcta para cumplir el job. No puede elegir el job correcto, porque no sabe por qué jobs van a pagar tus clientes.
Un v1 de pre-seed normalmente tiene entre tres y seis jobs. Si tu lista tiene doce, no estás escribiendo un v1; estás escribiendo una wishlist. Corta.
4. Los trade-offs que no vas a discutir después
Los ingenieros toman cientos de decisiones pequeñas durante un build. La mayoría son invisibles para ti. Algunas no, y esas se vuelven discusión si no las escribes antes.
Tres trade-offs aparecen en casi todo build:
El primero es alcance versus pulido. Puedes tener una rebanada delgada que hace diez cosas pasables, o dos cosas con excelencia. Elige. El equipo va a elegir por ti si tú no eliges, y no va a elegir lo que tú elegirías.
El segundo es velocidad versus durabilidad. Puedes entregar algo amarrado con cinta adhesiva en cuatro semanas, o algo mantenible en ocho. Elige. Vimos founders insistir en la versión de cuatro semanas, sprintar para llegar a la demo del fundraise, y pasar los siguientes doce meses pidiendo perdón a sus ingenieros por la cinta adhesiva. Decide qué error preferís cometer.
El tercero es custom versus off-the-shelf. Cada build tiene partes que deberían comprarse, no construirse. Auth es la obvia; nadie debería estar construyendo pantallas de login desde cero en 2026. Ejemplos menos obvios: almacenamiento de archivos, email transaccional, pagos, búsqueda. Dile al equipo de build dónde quieres que dibuje esas fronteras, o las van a dibujar en lugares que te van a sorprender.
5. Cómo se ve el éxito en la semana ocho
Elige un resultado observable que signifique que el v1 funcionó. No un dashboard de KPIs. Una frase.
Un caso real de una fintech con la que trabajamos el año pasado: “Para la semana ocho, tres clientes pagos habrán completado al menos un cierre mensual completo en el producto, de punta a punta, sin que nuestro equipo de soporte intervenga.” Esa frase es un contrato. Toda la gente del equipo de build puede sostenerla en la cabeza y usarla para resolver discusiones de alcance. “¿Esta feature ayuda a llegar a la métrica de cerrar sin soporte?” Si sí, se construye. Si no, se posterga.
La mayoría de los PRDs de founders que leemos no tiene esta sección. Tiene un dashboard con doce KPIs y una aspiración vaga. Eso no es objetivo; es contabilidad de deseo.
6. Qué queda fuera del alcance, y por qué
Las cosas que no vas a construir merecen su propia sección, porque si no, vuelven sigilosamente durante el build. Escríbelas. Escríbelas con el motivo. “App móvil: no, porque los usuarios están en escritorio.” “Multi-moneda: no, porque los clientes del v1 son solo de EE. UU.” “SSO: no, porque los clientes del v1 son emprendedores individuales.”
El tú-del-futuro va a agradecer al tú-del-presente esta sección en la semana seis, cuando un inversor pregunte por qué no tienes app móvil y puedas responder en una frase en vez de volver al documento.
Seis secciones que no deberían estar en el PRD del founder
Estas pertenecen a PRDs escritos para orgs de producto establecidas. No pertenecen al brief de un founder no técnico. Meterlas es la manera más confiable de gastar tres semanas escribiendo un documento y aun así no tener un plan construible.
Glosario. Si necesitas glosario, no podaste el documento lo suficiente. El equipo de build no debería necesitar buscar términos. Usa las palabras que sus ingenieros y tus clientes realmente usan.
Personas. Las personas son una herramienta para priorizar entre muchos tipos de usuario. En pre-seed, tienes un tipo de usuario, y deberías conocerlo por nombre. Escribe el párrafo del cliente-y-el-momento.
OKRs. Los OKRs son herramienta de alineación organizacional. Un founder dando brief a un equipo de cuatro personas no los necesita. La frase de “cómo se ve el éxito en la semana ocho” hace el mismo trabajo.
Roadmap más allá del v1. Roadmap después del v1 es especulación. Cualquier vendor o hire que trate tu roadmap post-v1 como un plan real no está prestando atención. Mantén el roadmap fuera del PRD; lo que está en el v1 es el plan, lo que viene después es hipótesis.
User stories detalladas con criterios de aceptación. Los criterios de aceptación son cómo los PMs traducen un roadmap a un tracker. Un equipo pequeño de build no los necesita por adelantado; los va a escribir él mismo, contra tus seis secciones, y te va a preguntar cuando algo sea ambiguo. Es más rápido.
Wireframes que el equipo no dibujó. Si bocetaste las pantallas en Figma tú mismo, no las pongas en el PRD. El equipo de build las va a redibujar, y debe. Mostrar tu boceto tiende a anclar a todo el mundo a un layout que tal vez no sobreviva al contacto con la implementación real. Describe el job del usuario; deja que el equipo diseñe la pantalla.
Un ejemplo trabajado: cómo se vio un PRD de founder
El ejemplo de la contadora arriba es de una fundadora real. Su PRD del v1, después de que lo recortamos, tenía cinco páginas. La estructura era exactamente las seis secciones de arriba. Tres jobs en la lista del v1: subir facturas, verlas en QuickBooks en cinco minutos, mandarle un mensaje en Slack a la contadora cuando algo fallara. Dos trade-offs decididos por adelantado: entregar en seis semanas en vez de tres, sostener una sola integración con QBO. Una métrica de éxito: diez estudios pagos cerrando el mes sin soporte para la semana diez.
El build llevó ocho semanas en vez de seis. Un job se corrió a un v1.5 (notificaciones de fallo). Diez estudios pagos llegaron a la métrica en la semana doce. El PRD aguantó. La versión de catorce páginas que reemplazamos no habría aguantado, porque demasiadas secciones eran discusiones esperando para estallar.
Esa es la prueba de un buen PRD de founder: ¿sobrevivió al contacto con el build, y alguien tuvo que reabrir sus premisas a mitad de la semana cuatro? Si sí, el documento estaba demasiado largo, demasiado vago, o las dos cosas.
Cuándo escribir más, y cuándo escribir menos
La estructura de seis secciones no es regla rígida. Dos situaciones piden un documento más largo.
La primera son industrias reguladas. Si estás construyendo en healthtech, fintech, o donde un equipo de compliance vaya a mirar el sistema, vas a necesitar un documento aparte para ese equipo y una sección en el PRD que diga “review de compliance está dentro del alcance, ver anexo.” No te lo saltes; el costo de descubrir un hueco de compliance en la semana seis es mucho mayor que el costo de escribirlo en la semana cero.
La segunda es cuando estás pagando a un vendor de precio cerrado. Los contratos de precio cerrado empujan toda ambigüedad a la negociación contractual, porque el vendor va a cobrar por cualquier cosa no especificada. En ese caso, el PRD se vuelve documento de contrato, y se escribe más largo porque cada línea no escrita es un change order futuro. Por eso solemos recomendar a los founders evitar contratos de precio cerrado en esta etapa; construye con un partner que trabaje en time-and-materials, y el PRD se mantiene corto.
Dos situaciones piden un documento más corto. Si estás con un ingeniero en quien confías y con quien ya entregaste antes, un brief de una página con tres jobs y una métrica de éxito alcanza. La confianza hace el trabajo que haría el documento. Y si tu v1 es genuinamente un prototipo, no un producto, escribe un párrafo y un boceto y entrega en dos semanas. Llamarle PRD a eso es teatro.
La versión que escribes en la semana uno no es la que sale al aire
Lo más difícil de escribir un PRD como founder no técnico es aceptar que el documento va a cambiar. Los PMs que escriben las guías en Atlassian y Notion lo saben; sus equipos modifican PRDs en pleno vuelo todos los días. Los founders escribiendo su primer PRD muchas veces lo tratan como entregable de un solo tiro, lo pasan, y se sienten traicionados cuando la realidad fuerza una edición.
Escribe el documento con una premisa: para el final de la semana dos va a estar equivocado en algún lugar. El equipo de build va a descubrir algo que rompe una premisa. El trabajo del PRD no es estar en lo correcto; es ser lo bastante específico para que estar equivocado se vea claro y rápido. Un documento vago se equivoca en silencio. Un documento específico se equivoca en voz alta, que es la clase de equivocación que se puede arreglar.
Si nunca escribiste uno, la primera versión va a parecerte incómodamente opinionada. Bien. Lo opuesto a opinionado es “cada uno tiene su propia lectura de qué estamos construyendo,” que es el modo de fallo que el documento existe para evitar.
FAQ
¿Cuál es la diferencia entre un PRD y un product brief?
En la mayoría de los contextos de founder no técnico no hay una diferencia útil. Los PMs a veces usan “product brief” para un documento de una página en etapa temprana y “PRD” para la versión más larga. Elige un término y quédate con él; el documento hace el mismo trabajo.
¿Cuántas páginas debería tener un PRD de founder?
De cuatro a siete páginas para un v1, en nuestra experiencia. Si el tuyo tiene veinte, el equipo de build no lo va a leer; va a hojear las primeras tres y te va a preguntar el resto en call.
¿Debería usar una plantilla de PRD?
Las plantillas son estructura inicial, no documento terminado. El peligro es que la plantilla te lleva a llenar cada sección, incluidas las que no necesitas. Usa las seis secciones de arriba como checklist; trata cualquier sección que una plantilla te diga que llenes y que no esté en esa lista como opcional.
¿La IA sirve para escribir un PRD?
Para redactar el texto, sí. Para decidir qué entra en el v1, no. Las decisiones de las secciones dos a seis son tuyas y solo tuyas; un LLM puede ayudarte a escribirlas más rápido, pero no puede elegir qué trade-offs son los correctos para tu negocio. Usa la IA en el tipeo, no en el pensamiento.
¿Y si mi ingeniero pide más detalle del que da el PRD?
Responde la pregunta, y decide si merece entrar al documento. Si es una pregunta recurrente que otro ingeniero va a hacer después, escríbela. Si es una aclaración puntual, respóndela en Slack y sigue. El PRD es documento de trabajo, no contrato.