PRD, spec y RFC: tres documentos, tres audiencias y cuál escribir primero

Los tres documentos frente a frente

Las filas que más importan son la primera y la última. Cada documento responde a una pregunta y cada uno tiene su forma característica de salir mal.

Para qué sirve un PRD

Un documento de requisitos de producto existe para que todas las personas que tocan el producto coincidan en el problema y en los límites antes de que nadie abra un editor. La entrada del glosario sobre PRD describe la anatomía completa; las partes que se ganan su sitio son:

• El problema en un párrafo, con quién lo tiene y cómo lo sabes.
• Objetivos y no objetivos. Los no objetivos son la mitad más útil. "No habrá edición sin conexión en la v1" evita un mes de discusiones.
• Requisitos numerados con un identificador estable (REQ-007), una prioridad y criterios de aceptación que podrías entregar a alguien de QA.
• Preguntas abiertas que siguen abiertas, con fecha.

El PRD es el documento que un cliente aprueba y contra el que una auditoría de requisitos comprueba después lo construido. Para que eso funcione, necesita identificadores que no cambien y una copia congelada en la aprobación. Un PRD que se reescribe cada semana no se puede auditar, porque nadie puede decir qué se acordó.

Lo que un PRD no es: una lista de pantallas, un esquema de base de datos ni un diseño técnico. En cuanto dice "guardar esto en una columna JSONB", se ha convertido en una spec con el sombrero equivocado.

Si escribes uno desde cero, la plantilla de PRD trae las secciones en este orden, y el artículo anterior sobre escribir un PRD con IA explica cómo rellenarla.

Para qué sirve una spec

Una spec (especificación funcional, especificación técnica, documento de diseño; los nombres se mezclan) traduce un requisito a un comportamiento lo bastante preciso para construirlo y probarlo. Donde el PRD dice "los clientes pueden exportar sus datos", la spec dice qué formatos, cómo se llama el archivo, qué pasa con los adjuntos de más de 25 MB, si la exportación corre en segundo plano y qué ve la persona mientras tanto.

Una buena spec tiene una forma distinta a la de un PRD:

1. Un requisito o una funcionalidad por spec. Las specs que cubren todo el producto son PRD con demasiado detalle.
2. Estados y transiciones, no prosa. Una tabla de "cuando el usuario hace X en el estado Y, ocurre Z" atrapa más errores que los párrafos.
3. Casos límite explícitos: vacío, máximo, concurrente, sin conexión, permiso denegado.
4. Interfaces: la forma de la API, los nombres de eventos, los campos y sus tipos.
5. Qué queda fuera de esta versión, para que nadie lo construya por accidente.

Las specs pueden cambiar a menudo, hasta el momento en que la funcionalidad se publica. Son un documento de trabajo para quienes construyen, así que el historial de versiones importa más que la aprobación. En un equipo de cinco, la spec suele ser una página bajo el proyecto junto al PRD, que el ingeniero edita sobre la marcha mientras el PM comenta en vez de reescribir.

La diferencia entre spec de producto y spec técnica está sobre todo en quién escribe los casos límite. La de producto lista lo que ve la persona en cada estado; la técnica, cómo llega ahí el sistema. Los equipos pequeños suelen fusionarlas en un documento con dos secciones, y está bien.

Para qué sirve un RFC

Un RFC propone un cambio caro de deshacer y pide a los afectados que objeten ahora y no después. Ejemplos de dirigir una empresa pequeña con estas herramientas: pasar de permisos por proyecto a permisos de todo el espacio, mover la facturación de un proveedor a otro, adoptar un monorepo o retirar un idioma del sitio de marketing.

La forma es simple y lleva estable desde los años sesenta, cuando los primeros RFC de internet eran literalmente memorandos que pedían comentarios:

• Contexto: qué es cierto hoy y por qué es un problema.
• Propuesta: el cambio, en concreto.
• Alternativas consideradas, con el motivo por el que se descartó cada una. Esta sección es lo que separa un RFC de un anuncio.
• Consecuencias: qué se vuelve más difícil, no solo qué se vuelve más fácil.
• Periodo abierto: una fecha límite para comentarios y quién decide.

Un RFC lo lee más gente de la que actuará sobre él. Es el único de los tres que termina cuando se acaban los comentarios, no cuando se publica el código. Una vez decidido, debe marcarse como aceptado o rechazado y dejarse en paz; un cambio posterior tiene su propio RFC que cita al primero. Algunos equipos los llaman registros de decisión o ADR; la mecánica es la misma.

El fallo clásico es el RFC escrito después de la decisión, para darle un rastro en papel. La gente lo nota y deja de comentar el siguiente.

¿Qué documento necesitas ahora mismo?

Recorre estas preguntas en orden.

1. ¿Hay un producto o una funcionalidad que aún no existe y más de una persona tiene que acordar qué es? Escribe un PRD. Si es una funcionalidad dentro de un producto existente, añádela al PRD del producto como un requisito numerado nuevo, no como documento aparte.
2. ¿Hay un requisito con más de dos o tres casos límite, o una interfaz sobre la que otra persona construirá? Escribe una spec para ese requisito y enlázala desde él.
3. ¿Hay un cambio que afecta a más de un equipo, cuesta más de una semana o es difícil de revertir? Escribe un RFC y ponle fecha de cierre.
4. ¿No es ninguna de las anteriores? Escribe una incidencia con criterios de aceptación y sáltate el documento. Una tarea de dos días no necesita un PRD.

Un equipo de seis que construye un producto para un cliente suele tener un PRD, de tres a diez specs a lo largo del proyecto y uno o dos RFC al año. Si tienes más RFC que specs, estás debatiendo más de lo que construyes.

El giro de 2026: los agentes leen estos documentos primero

Hace dos años, el primer lector de una spec era un desarrollador. Hoy suele ser un agente de programación, un agente de planificación dentro del espacio de trabajo o un asistente conectado por MCP. Eso cambia lo que es un buen documento en varios aspectos prácticos.

La estructura vence a la prosa. Un agente que recibe un PRD con requisitos numerados y criterios de aceptación puede planificar incidencias contra ellos e informar de la cobertura. Con cuatro páginas de narrativa, las resumirá y perderá los límites. Encabezados, identificadores y tablas ya no son preferencias de estilo; son la interfaz.

Los no objetivos se leen al pie de la letra. Una persona lee por encima "no haremos modo sin conexión en la v1" y lo recuerda. Un agente que planifica trabajo solo lo respetará si está en el documento que recibió. Pon los no objetivos en el PRD, no en un hilo de chat.

La línea base importa más. Cuando un agente escribe requisitos y otro planifica incidencias a partir de ellos, la deriva se vuelve fácil: un requisito se suaviza en una pasada y nadie lo nota. Congelar el PRD en la aprobación y comparar las versiones posteriores con él es la forma de detectarlo. En Atrix, la ejecución Develop del agente escribe un documento de requisitos a partir de un brief, los requisitos se pueden congelar como línea base y una auditoría de requisitos muestra cobertura y deriva respecto a esa línea base. No escanea código; compara registros.

Las specs se convierten en el plan de pruebas. Si la spec es una tabla de estados y comportamiento esperado, un agente de programación puede convertir cada fila en una prueba. Si es intención en párrafos, no puede.

Los RFC siguen siendo humanos. La decisión de un RFC es un juicio sobre las concesiones que la organización está dispuesta a hacer. Un agente puede redactar bien la sección de alternativas y resumir los comentarios. No debería ser quien decide.

Mantener los tres en un mismo sitio

Dónde viven los documentos importa más que antes, porque un agente solo puede leer lo que alcanza. Un PRD en Google Docs, una spec en una wiki y un RFC en la descripción de un pull request son tres permisos, tres buscadores y ningún enlace entre ellos.

Lo que nos ha funcionado: un árbol de páginas por producto. El PRD es la página superior, cada spec es una página hija enlazada desde su requisito, y los RFC viven en una carpeta del espacio con el estado en el título. Los elementos de la hoja de ruta enlazan a los requisitos, así que cuando uno se retrasa, el requisito al que sirve está a un clic. La plantilla de hoja de ruta de producto se apoya en ese enlace.

Atrix es una forma de conseguirlo, con páginas anidadas bajo un proyecto, coedición en vivo, historial de versiones y exportación a Markdown; su servidor MCP también permite que un asistente externo lea las mismas páginas. Notion y Confluence también anidan y guardan historial. La propiedad que importa es que los tres documentos sean accesibles desde la misma herramienta, con los mismos permisos.

FAQ

¿Cuál es la diferencia entre un PRD y una spec?

Un PRD dice qué construir y por qué, al nivel de requisitos numerados con criterios de aceptación. Una spec dice cómo se comporta uno de esos requisitos en cada estado, con la precisión suficiente para construirlo y probarlo. El PRD se aprueba y se congela; la spec cambia hasta que la funcionalidad se publica.

¿Un RFC es lo mismo que un documento de diseño?

No exactamente. Un documento de diseño explica cómo se construirá algo; un RFC pregunta si debe hacerse un cambio e invita a objetar antes de decidir. Muchos documentos de diseño incluyen una sección de "alternativas consideradas" al estilo RFC, y algunos equipos usan los nombres indistintamente, pero lo que define al RFC es el periodo de comentarios y la decisión al final.

¿Las startups necesitan PRD?

Un equipo de dos que construye su primera versión puede arreglarse con un planteamiento del problema de una página y una lista de incidencias. Desde la primera vez que un cliente, un inversor o una nueva incorporación necesita saber qué se acordó, un PRD con requisitos numerados se paga solo. El detonante es que más de una persona tenga que ponerse de acuerdo, no el tamaño de la empresa.

¿Quién escribe la spec, el PM o el ingeniero?

Normalmente el ingeniero o diseñador más cercano al trabajo, con el PM revisando. El PRD es el documento del PM; la spec, el de quien construye. En un equipo sin PM, el fundador escribe el PRD y quien construye la funcionalidad escribe la spec.

¿Debe un PRD contener detalles técnicos?

No. La arquitectura, los esquemas y las formas de API van en una spec o en un diseño técnico. Un PRD que fija la implementación bloquea decisiones que deberían tomar quienes construyen, y queda obsoleto la primera vez que un ingeniero elige otro enfoque.

¿Puede un agente de IA escribir estos documentos?

Puede redactar los tres, y redacta bien PRD y specs cuando recibe un brief claro y las páginas existentes como contexto. Lo que conviene mantener humano es el planteamiento del problema en el PRD, la decisión en un RFC y la aprobación que convierte los requisitos en una línea base.

Siguiente paso

Si empiezas un producto, escribe primero el PRD; la plantilla de PRD es una página en Markdown con las secciones anteriores en orden. Cuando existan los requisitos, la plantilla de hoja de ruta de producto enlaza cada elemento con el requisito al que sirve, que es el enlace del que después depende una auditoría. Para ver cómo funcionan los documentos dentro de un espacio con agente, consulta documentos y pizarras y la página del agente de IA.