Propósito: Esta guía lleva al equipo desde el Press Release redactado en el Tema 1 hasta una PoC interactiva que valida los Jobs To Be Done identificados en el Mapa de Empatía. No se requiere programación. Solo pensamiento estratégico y prompts bien construidos.
PRESS RELEASE (Tema 1)
↓
MAPA DE EMPATÍA + JTBD (Sesión 2)
↓
┌───────────────────────────────┐
│ PARTE 1: PARTY ROCK (AWS) │ → Lógica de negocio + IA conversacional
└───────────────────────────────┘
↓
┌───────────────────────────────┐
│ PARTE 2: LOVABLE │ → Interfaz web-móvil interactiva
└───────────────────────────────┘
↓
┌───────────────────────────────┐
│ PARTE 3: VALIDACIÓN JTBD │ → ¿El prototipo resuelve el pain-point?
└───────────────────────────────┘
↓
DEMO DAY READY ✅
| Herramienta | URL | Acción requerida |
|---|---|---|
| Party Rock AWS | partyrock.aws |
Crear cuenta gratuita con email institucional |
| Lovable | lovable.dev |
Crear cuenta gratuita (GitHub o Google) |
| Miro | miro.com |
Acceder al board del curso (link en Bloque Neón) |
| Google Docs | docs.google.com |
Tener el Press Release del Tema 1 abierto |
Antes de comenzar, asegúrate de tener respuestas claras a: 1. ¿Cuál es el Job To Be Done principal de tu app? 2. ¿Cuál es el micro-momento en el que el usuario lo necesita? 3. ¿Cuál es el pain-point #1 identificado en el Mapa de Empatía?
Party Rock es una plataforma de AWS que permite construir aplicaciones de IA generativa de forma visual, sin código. Funciona combinando widgets de entrada (lo que el usuario ingresa) con widgets de IA (modelos como Claude o Llama que procesan la información). El resultado simula la lógica de negocio de una app real.
partyrock.aws e inicia sesión con tu cuenta AWS o
cuenta de AWS Builder ID (gratuita).[NombreApp]_PoC_[NombreEquipo].Crea los siguientes widgets según tu caso de uso. Para añadir un widget: haz clic en “+ Add Widget” → “User Input”.
| Widget | Tipo recomendado | Ejemplo para app de pagos |
|---|---|---|
| Perfil del usuario | Text Input (multilínea) | “Soy Juan, 28 años, independiente en Bogotá” |
| Contexto de uso | Text Input | “Quiero pagar el domicilio de Rappi pero no tengo efectivo” |
| Urgencia / Micro-momento | Dropdown | Opciones: Urgente / Normal / Planificado |
| Objetivo del Job | Text Input | “Pagar sin comisiones en 3 toques” |
Tip estratégico: Cada widget de entrada debe corresponder a una dimensión del Mapa de Empatía (Piensa/Siente, Ve, Dice/Hace, Oye). Esto garantiza que la PoC refleja insights reales del usuario y no suposiciones del equipo.
Haz clic en “+ Add Widget” → “AI”. Selecciona el modelo Claude (Anthropic) o Llama 3.
SYSTEM PROMPT:
Eres el motor de personalización de [NombreApp], una app de [categoría] para
el mercado colombiano. Tu trabajo es analizar el perfil y contexto del usuario
y generar una propuesta de valor personalizada de máximo 3 líneas.
Formato de respuesta:
🎯 Tu solución: [beneficio principal en máximo 15 palabras]
⚡ En este momento: [acción inmediata disponible]
💰 Tu ventaja: [diferenciador vs competencia en máximo 10 palabras]
USER PROMPT:
Perfil: {{Widget_Perfil}}
Contexto: {{Widget_Contexto}}
Urgencia: {{Widget_Urgencia}}
Job: {{Widget_Objetivo}}
SYSTEM PROMPT:
Eres el diseñador de experiencia de [NombreApp]. Basándote en el usuario
descrito, genera el flujo de onboarding de 5 pasos que maximiza la
activación en los primeros 3 minutos.
Para cada paso especifica:
- 📱 Pantalla: [nombre de la pantalla]
- 👆 Acción del usuario: [qué hace exactamente]
- 🎁 Valor entregado: [qué recibe / qué aprende]
- ✍️ Micro-copy del botón: [texto del CTA principal, ≤5 palabras]
USER PROMPT:
{{Widget_Perfil}} quiere {{Widget_Objetivo}}.
Contexto situacional: {{Widget_Contexto}}.
Genera el onboarding más efectivo para este Job To Be Done.
SYSTEM PROMPT:
Eres el sistema de comunicaciones de [NombreApp]. Genera exactamente 3 push
notifications event-driven (basadas en comportamiento) para el usuario descrito.
Para cada push incluye:
- 🔔 Título (≤50 caracteres, con emoji)
- 📝 Cuerpo (≤100 caracteres)
- ⚡ Trigger que la activa (evento específico del usuario)
- 🕐 Timing recomendado (cuándo después del trigger)
USER PROMPT:
Usuario: {{Widget_Perfil}}
Job principal que quiere completar: {{Widget_Objetivo}}
Contexto de uso: {{Widget_Contexto}}
SYSTEM PROMPT:
Eres un consultor de mobile strategy de McKinsey especializado en LatAm.
Evalúa la viabilidad de esta app en 3 dimensiones:
1. MERCADO: ¿Existe un segmento suficientemente grande con este JTBD?
2. CANAL: ¿App nativa, PWA o micro-canal? ¿Por qué?
3. RIESGO: ¿Cuál es el mayor riesgo estratégico de este modelo?
Sé directo, usa datos de referencia de LatAm y da una recomendación final en
máximo 2 oraciones.
USER PROMPT:
App propuesta: {{Widget_Perfil}} [aquí el equipo describe su idea]
Job To Be Done: {{Widget_Objetivo}}
{{NombreDelWidget}} para
referenciar el output de otros widgets.Cada integrante del equipo ingresa los datos de un usuario real del mapa de empatía: - ¿La IA genera respuestas coherentes con el JTBD definido? - ¿Las push notifications suenan auténticas o genéricas? - ¿El onboarding resuelve el pain-point identificado?
Entregable Party Rock: URL del Playground compartido (botón “Share” → “Anyone with the link”) + 3 capturas de pantalla de outputs con perfiles distintos.
Lovable es un generador de aplicaciones web que convierte instrucciones en lenguaje natural en interfaces funcionales con React. Produce código real que puedes ver, editar y compartir con un link público. Sin instalaciones, sin programación, en menos de 10 minutos tienes tu primera versión.
Ve a lovable.dev, haz clic en “Start
building” e ingresa el prompt base. Tómate 15 minutos
en construirlo bien: la calidad del output depende directamente
de la calidad del prompt.
Crea una aplicación web mobile-first para [NombreApp].
CONTEXTO DEL USUARIO TARGET:
[Descripción del usuario: ej. "Millennials colombianos 25-35 años,
independientes, usan smartphone como principal herramienta financiera.
Pain-point principal: las transferencias de dinero tienen demasiados pasos
y comisiones ocultas"]
JOB TO BE DONE PRINCIPAL:
"Cuando [contexto], quiero [acción], para poder [resultado]"
[Pega tu JTBD aquí]
PANTALLAS REQUERIDAS (5 pantallas, diseño mobile 375px):
1. SPLASH / ONBOARDING: Headline que capture el beneficio en 5 palabras.
Subtítulo explicativo. Botón CTA principal y opción "Ver demo".
2. REGISTRO SIMPLIFICADO: Máximo 3 campos. Botón de registro con Google/Apple.
Indicador de progreso. Texto de confianza ("Tus datos están protegidos").
3. HOME / DASHBOARD: Mostrar el valor entregado al usuario (saldo, puntos,
progreso). 3 acciones principales con íconos. Bienvenida personalizada
con nombre del usuario. Sección de actividad reciente (3 ítems de ejemplo).
4. PANTALLA DEL FLUJO PRINCIPAL: Donde ocurre el Job To Be Done.
Indicador de progreso de 3 pasos. Máximo 3 campos de input.
Feedback visual en tiempo real. CTA claro y prominente.
5. CONFIRMACIÓN / ÉXITO: Animación de celebración (confetti o checkmark
animado). Resumen de la acción completada. Botones de "Compartir" y
"Volver al inicio". Invitación sutil al próximo uso.
IDENTIDAD VISUAL:
- Color primario: [HEX de tu marca, ej. #00B0BA para teal]
- Color secundario: [HEX complementario]
- Estilo: moderno, minimalista, confiable (inspiración: Nubank, Nequi)
- Fuente: Inter o Poppins
- Íconos: Lucide o Heroicons, tamaño consistente
INTERACTIVIDAD REQUERIDA:
- Navegación entre las 5 pantallas con botones funcionales
- Estado activo visible en el paso del flujo principal
- Al menos un elemento con animación CSS suave (fade-in, slide-up)
- Responsive pero optimizado para 375px (iPhone 14 Pro)
Una vez generada la versión inicial (espera 60-90 segundos), refina con prompts específicos:
Para mejorar el Home Dashboard:
En el Home, la sección de "Actividad reciente" debe mostrar transacciones
con ícono de categoría (comida, transporte, servicios), monto en COP con
formato $XX.XXX, fecha relativa ("Hace 2 horas") y color verde para ingresos
y rojo suave para gastos.
Para agregar micro-interacciones:
En la pantalla de flujo principal, cuando el usuario completa cada uno de
los 3 pasos del indicador de progreso, agrega un micro-animation de checkmark
verde con una pequeña vibración sutil. El paso activo debe tener el color
primario y los completados una línea de conexión verde.
Para mejorar la pantalla de éxito:
La pantalla de confirmación debe mostrar un círculo grande con checkmark
animado que aparece con ease-in-out en 0.5 segundos. Debajo, muestra una
tarjeta con el resumen de la operación (datos de ejemplo). El botón de
compartir debe tener ícono de WhatsApp y el texto "Comparte con tus amigos".
Para mobile-first perfecto:
Revisa que toda la app funcione perfectamente en 375px de ancho. Asegúrate
de que: los botones tengan mínimo 44px de altura, los textos sean legibles
(mínimo 14px body), haya suficiente padding lateral (16px mínimo), y ningún
elemento se corte o superponga.
Entregable Lovable: Link público de la app + video de pantalla del flujo en smartphone.
Esta sección es la más estratégica de la guía. Aquí conectas el prototipo con los insights del Mapa de Empatía y verificas que la PoC resuelve el pain-point real.
NOMBRE DE LA APP: _______________________________________________
JOB TO BE DONE PRINCIPAL IDENTIFICADO EN EL MAPA DE EMPATÍA:
"Cuando [contexto]: ____________________________________________,
quiero [acción]: _______________________________________________,
para poder [resultado]: ________________________________________"
PAIN-POINT #1 DEL MAPA DE EMPATÍA:
_______________________________________________________________
PREGUNTA DE VALIDACIÓN: ¿Cómo resuelve tu prototipo este pain-point?
Para cada pregunta, el equipo debe dar una respuesta concreta basada en el prototipo:
Referencia: ¿Cuántos pasos necesita el usuario para completar su Job en el prototipo de Lovable?
| Pain-point identificado | Pasos en competencia actual | Pasos en tu PoC | Fricción reducida |
|---|---|---|---|
| [Tu pain-point] | [Número] | [Número] | [Sí/No - % reducción] |
Prueba con 3 perfiles distintos de usuarios del mapa de empatía:
| Perfil de usuario | Output de Party Rock | ¿Resuelve el Job? | Ajuste necesario |
|---|---|---|---|
| Usuario 1: [desc] | [Captura/resumen] | Sí / Parcialmente / No | [Ajuste] |
| Usuario 2: [desc] | [Captura/resumen] | Sí / Parcialmente / No | [Ajuste] |
| Usuario 3: [desc] | [Captura/resumen] | Sí / Parcialmente / No | [Ajuste] |
| Criterio | Tu elección | Justificación basada en JTBD |
|---|---|---|
| Frecuencia de uso esperada | [X veces/semana] | |
| ¿Necesita push notifications? | Sí / No | |
| ¿Requiere acceso offline? | Sí / No | |
| ¿El usuario instalará una app? | Alta / Media / Baja probabilidad | |
| Canal recomendado | App / PWA / Wallet / QR |
Criterio de evaluación: Una push es contextual si menciona un evento específico del usuario y genera urgencia legítima. Es genérica si podría enviarse a cualquier usuario en cualquier momento.
| Push generada por Party Rock | Contextual (✅) / Genérica (⚠️) | Trigger correcto (✅/⚠️) |
|---|---|---|
| Push #1: [texto] | ||
| Push #2: [texto] | ||
| Push #3: [texto] |
El Mom Test (Rob Fitzpatrick, 2013) propone que una solución es válida si alguien que te quiere (y no quiere herirte) la usaría en la vida real.
Instrucciones: Muestra el prototipo de Lovable a alguien fuera del equipo (un familiar, un compañero de otro grupo) sin explicar nada. Observa si:
Resultado del Mom Test: ________________ / 4 criterios cumplidos
Al completar las 3 partes de esta guía, el equipo debe redactar la siguiente declaración:
DECLARACIÓN DE VALIDACIÓN DE PoC
Equipo: _______________________ App: _______________________
Nuestro prototipo resuelve el Job To Be Done:
"Cuando [contexto], quiero [acción], para poder [resultado]"
Lo resuelve de la siguiente manera:
- En Party Rock: [descripción de la lógica de negocio implementada]
- En Lovable: [descripción de la interfaz y el flujo]
- Reducción de fricción: de [X] pasos a [Y] pasos
El pain-point principal "[dolor]" se aborda mediante:
[Descripción de la solución en 2-3 oraciones]
Limitaciones actuales del prototipo y próximos pasos:
1. [Limitación 1 y cómo se resolvería en la versión real]
2. [Limitación 2 y cómo se resolvería en la versión real]
KPIs que mediríamos desde el día 1:
- KPI de activación: [ej. % usuarios que completan onboarding en sesión 1]
- KPI de retención: [ej. Retención Day-7]
- KPI de negocio: [ej. ARPU / GMV / NPS]
| Criterio | Peso | Indicadores de excelencia |
|---|---|---|
| Claridad estratégica del JTBD | 20% | El equipo articula con precisión el Job, el micro-momento y el canal elegido. La conexión con el mapa de empatía es evidente. |
| Funcionalidad del prototipo Lovable | 25% | Flujo completo navegable en 375px. Diseño coherente con la marca. Mínimo 4 de 5 pantallas funcionales. |
| Inteligencia de los widgets Party Rock | 20% | Los prompts generan outputs contextuales y diferenciados. Las push notifications son event-driven, no genéricas. |
| Validación del JTBD | 20% | El framework de validación está completo. El Mom Test supera 3/4 criterios. La declaración de validación es específica. |
| Storytelling del pitch | 15% | El equipo presenta en ≤7 minutos. El problema es emocional. La solución es memorable. Los KPIs son realistas. |
aws.amazon.com/developer/communitydiscord.gg/lovableproducthunt.com/topics/mobileGuía elaborada para el curso Estrategias de Mobile Marketing · Especialización en Inteligencia de Mercados · Universidad de los Andes · Prof. Juan Pablo Gómez Bravo · 2026
Herramientas: Party Rock AWS · Lovable · Miro · Working Backwards (Amazon)