Psicología Antes del Producto: Cómo Construimos WaitlistQuiz

Hace dos semanas tomé una decisión que podría ahorrarnos meses de esfuerzo desperdiciado. No fue una feature. No fue un design sprint. Fue simplemente una pregunta: ¿Y si escuchamos antes de construir?

La mayoría de los startups lo hace al revés. Construyen un producto basado en suposiciones sobre quién lo necesita. Luego lanzan. Luego se sorprenden cuando las personas que llegan no son las que diseñaron.

Decidimos invertir eso. Antes de escribir una sola línea de código para Ledger, LabelLoop, PAIP y Pólizas, construimos un sistema para entender la psicología de las personas que podrían querer usarlos.

Ese sistema es WaitlistQuiz.

Por Qué la Psicología Importa Más que las Features

Esto es lo que aprendí: saber qué feature estás construyendo importa menos que saber el estado emocional de la persona que la va a usar.

Dos usuarios pueden necesitar organización de emails. Pero uno de ellos ha probado cinco aplicaciones distintas y está en estado de indefensión aprendida. El otro nunca ha probado nada y solo necesita un punto de entrada sin fricción. La feature es la misma. La psicología es completamente diferente.

Tu copy, tu onboarding, tu pricing, tu soporte — todo cambia según esa diferencia.

Así que hicimos algo poco convencional: construimos quizzes no para capturar emails, sino para capturar psicología.

La Arquitectura

Cada una de las cuatro landing pages tiene su propio quiz. Pero todas siguen la misma arquitectura:

Capa 1: Las Preguntas (Activación del Sistema 1)

Cada pregunta en WaitlistQuiz tiene un principio psicológico integrado. Así se ordenan:

  1. Anclar el Problema (Preguntas 1-2)

    • “¿Cuántos emails de gastos recibes por semana?”
    • “Al fin de mes, ¿sabes exactamente cuánto gastaste?”

    Estas activan el pensamiento Sistema 1 (rápido, emocional, basado en identidad). El usuario se reconoce en el problema.

  2. Construir Coherencia (Preguntas 3-4)

    • “¿Qué has intentado hasta ahora?”
    • “¿Qué te frustra más?”

    Ahora el usuario está construyendo una narrativa. Está generando coherencia interna. No está solo respondiendo preguntas — se está contando una historia sobre su propia incapacidad para resolver este problema.

  3. Activar el Compromiso (Preguntas 5-6)

    • “¿Con qué frecuencia revisas tu Gmail?”
    • “Si esto lo resolviera mañana, ¿qué cambiaría?” (texto libre)

    La pregunta de texto libre es la trampa. Una vez que escriben qué cambiaría, ya decidieron que lo quieren. El signup es solo la conclusión natural.

Capa 2: Reglas de Segmentación

Aquí es donde la psicología se convierte en data:

Cada usuario cae en uno de 3-4 segmentos, según sus respuestas. Para Ledger:

Para LabelLoop, los segmentos son distintos: El Inbox Rehab Profile, El Inbox Architect, El Clean Slate Profile. Cada producto tiene segmentos calibrados a su psicología real de usuario.

El matching es ponderado. Si las respuestas de un usuario activan múltiples segmentos, el sistema elige el de mayor peso. Ocurre en el browser, así que el resultado es instantáneo.

Capa 3: El API Capture

Cuando alguien hace click en “Únete a la Lista de Espera”, todo su recorrido se persiste:

{
  "productSlug": "ledger",
  "email": "user@example.com",
  "segmentName": "El Resignado Productivo",
  "answers": {
    "1": 3,
    "2": 3,
    "3": [4],
    "4": 2,
    "5": 1,
    "6": "Podría finalmente tener un presupuesto real..."
  },
  "submittedAt": "2026-04-12T14:32:00Z"
}

Cada línea es una historia de usuario completa. No solo “quiero organizar mis finanzas.” Sino por qué. Cómo llegaron acá. Qué han intentado ya.

El Problema Real (Astro + Slots)

Aquí es donde el Build in Public se complica: tenemos un problema que aún no resolvemos.

El componente WaitlistQuiz se supone que debe ser compartido entre las cuatro landing pages. Pero en realidad, cada proyecto tiene su propia copia:

src/web-landings/
├── ledger/src/shared/components/WaitlistQuiz.astro
├── labelloop/src/shared/components/WaitlistQuiz.astro
├── paip/src/shared/components/WaitlistQuiz.astro
└── polizas/src/shared/components/WaitlistQuiz.astro

¿Por qué? Porque Astro slots + event binding + SSG hydration no funciona bien cuando intentas pasar configuraciones dinámicas de quiz desde múltiples landing pages a un único componente compartido. El script is:inline pierde contexto. El define:vars se duplica.

Intentamos: Astro Islands, web components, delegación de scripts. Nada fue limpio.

Así que tomamos el camino pragmático: clonar el componente en cada proyecto. Viola DRY. Lo sabemos. Pero garantiza que cada instancia tenga acceso limpio a su propia config, sin colisiones de ID y cero sorpresas en preview o producción.

¿Es lo ideal? No. ¿Es honesto sobre dónde estamos? Sí.

Esto es el ticket Linear LANDING-027. Lo estamos trackeando. Lo vamos a resolver. Pero no vamos a bloquear el lanzamiento por arquitectura perfecta.

Lo Que Aprendimos (40 Respuestas, Data Real)

El quiz está live en Ledger y LabelLoop. En una semana, tenemos ~40 respuestas completas. Los patrones ya son visibles:

Ledger:

LabelLoop:

El hallazgo más importante: La pregunta 4 (dominancia del pain point) está cambiando directamente nuestro copy.

Los usuarios que marcan “Pierdo tiempo buscando información que ya tengo” reciben headlines sobre eficiencia.

Los que marcan “Las apps me hacen ingresar todo manualmente” reciben headlines sobre “cero input manual.”

Los que marcan “No tengo visibilidad hasta que el daño ya está hecho” reciben headlines sobre control en tiempo real.

Ya no estamos adivinando. Los usuarios nos están escribiendo el copy.

Por Qué Importa en Build in Public

Todos hablan de “escuchar a tus usuarios.” Pero la mayoría lo hace después del lanzamiento.

Decidimos: ¿y si realmente escuchamos antes de lanzar?

Esto no es sofisticado. No es una feature novedosa. Es solo la realización honesta de que:

  1. No sabes quién es tu usuario hasta que se lo preguntas
  2. Preguntar revela no solo qué necesitan, sino por qué lo necesitan
  3. La psicología es data
  4. La data cambia decisiones

Las decisiones que estamos tomando ahora mismo son:

La Invitación

Si llegas a una de nuestras landing pages y ves el quiz:

  1. Responde con honestidad. No hay respuestas “correctas”. Cada respuesta es combustible para la siguiente iteración.
  2. Comparte tu resultado. Si tu segmento te representa, compártelo. Es distribución orgánica con señalización de identidad.
  3. Dinos si nos equivocamos. La pregunta 6 siempre es texto libre. Úsala para hacerle agujeros a nuestras suposiciones.

Qué Sigue

En dos semanas, PAIP y Pólizas van live con sus quizzes. Tendremos ~200 respuestas totales entre cuatro productos. Ahí es cuando emergen los patrones reales.

Después de eso, migramos de JSONL local a Vercel Blob, para que la data sea persistente entre ambientes de preview, producción y analytics.

Y vamos a resolver el problema del componente compartido en Astro. No forzando arquitectura perfecta. Sino encontrando el patrón que realmente funciona para quizzes dinámicos en un monorepo.

Esto es Build in Public en el medio caótico: no compartir las victorias, sino compartir las luchas. No mostrar el producto pulido, sino el pensamiento que viene antes del producto.

Ese es el punto.

Links:

Estado técnico:

Data hasta ahora:

El próximo post será sobre cómo usamos la psicología de segmentos para escribir emails distintos para distintos tipos de usuario. Spoiler: el Resignado recibe un mensaje muy diferente al del Curioso.

Build in Public significa mostrar el pensamiento, no solo los resultados.