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
🎯 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
Procesando...
Historial reciente
S2 Arquitectura Conceptual Gemini · 911p
S2 Arquitectura Conceptual Gemini · 387p
S1 Resumen Ejecutivo Claude · 415p
PC-1 Entrevista de Descubrimiento Claude · 939p
PC-0 Validación Rápida Gemini · 399p