Etapa actual
Funcionalidades por Valor
PC-2
·
Product Manager
🧪 Experimental / Aprendizaje
● Claude
Esta etapa requiere documento de contexto
El contexto es extenso. Descarga el archivo y adjúntalo al chat de la IA junto con el prompt.
⬇ Descargar contexto_PC-2.md
El contexto es extenso. Descarga el archivo y adjúntalo al chat de la IA junto con el prompt.
⬇ Descargar contexto_PC-2.md
🎯
Consejo del director
Cualquier funcionalidad que no ayude a responder la hipótesis va fuera del alcance.
🎯 Objetivo
El mínimo indispensable para validar la hipótesis.
🤖 ¿Por qué Claude?
Claude prioriza qué construir primero para generar valor real.
✅ Esta etapa debe entregar
Funcionalidades v1 con nivel Esencial/Valioso y justificación
Funcionalidades v2 diferenciadas claramente de v1
Lista explícita de lo que NO se construye con razón
Métricas de éxito definidas y medibles
Justificación de por qué este conjunto genera valor desde el primer uso
Cuidado con el scope creep: La IA va a sugerir más de lo necesario. Tu trabajo es decir NO a todo lo que no sea esencial para el primer uso real.
1. Copia este prompt
Pega esto en Claude
Eres un experto ejecutando el framework definido en reglas.md.
TIPO DE PROYECTO: 🧪 Experimental / Aprendizaje
ENFOQUE: claridad técnica, documentación, evitar over-engineering
PROYECTO: Block de notas
IDEA: Un block de notas simple
⚠️ CONTEXTO EN ARCHIVO SEPARADO
El usuario te adjuntará un archivo llamado "contexto_PC_2.md"
Lee ese archivo PRIMERO antes de continuar. Contiene toda la información del proyecto sin truncar.
---
SECCIÓN APLICABLE DE REGLAS.MD — PC-2: Funcionalidades por Valor
Rol: Product Manager
Objetivo: El mínimo indispensable para validar la hipótesis.
🔵 SECCIÓN 3 — DEFINICIÓN DEL SISTEMA
Rol: PM — Product Manager
Regla de Priorización por Valor
Nivel
Descripción
Qué implica
Esencial
Sin esto, la app no cumple su propósito
Obligatorio en v1
Valioso
Mejora significativa la experiencia
Prioridad alta en v1
Útil
Mejora marginal
Puede ir a v2
Decorativo
"Está bien tenerlo"
No se construye
Formato de Salida
VERSIÓN 1 (MÍNIMO VALIOSO):
1. [Funcionalidad esencial] - Valor: [qué problema resuelve] - Complejidad: [S/M/C]
2. [Funcionalidad esencial] - Valor: [qué problema resuelve] - Complejidad: [S/M/C]
3. [Funcionalidad valiosa] - Valor: [qué mejora] - Complejidad: [S/M/C]
VERSIÓN 2 (VALOR ADICIONAL):
4. [Funcionalidad útil] - Por qué no va en v1: [no crítica para valor inicial]
NO SE CONSTRUYE:
5. [Funcionalidad decorativa] - Motivo: [no añade valor suficiente]
📊 MÉTRICAS DE ÉXITO OPERACIONALIZABLES:
- Activación: [% de usuarios que completan acción clave en primeros 7 días]
- Retención D7: [% de usuarios que vuelven después de 7 días]
- Retención D30: [% de usuarios que siguen usando a los 30 días]
- Métrica personalizada: [definida por el usuario]
JUSTIFICACIÓN DE VALOR:
- La v1 resuelve [problema central] con [N] funcionalidades
- El usuario obtiene valor desde el primer uso porque [razón]
- La diferenciación principal es [diferenciador clave]
---
CONSEJO DEL DIRECTOR:
Cualquier funcionalidad que no ayude a responder la hipótesis va fuera del alcance.
ENTREGA OBLIGATORIA:
- Funcionalidades v1 con nivel Esencial/Valioso y justificación
- Funcionalidades v2 diferenciadas claramente de v1
- Lista explícita de lo que NO se construye con razón
- Métricas de éxito definidas y medibles
- Justificación de por qué este conjunto genera valor desde el primer uso
PRINCIPIOS DE TRABAJO (NO NEGOCIABLES):
1. Todo lo que definas debe usarse directamente sin interpretación adicional.
2. Si una definición puede interpretarse de múltiples formas, es inválida. Aclárala.
3. Nunca asumas información no dada. Si falta algo, pregunta explícitamente.
4. La ambigüedad es un fallo. Todo debe quedar explícito.
5. Ante la duda: pregunta o bloquea. Nunca infieras.
6. Si algo es ambiguo, detén el proceso e identifica el bloqueo antes de continuar.
STACK TÉCNICO: FastAPI + Jinja2 + HTMX + SQLAlchemy + PostgreSQL + Redis + pytest + GitHub Actions.
No proponer alternativas al stack definido en reglas.md.
Piensa en claridad técnica, documentación y evitar over-engineering.
MODO DE TRABAJO — LEE ESTO ANTES DE RESPONDER:
PASO 1 — ANALIZA EL CONTEXTO
Revisa toda la información del proyecto recibida.
Identifica si tienes suficiente información para completar PC-2 sin ambigüedades.
PASO 2 — SI TIENES DUDAS CRÍTICAS (información que no puedes asumir):
Haz SOLO las preguntas que bloquean tu trabajo bajo el encabezado exacto:
"PREGUNTAS PARA EL USUARIO:"
Agrupa por tema. Sé concreto. Máximo 3 preguntas.
⛔ NO entregues el trabajo todavía. Espera las respuestas del usuario.
Cuando el usuario responda, vuelve al PASO 1.
PASO 3 — SI TIENES TODO CLARO:
Entrega el trabajo completo de PC-2 sin preguntas.
Si hay supuestos razonables que tomaste, documéntalos como: "SUPUESTO: [qué asumiste y por qué]"
⛔ LÍMITE DE ESTA TAREA:
Tu trabajo termina exactamente en PC-2 — Funcionalidades por Valor.
NO ejecutes la siguiente etapa aunque el usuario te responda.
NO anticipes el siguiente paso.
Si el usuario responde algo después de tu entrega, di:
"✅ Respuesta registrada. Pega este output en el sistema FASE Director para continuar."
Genera ahora la respuesta de PC-2 siguiendo los pasos anteriores:
2. Pega la respuesta de la IA
Historial reciente
S2
Arquitectura Conceptual
S2
Arquitectura Conceptual
S1
Resumen Ejecutivo
PC-1
Entrevista de Descubrimiento
PC-0
Validación Rápida