¿Qué es un brief de producto?

Un documento breve que explica qué es un producto, qué problema resuelve, para quién y qué deja fuera a propósito. Da a todos los que trabajan en el producto, personas y agentes, el mismo punto de partida.

¿En qué se diferencia un brief de producto de un PRD?

El brief cubre todo el producto en una página. Un documento de requisitos de producto (PRD) profundiza en una función o una versión y describe con exactitud cómo debe comportarse. Empieza por el brief y escribe PRD cuando una función necesite ese nivel de detalle.

¿Puede usar este brief un agente de programación con IA?

Sí. Guarda el archivo Markdown en tu repositorio y haz referencia a él desde AGENTS.md o impórtalo en CLAUDE.md. AGENTS.md es Markdown simple, y Claude Code lee CLAUDE.md al inicio de cada sesión.

¿Por qué Markdown y JSON?

Markdown es fácil de leer para personas y agentes y se muestra bien en cualquier plataforma de código. JSON tiene el mismo contenido con claves fijas en inglés, para que scripts y formularios lo lean sin tener que interpretar texto libre.

¿Se guarda o se envía mi brief a algún sitio?

Solo se guarda en el almacenamiento local de tu navegador para que una recarga no lo borre. No se sube nada ni se envía a ninguna analítica, y Borrar elimina el borrador.

Plantilla de brief de producto: gratis, Markdown y JSON

Por Aleksandar Vuk JovanovicActualizado 30 de septiembre de 2026Cómo investigamos y actualizamos

Rellena el brief

Escribe directamente en los campos. El Markdown y el JSON de abajo se actualizan mientras escribes y están listos para copiar o descargar.

Tu borrador se guarda en el almacenamiento local de este navegador para que sobreviva a una recarga. Nunca se sube. Borrar lo elimina.

Vista previa en Markdown

# [Nombre del producto]

> [Qué hace y para quién, en una línea]

Última actualización: [fecha]

## Problema

[Quién tiene hoy qué dificultad]

## Para quién es

[Usuarios y compradores principales]

## Qué hace

[Cómo resuelve el producto el problema]

## Funciones clave

- [Hasta tres cosas que ya hace hoy]

## En lugar de

[Qué usa la gente hoy y por qué esto es mejor]

## Fuera del alcance

[Lo que deliberadamente no hace]

## Cómo sabemos que funciona

[Una señal que puedas comprobar]

## Enlace

[URL de la web o del repositorio]

Vista previa en JSON

{
  "format": "product-brief",
  "version": 1,
  "language": "es",
  "updated": "",
  "name": "",
  "oneLiner": "",
  "problem": "",
  "audience": "",
  "solution": "",
  "features": [
    "",
    "",
    ""
  ],
  "alternative": "",
  "nonGoals": "",
  "success": "",
  "url": ""
}

Archivos en blanco

¿Prefieres tu propio editor? Llévate la plantilla vacía en cualquiera de los dos formatos.

Para qué sirve cada campo

Diez campos bastan para que personas y agentes estén de acuerdo en qué construyes. Cada uno responde a una pregunta que, de otro modo, alguien te haría.

Nombre del producto: Todos, incluido un agente, deben escribir el nombre igual. Escríbelo aquí una vez.
Frase de presentación: La frase que reutilizarás en fichas, biografías y en tu página de inicio. Si no consigues escribirla, el producto aún no está claro.
Problema: El trabajo parte del problema, no de la función. Un problema claro permite a otros proponer soluciones mejores que la tuya.
Para quién es: Un público acotado facilita cada decisión posterior: el tono, las funciones, dónde lanzar.
Qué hace: Cómo resuelve el producto el problema, en palabras sencillas. Es lo primero que necesita alguien nuevo.
Funciones clave: Tres funciones que existen hoy. Un agente que redacta textos nunca debería inventarse una cuarta.
En lugar de: La gente compara con lo que hace ahora. Nombrar la solución improvisada explica tu valor mejor que una tabla de funciones.
Fuera del alcance: El campo que la mayoría de los briefs se salta. Frena el crecimiento descontrolado del alcance y evita que un agente añada funciones que no has pedido.
Cómo sabemos que funciona: Una señal observable te dice si el producto funciona y le da a un agente un objetivo con el que comprobar su trabajo.
Enlace: Un enlace permite a un lector o a un agente verificar los detalles en lugar de adivinarlos.

Comprueba tu tagline con el límite de caracteres de cada plataforma →

Pásale el brief a tu agente

Los agentes de programación leen archivos Markdown de tu repositorio. Un brief breve junto a tu código les da el contexto de producto que el código por sí solo no contiene.

Descarga el archivo Markdown y guárdalo en tu repositorio, por ejemplo como docs/product-brief.md.
Indícaselo a tu agente: añade una línea en AGENTS.md o impórtalo en CLAUDE.md con @docs/product-brief.md.
Para GitHub Copilot, enlaza o copia lo esencial en .github/copilot-instructions.md.
Guarda el JSON al lado cuando un script u otra herramienta deba leer los mismos datos.
Cambia la línea de fecha cada vez que algo cambie y borra las frases que ya no sean ciertas.

Tema	Redacción oficial	Qué significa para tu brief
Formato	AGENTS.md is just standard Markdown.	Un brief en Markdown simple sirve como contexto para el agente sin ninguna sintaxis especial.
Encabezados	Use any headings you like; the agent simply parses the text you provide.	Los nombres de las secciones de esta plantilla son una sugerencia. Cámbialos si tu equipo usa otras palabras.
Cuándo se lee	You write these files in plain text; Claude reads them at the start of every session.	Claude Code carga CLAUDE.md al inicio de cada sesión, así que un brief importado siempre está en contexto.
Importación	CLAUDE.md files can import additional files using @path/to/import syntax.	Basta una línea como @docs/product-brief.md en CLAUDE.md para incluir el brief.
Longitud	target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.	Un contexto corto se sigue mejor. Un brief de una página queda muy por debajo de este tamaño.
Copilot	Add natural language instructions to the file, in Markdown format.	Las instrucciones de Copilot también son Markdown, así que el mismo texto encaja ahí.
Codificación JSON	JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8	La descarga en JSON es UTF-8, así que las tildes, los caracteres CJK y los emoji sobreviven a cualquier herramienta.

Brief, PRD o archivo de contexto

Tres documentos que se confunden a menudo. Responden a preguntas distintas, y muchos productos necesitan más de uno.

Documento	Responde a	Extensión	Lo escribe
Brief de producto (esta plantilla)	Qué construimos, para quién y dónde termina	Una página, diez campos	Fundador o responsable de producto
Documento de requisitos de producto (PRD)	Cómo debe comportarse exactamente una función o una versión	Varias páginas por función	Product manager junto con ingeniería
Archivo de contexto de producto	Qué datos y textos aprobados puede publicar un agente	Crece con cada canal	Quien lleve el lanzamiento

Plantilla de plan de lanzamiento →

Lo que esta plantilla deja fuera

Es un punto de partida, no una especificación completa. Los requisitos detallados, los diseños y la investigación viven en sus propios documentos.
Los precios, las fechas de lanzamiento y las variantes de textos de marketing quedan fuera a propósito.
La página no comprueba si tus afirmaciones son ciertas. Escribe solo lo que el producto hace hoy.
No se envía nada a ningún sitio: el borrador se queda en este navegador hasta que pulses Borrar.

Fuentes

Leímos estas páginas el 30 de septiembre de 2026 y las citamos arriba palabra por palabra.

Página	Fecha en la página	Comprobado por nosotros
AGENTS.md	sin fecha	30 sept 2026
Claude Code Docs: How Claude remembers your project	sin fecha	30 sept 2026
GitHub Docs: Adding repository custom instructions for GitHub Copilot	sin fecha	30 sept 2026
RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format (December 2017)	sin fecha	30 sept 2026
CommonMark Spec, version 0.31.2	sin fecha	30 sept 2026

Preguntas frecuentes

¿Qué es un brief de producto?: Un documento breve que explica qué es un producto, qué problema resuelve, para quién y qué deja fuera a propósito. Da a todos los que trabajan en el producto, personas y agentes, el mismo punto de partida.
¿En qué se diferencia un brief de producto de un PRD?: El brief cubre todo el producto en una página. Un documento de requisitos de producto (PRD) profundiza en una función o una versión y describe con exactitud cómo debe comportarse. Empieza por el brief y escribe PRD cuando una función necesite ese nivel de detalle.
¿Puede usar este brief un agente de programación con IA?: Sí. Guarda el archivo Markdown en tu repositorio y haz referencia a él desde AGENTS.md o impórtalo en CLAUDE.md. AGENTS.md es Markdown simple, y Claude Code lee CLAUDE.md al inicio de cada sesión.
¿Por qué Markdown y JSON?: Markdown es fácil de leer para personas y agentes y se muestra bien en cualquier plataforma de código. JSON tiene el mismo contenido con claves fijas en inglés, para que scripts y formularios lo lean sin tener que interpretar texto libre.
¿Se guarda o se envía mi brief a algún sitio?: Solo se guarda en el almacenamiento local de tu navegador para que una recarga no lo borre. No se sube nada ni se envía a ninguna analítica, y Borrar elimina el borrador.

¿Brief listo? Pon el producto delante de la gente.

LaunchRepo da a tu agente de programación un playbook para cada plataforma de lanzamiento y cada directorio, para que el producto que acabas de describir aparezca donde busca tu público, y registra qué fichas se han publicado.

Ver precios