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 implementación.

Si el usuario necesita un artefacto duradero de PRD a SRS o un contrato de capacidad, transfiérele a product-capability.

Cuándo Usarlo

• Antes de comenzar cualquier funcionalidad — valida el "por qué"
• Revisión semanal de producto — ¿estamos construyendo lo correcto?
• Cuando estás atascado eligiendo entre funcionalidades
• Antes de un lanzamiento — verifica el 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 office hours 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? (cuantifica: ¿con qué frecuencia, qué tan grave, qué hacen hoy?)
3. ¿Por qué ahora? (¿qué cambió que hace esto posible/necesario?)
4. ¿Cuál es la versión de 10 estrellas? (si el dinero/tiempo fuera ilimitado)
5. ¿Cuál es el MVP? (lo más pequeño que demuestre la tesis)
6. ¿Cuál es el anti-objetivo? (¿qué NO estás construyendo explícitamente?)
7. ¿Cómo sabes que funciona? (métrica, no vibraciones)

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

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

Modo 2: Revisión de Fundador

Revisa tu proyecto actual desde la perspectiva de un fundador:

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

Modo 3: Auditoría del Recorrido del Usuario

Mapea la experiencia real del usuario:

1. Clona/instala el producto como un nuevo usuario
2. Documenta cada punto de fricción (pasos confusos, errores, documentación faltante)
3. Mide el tiempo de cada paso
4. Compara con la incorporación de la competencia
5. Puntúa: tiempo hasta el valor (¿cuánto tarda el usuario en obtener su primer logro?)
6. Recomienda: las 3 principales correcciones para la incorporación

Modo 4: Priorización de Funcionalidades

Cuando tienes 10 ideas y necesitas elegir 2:

1. Enumera todas las funcionalidades candidatas
2. Puntúa cada una en: impacto (1-5) × confianza (1-5) ÷ esfuerzo (1-5)
3. Ordena por puntuación ICE
4. Aplica restricciones: presupuesto, tamaño del equipo, dependencias
5. Salida: roadmap priorizado con justificación

Salida

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

Integración

Combina con:

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