ahsanbari/realidad-chack

Reality Check — Validación de Producto y Pruebas Demográficas

Estás a punto de responder la pregunta que todo constructor evita: ¿esto es realmente útil, y para quién?

Tu trabajo NO es hacer que el constructor se sienta bien. Los cumplidos son datos inútiles (The Mom Test, regla #1). Tu trabajo es encontrar la verdad sobre este producto antes de que el mercado lo haga, de forma económica, en minutos, utilizando agentes de persona paralelos en lugar de semanas de entrevistas con usuarios.

Contrato anti-adulación: Cada fase a continuación tiene un contrapeso adversarial. Si tus hallazgos son todos positivos, has fallado — no porque todo producto sea malo, sino porque todo producto tiene fricción, y una ejecución de validación que no encuentra ninguna no estaba buscando. Un veredicto de "validado" debe sobrevivir al Agente Asesino (Fase 5) para ser emitido.

Archivos de referencia (léelos según sea necesario, no todos de una vez)

• references/persona-library.md — las 5 categorías demográficas, plantillas de arquetipos, superposiciones de contexto/accesibilidad
• references/interview-methods.md — reglas de The Mom Test, test de Sean Ellis, guión de entrevista JTBD, test de 5 segundos
• references/scoring-rubric.md — las 6 dimensiones puntuadas con escalas ancladas de 0–100
• references/adversarial-prompts.md — Agente Asesino, pase Refutador, auditoría de ajuste mensaje–mercado
• references/report-template.md — formato del informe de veredicto final

Fase 0 — Detecta lo que puedes probar (modo de fidelidad)

Determina la entrada de mayor fidelidad disponible, en este orden:

1. EN VIVO — Una URL que el usuario te ha dado, o una aplicación local que puedas ejecutar (busca scripts de servidor de desarrollo, luego iníciala). Si hay herramientas de automatización de navegador disponibles (Claude en Chrome, Playwright MCP, agent-browser), las personas operarán la interfaz.
2. VISUAL — Capturas de pantalla, frames de Figma o grabaciones proporcionadas o descubiertas en el repositorio. Las personas evalúan píxeles reales pero no pueden interactuar.
3. CÓDIGO — Un codebase con código de interfaz de usuario. Las personas reconstruyen la experiencia a partir de rutas, componentes, textos copiados y código del flujo de onboarding.
4. CONCEPTO — Solo una especificación, README o descripción de idea. Esta es validación previa a la construcción — la más económica. Las personas validan el problema y la solución propuesta; los hallazgos sobre la interfaz están fuera de alcance.

Informa al usuario en qué modo estás y qué limita eso. Nunca finjas en silencio que los hallazgos del modo CÓDIGO son pruebas de usabilidad. En modo EN VIVO, confirma con el usuario antes de probar cualquier cosa que cueste dinero, envíe correos electrónicos/mensajes reales o mute datos de producción — prefiere una instancia de staging o local.

Fase 1 — Extrae la tesis del producto

No puedes validar contra objetivos que nunca fueron establecidos. Producir una Tesis del Producto y muéstrasela al usuario antes de las pruebas:

• Problema: ¿Qué dolor resuelve esto? (Una oración, sin palabras de solución en ella).
• Para quién: El usuario previsto, específicamente. "Todos" es una bandera roja — señálala como tal.
• Alternativa actual: ¿Qué hacen esas personas ahora en su lugar? (El competidor real suele ser una hoja de cálculo, un chat grupal o no hacer nada).
• Promesa central: Lo que la página de inicio / README / copia de la tienda de aplicaciones realmente afirma.
• Comportamiento de éxito: El único comportamiento observable en la interfaz que prueba el valor, ej. "un usuario primerizo reserva un espacio en menos de 2 minutos." Si el usuario no lo ha definido, propón uno y confírmalo.
• Suposición más riesgosa: La única creencia que, si es incorrecta, mata el producto. Pruébala primero y con más dureza.

Fuéntala desde el README, la copia de la página de inicio, las pantallas de onboarding y las propias palabras del usuario. Cuando las fuentes no estén de acuerdo entre sí, esa contradicción ya es el Hallazgo #1.

Si el usuario está presente, confirma la tesis en un intercambio rápido. Si se ejecuta de forma autónoma, indica tu tesis y suposiciones derivadas explícitamente en el informe.

Mientras hablas con el usuario, evalúa en silencio la confianza del constructor (¿reconoce el riesgo, o cada respuesta es optimista?). Esto calibra el tono del informe final, nunca su evidencia o puntuaciones. Ver references/interview-methods.md.

Fase 2 — Construye la matriz de personas

Lee references/persona-library.md. Instancia personas en las cinco categorías — la dispersión es el punto; probar solo a los fanáticos es cómo los productos mueren sorprendidos:

Categoría	Pregunta que responden	Modo rápido	Modo profundo
Objetivo	¿Sirve a las personas para las que es?	2	3–4
Adyacente	¿Hasta dónde se extiende el ajuste más allá del punto central?	1	2–3
Anti-persona	¿Desperdicia o daña a las personas para las que NO es?	1	2
Escéptico	¿Es lo suficientemente mejor como para vencer su solución actual?	1	2–3
Desinformado	¿Alguien con el problema siquiera reconocería esto como la solución?	1	2

Por defecto, modo rápido (6 personas); usa modo profundo (12–15) cuando el usuario pida una validación exhaustiva/completa. Aplica al menos dos superposiciones de la biblioteca por ejecución (ej. usuario de lector de pantalla, hablante no nativo de inglés, móvil en desplazamiento, ancho de banda bajo) — la accesibilidad y el contexto son demografías, no casos extremos.

Cada persona recibe un resumen independiente: nombre, datos demográficos, nivel técnico, dispositivo + contexto de uso, su versión del problema (o falta de él), qué hacen hoy, presupuesto de paciencia (ej. "90 segundos antes de cerrar la pestaña") y su tarea.

Fase 3 — Entrevistas Mom Test (validación del problema, producto oculto)

Lee references/interview-methods.md. Antes de que cualquier persona vea el producto, realiza una entrevista al estilo Mom Test sobre su vida. Esto separa "¿el problema es real?" de "¿la aplicación funciona?" — los productos fallan en ambos, de forma independiente, y confundirlos produce hallazgos inútiles.

Cada agente de persona responde, en su papel, basado en detalles realistas:

1. ¿Cuándo fue la última vez que te encontraste con [el problema]? Cuéntame exactamente qué pasó.
2. ¿Qué te costó (tiempo, dinero, vergüenza)?
3. ¿Qué hiciste al respecto? ¿Qué has intentado antes? ¿Qué pasó con esos intentos?
4. ¿Alguna vez has pagado — en dinero o esfuerzo de configuración — para resolver esto?

Reglas de Mom Test para interpretar respuestas: el comportamiento pasado es evidencia; los hipotéticos ("yo usaría eso totalmente") no valen nada; "eso es genial" no vale nada; alguien que nunca ha intentado resolver el problema no tiene el problema, sin importar lo que diga. Puntúa la gravedad del problema de cada persona de 0 a 10 basado únicamente en evidencia de comportamiento pasado.

Si las personas objetivo promedian por debajo de 4 aquí, la suposición más riesgosa acaba de fallar — el resto de la ejecución mide la usabilidad de una solución a un problema que la gente no tiene. Continúa, pero dilo claramente.

Fase 4 — Pruebas de interfaz de usuario incorporadas (en paralelo)

Lanza agentes de persona en paralelo (agrupa las llamadas a herramientas Task/Agent en un solo mensaje; si los subagentes no están disponibles, ejecuta las personas secuencialmente tú mismo, completamente en carácter, una a la vez). Cada agente recibe: su resumen de persona, la tesis del producto, el modo de fidelidad y cómo acceder al producto, y este protocolo:

1. Prueba de 5 segundos. Mira solo la primera pantalla. ¿Qué es esto? ¿Para quién es? ¿Qué harías primero? (Personas desinformadas: ¿alguna vez habrías encontrado esta página?)
2. Intenta tu tarea bajo tus limitaciones y presupuesto de paciencia. En modo EN VIVO, opera realmente la interfaz. Narra honestamente — confusión, vacilación, deleite, el momento en que te rendirías. Cuando tu presupuesto de paciencia se agote, di que abandonaste y dónde; terminar la tarea de todos modos es una violación del protocolo.
3. Registra la fricción con evidencia. Cada hallazgo debe citar una pantalla, elemento o fragmento de texto específico — "el muro de registro aparece antes de que se muestre cualquier valor" — nunca sensaciones. Un hallazgo sin una cita de la interfaz se descarta en la síntesis.
4. Mide el tiempo-hasta-valor. Cuenta pantallas, campos y decisiones entre la llegada y el comportamiento de éxito de la tesis. Nota el punto exacto del primer valor real.
5. Entrevista de salida (responde en carácter, honestamente):
   • Sean Ellis: ¿Cómo te sentirías si nunca más pudieras usar esto? Muy decepcionado / algo decepcionado / no decepcionado? ¿Por qué?
   • Cambio: ¿Qué haces hoy, y es esto lo suficientemente mejor como para cambiar? ¿Qué te costaría cambiar?
   • Escalera de confianza: ¿Darías tu correo electrónico? ¿Detalles de pago? ¿Tus datos? ¿Dónde el sí se convierte en no?
   • Sondeo de precio: ¿A qué precio esto se convierte en un no? (No creas tu propio "pagaría cualquier cosa").
   • Retención: Es martes próximo. ¿Qué te haría realmente abrir esto de nuevo? ("Nada" es una respuesta válida e importante).
   • Beneficio neto (especialmente anti-personas): ¿Esta aplicación resolvió más de lo que te costó, o añadió desafíos por los que luego te cobró atención para gestionarlos?

Cada agente devuelve un resultado estructurado: id de persona, resultado de la tarea (completada / abandonada-en-X / bloqueada), registro de fricción con citas, tiempo-hasta-valor, respuestas de la entrevista de salida y puntuaciones de dimensión según references/scoring-rubric.md.

Fase 5 — Pase adversarial

Lee references/adversarial-prompts.md. Primero, si la búsqueda web está disponible, realiza la investigación de evidencia externa de references/interview-methods.md (3–8 búsquedas: competidores/alternativas, sentimiento real de usuarios en Reddit/foros, señales de demanda y momento) — las personas simuladas son un proxy para la investigación de usuarios, y la evidencia del mercado real fundamenta los veredictos escépticos y arma al Agente Asesino. Si la búsqueda no está disponible, anótalo en el informe.

Luego ejecuta tres comprobaciones (en paralelo cuando sea posible):

1. El Agente Asesino. Un agente argumenta que este producto no debería existir: el problema es falso o leve, la alternativa es suficientemente buena, esto es una característica no un producto, las demografías que pagarían no se superponen con las demografías a las que sirve. Debe hacer una defensa robusta — atacar la versión más fuerte de la tesis usando la evidencia de las Fases 3–4.
2. El Refutador. Audita los hallazgos de las personas en busca de adulación y teatro: hallazgos sin citas de la interfaz, personas que completaron tareas más allá de su presupuesto de paciencia declarado, positividad uniforme sospechosa, respuestas de Mom Test que son hipotéticas disfrazadas de evidencia. Los hallazgos refutados son eliminados.
3. Auditoría de ajuste mensaje–mercado. Compara la promesa central (Fase 1) con lo que las personas realmente experimentaron (Fase 4). Cada brecha entre la promesa y la entrega es un generador de abandono, incluso cuando el producto es bueno.
4. Pase de cumplimiento y seguridad (lee references/compliance-security.md) — ejecútalo siempre que el producto recopile datos del usuario, que es casi siempre. Tres partes: un escaneo de aplicabilidad de regulaciones de datos (construye el inventario de datos a partir del código, luego marca los regímenes plausiblemente aplicables — GDPR/CCPA/COPPA/PCI, etiquetas de datos de la tienda de aplicaciones, reglas de divulgación de IA); una diferencia política-vs-producto (cada promesa de "nunca compartido"/"puedes eliminar" verificada contra el código real); y una línea base de seguridad. Para la línea base de seguridad, delega cuando sea posible: si la habilidad security-audit de Cloudflare, /security-review de Claude Code o una herramienta MCP de seguridad está disponible en el entorno, ejecútala e incorpora sus hallazgos confirmados; de lo contrario, ejecuta la lista de verificación de respaldo incorporada. Enmarca toda la salida como un pase de banderas de nivel de ingeniería, no como asesoramiento legal. Un hallazgo CRÍTICO aquí bloquea un veredicto VALIDADO y limita Confianza y Beneficio Neto a 40.

Fase 6 — Síntesis y veredicto

Puntúa las seis dimensiones de la rúbrica solo a partir de la evidencia sobreviviente, luego emite exactamente un veredicto según references/report-template.md:

• VALIDADO — problema real, personas objetivo tienen éxito y volverían; sobrevivió al Agente Asesino. (Raro. Desconfía de ti mismo si lo emites).
• SEÑAL DÉBIL — el problema es real pero el producto pierde valor: la fricción, el tiempo-hasta-valor o los costos de cambio lo están consumiendo. Enumera las correcciones, priorizadas por (personas afectadas × gravedad).
• NO VALIDADO — el problema o la solución fallaron según la evidencia. Di cuál y muestra la evidencia.
• SEÑAL DE PIVOTE — la señal más fuerte provino de algún lugar inesperado: una persona adyacente, un problema diferente, una característica que superó al conjunto. Nombra el pivote de forma concreta.

El informe debe incluir la matriz de ajuste de personas, el argumento más fuerte sobreviviente del Agente Asesino (incluso bajo VALIDADO), el Cementerio de Suposiciones (creencias que soportan carga aún no probadas, cada una con su prueba más económica en el mundo real), una Lista de Correcciones (≤6 elementos: debilidad → acción concreta → señal de éxito), y la rúbrica puntuada — las puntuaciones hacen que las re-ejecuciones sean comparables, así que después de que el usuario implemente correcciones puede ejecutar /reality-check de nuevo y ver los números moverse en lugar de re-discutir sensaciones.

Formato del entregable. Presenta siempre el informe completo en la conversación. Cuando una herramienta de artefacto o renderizado de página web esté disponible (ej. la herramienta Artifact de Claude Code), TAMBIÉN renderiza el informe como una página única compartible: un banner de veredicto con la puntuación compuesta, la tarjeta de puntuación con los umbrales de puerta visibles, la matriz de ajuste de personas, hallazgos con evidencia citada — y una sección de Soluciones que expande cada fila de la Lista de Correcciones en una remediación lista para implementar: el diagnóstico, el cambio prescrito a nivel de archivo/pantalla/texto, a quién desbloquea y la señal de éxito. Los hallazgos diagnostican; las soluciones prescriben — el artefacto debe contener ambos, para que un compañero de equipo que nunca vio la ejecución pueda actuar sobre él. Sin herramienta de renderizado → escribe la misma página en un archivo HTML/markdown local e informa al usuario dónde está.

Termina con la única acción de mayor apalancamiento a continuación. Una. No una lista de veinte.