product-lens

Product Lens — Piensa Antes de Construir

Este carril es responsable del diagnóstico de producto, no de la redacción de especificaciones listas para implementar.

Si el usuario necesita un artefacto duradero de PRD a SRS o un contrato de capacidad, remítase a product-capacity.

Cuándo Usarlo

• Antes de comenzar cualquier funcionalidad — validar el "por qué"
• Revisión semanal de producto — ¿estamos construyendo lo correcto?
• Cuando estás atascado eligiendo entre funcionalidades
• Antes de un lanzamiento — verificación de cordura del recorrido del usuario
• Cuando conviertes una idea vaga en un brief de producto antes de que comience la planificación de ingeniería

Cómo Funciona

Modo 1: Diagnóstico de Producto

Como las horas de oficina de YC pero automatizado. Hace las preguntas difíciles:

1. ¿Para quién es esto? (persona específica, no "desarrolladores")
2. ¿Cuál es el dolor? (cuantificar: ¿con qué frecuencia, qué tan malo, qué hacen hoy?)
3. ¿Por qué ahora? (¿qué cambió que hace esto posible/necesario?)
4. ¿Cuál es la versión 10 estrellas? (si el dinero/tiempo fueran ilimitados)
5. ¿Cuál es el MVP? (la cosa más pequeña que prueba la tesis)
6. ¿Cuál es el anti-objetivo? (¿qué estás explícitamente NO construyendo?)
7. ¿Cómo sabes que está funcionando? (métrica, no vibraciones)

Salida: un PRODUCT-BRIEF.md con respuestas, riesgos y una recomendación de continuar/no continuar.

Si el resultado es "sí, construye esto", el siguiente carril es product-capacity, no más teatro de fundador.

Modo 2: Revisión de Fundador

Revisa tu proyecto actual a través de la lente de un fundador:

1. Leer README, CLAUDE.md, package.json, commits recientes
2. Inferir: ¿qué intenta ser esto?
3. Puntuar: señales de ajuste producto-mercado (0-10)
   - Trayectoria de crecimiento de uso
   - Indicadores de retención (contribuyentes repetidos, usuarios que regresan)
   - Señales de ingresos (página de precios, código de facturación, integración de Stripe)
   - Foso competitivo (¿qué es difícil de copiar?)
4. Identificar: la única cosa que multiplicaría esto por 10
5. Señalar: cosas que estás construyendo que no importan

Modo 3: Auditoría de Recorrido del Usuario

Mapa la experiencia real del usuario:

1. Clonar/instalar el producto como un nuevo usuario
2. Documentar cada punto de fricción (pasos confusos, errores, documentación faltante)
3. Cronometrar cada paso
4. Comparar con la incorporación de la competencia
5. Puntuar: tiempo hasta el valor (¿cuánto tarda el usuario en obtener su primera victoria?)
6. Recomendar: las 3 principales correcciones para la incorporación

Modo 4: Priorización de Funcionalidades

Cuando tienes 10 ideas y necesitas elegir 2:

1. Listar todas las funcionalidades candidatas
2. Puntuar cada una en: impacto (1-5) × confianza (1-5) ÷ esfuerzo (1-5)
3. Clasificar por puntuación ICE
4. Aplicar restricciones: presupuesto, tamaño del equipo, dependencias
5. Salida: hoja de ruta priorizada con justificación

Salida

Todos los modos generan documentos accionables, no ensayos. Cada recomendación tiene un paso específico siguiente.

Integración

Combinar:

• /browser-qa para verificar los hallazgos de la auditoría del recorrido del usuario
• /design-system audit para evaluación de pulido visual
• /canary-watch para monitoreo posterior al lanzamiento
• product-capacity cuando el brief de producto necesite convertirse en un plan de capacidad listo para implementar