Guía 04 · Build log · 2026
1 prompt · 1 template · 3 reglas

El PRD que uso antes
de buildear cualquier app.

Esto es lo que uso antes de escribir el primer prompt de una app. Son 2 piezas: un prompt para que Claude te entreviste como una PM senior y te saque el PRD él mismo, y un template en blanco por si preferís llenarlo a mano.

Empezá por el prompt. Casi siempre alcanza.

En esta guía
Por qué este PRD

El filtro que te ahorra
construir de más.

Esta guía no es un curso. Son 2 piezas, en este orden:

01Un prompt para que Claude te entreviste como una PM senior y te saque el PRD él mismo.
02Un template en blanco por si preferís llenarlo a mano.

Empezá por el prompt. Casi siempre alcanza. Si te trabás, abrís el template y completás a mano.

— El criterio
Si tu PRD entero cabe en una pantalla, está bien. Si necesitás scroll, todavía no lo entendés. El PRD no es burocracia. Es el filtro que te ahorra construir algo que nadie va a usar.
Parte 01 · El prompt · Copialo y pegalo en Claude

El prompt
completo.

Copialo tal cual. No le quites ni una coma. Las reglas de conversación y el orden de las preguntas son lo que hace que Claude te trate como una PM y no como un cliente.

~ prd-prompt.md
# cópialo TAL CUAL. no le quites ni una coma.

Vas a ayudarme a escribir el PRD (Product Requirements Document)
de una app que voy a construir con IA.

TU ROL:
Actúa como una Product Manager senior con 10 años de experiencia
que ha lanzado 6 apps y ha matado otras 12 antes de buildearlas.
Eres directa, te importan los detalles y no aceptas respuestas vagas.

REGLAS DE LA CONVERSACIÓN:
› Hazme UNA pregunta a la vez. No varias en el mismo mensaje.
› Si mi respuesta es vaga ("una app de productividad"), repreguntas
  hasta que sea específica ("una app de bloqueo de redes para
  freelancers que cobran por hora y se distraen").
› Si lo que digo es contradictorio, lo señalas.
› Si ves que estoy tomando una decisión típica de founders que
  fracasan (ej: "mi target son todos los profesionales"), me
  lo dices directo.
› No me halagas. No me dices "qué buena idea". Me retas.

TEMAS A CUBRIR (en este orden, uno por mensaje):
1. Qué es la app en una sola frase.
2. Para quién es exactamente. Un arquetipo, no varios.
3. Qué problema concreto resuelve.
4. Cómo lo resuelve hoy esa persona, sin mi app (el "as-is").
5. Qué hace mi app diferente. Una sola cosa, no diez features.
6. Los 3 flujos principales del usuario.
7. Qué NO va a hacer la app (lo que descarto a propósito).
8. Cómo sabré en 30 días que la app funciona. 1-2 métricas
   concretas, no "más usuarios".

AL TERMINAR LAS 8 PREGUNTAS:
Genera el PRD final en Markdown con estas secciones:
# Producto (una frase)
# Usuario objetivo
# Problema
# Solución (la diferenciación)
# Flujos principales (pasos numerados)
# Out of scope
# Métricas de éxito
# Stack técnico recomendado

Empieza ya con la pregunta 1.
— Cómo usarlo
Pegalo entero en un chat nuevo de Claude (idealmente dentro de un Project con tu contexto). Claude empezará a hacerte la pregunta 1. Respondé con honestidad. Si te suelta una repregunta brusca, está funcionando.
Parte 02 · El template · Si preferís llenarlo a mano

El esqueleto
en blanco.

Si tenés claro lo que querés construir y preferís saltarte la entrevista, abrí este template y completalo. 8 secciones, una pantalla.

~ prd-template.md
# PRD - [nombre de la app]

## PRODUCTO
[Una frase. Si necesitas un párrafo, todavía no lo tienes claro.]

## USUARIO OBJETIVO
› Edad / etapa profesional:
› Qué hace todo el día:
› Qué herramientas ya usa:
› Cuánto pagaría por resolver esto:

## PROBLEMA
[El dolor concreto. No "es difícil organizarse". Es "pierde 4 horas
a la semana copiando datos entre Notion y Sheets".]

## SOLUCIÓN
[Qué hace tu app que nadie más hace. Una sola cosa. No una lista.]

## FLUJOS PRINCIPALES
1. Happy path (lo que el 80% de usuarios va a hacer)
   › Paso 1
   › Paso 2
   › Paso 3
2. Flujo secundario crítico
3. [máximo 3 flujos. Si tienes más, sobra.]

## OUT OF SCOPE
[Lo que NO hace la app. 3 cosas mínimo.]
›
›
›

## MÉTRICAS DE ÉXITO
› Métrica de uso (ej: 70% de usuarios completa el flujo principal)
› Métrica de negocio (ej: 10 conversiones a paid en 30 días)

## STACK TÉCNICO
› Frontend:
› Backend:
› Base de datos:
› Auth:
› Hosting:

Las 8 secciones, en una línea cada una

PRODUCTOUna frase. Si necesitás un párrafo, todavía no lo tenés claro.
USUARIO OBJETIVOEdad, qué hace todo el día, qué usa hoy, cuánto pagaría.
PROBLEMADolor concreto, con número. No "es difícil organizarse".
SOLUCIÓNQué hace tu app que nadie más hace. UNA cosa, no una lista.
FLUJOSMáximo 3. Happy path + 2 secundarios. Si tenés más, sobra.
OUT OF SCOPELo que NO hace la app. Mínimo 3 cosas, escritas a propósito.
MÉTRICAS1-2 métricas concretas a 30 días. No "más usuarios".
STACK TÉCNICOFrontend, Backend, DB, Auth, Hosting. Una decisión por línea.
Las 3 reglas

Sin esto, el PRD
no sirve para nada.

Aunque uses el prompt y completes el template, si rompés alguna de estas tres reglas el PRD se convierte en otra cosa: una wishlist, un deck, un brainstorm. Pero ya no un filtro.

01
Cabe en una pantalla.
Si tu PRD entero cabe en una pantalla, está bien. Si necesitas scroll, todavía no lo entendés.
02
¿Entra en "solución"?
Cada vez que quieras añadir una feature, preguntate: ¿entra en mi sección de "solución"? Si no, va a "out of scope". Sin excepción.
03
Es para vos.
El PRD no es para nadie más. Es para vos. Es el filtro que te ahorra construir algo que nadie va a usar.
— Y ahora
Si esto te sirve, después del primer build contame. Si te trabaste en algún paso, también. Las mejores iteraciones de esta guía vienen de gente que lo usó de verdad.
— el siguiente paso

Tenés el PRD.
Ahora a buildear con apoyo.

Dentro de la comunidad: builds reales en directo, soporte cuando se rompe el primer deploy, y plantillas para cada fase (PRD, MVP, landing, lanzamiento). Casos de gente que ya facturó con la primera versión.

Ver todas las guías →