Descubrimiento de Producto y Validación con Clientes

Skill Arena - Scrum Manager
Enero 2026

---

Tabla de Contenidos

1. Diseño de objetivo de entrevista.
2. Calidad de notas y captura de señal.
3. Síntesis de insights accionables.
4. Enmarcado de problema (JTBD/uso).
5. Mapeo de supuestos y riesgos.
6. Planificación de test de prototipo.
7. Definición de MVP orientado a aprendizaje.
8. Criterios de éxito y señales.
9. Calidad de evidencia y control de sesgos.
10. Decisiones pivot/persevere.
11. Cierre y síntesis.
12. Anexos.

---

Introducción

Propósito y alcance de la guía

Esta guía didáctica está diseñada para desarrollar la capacidad de reducir incertidumbre antes de construir, obteniendo evidencia útil de clientes y mercado. Su propósito es mejorar las habilidades de entrevista, síntesis de información cualitativa, prototipado rápido y toma de decisiones fundamentadas sobre si continuar, iterar o cambiar de dirección.

El alcance de esta guía incluye: diseño y conducción de entrevistas de descubrimiento, toma de notas de calidad, mapeo de supuestos críticos, planificación de tests con prototipos, diseño de experimentos ligeros, interpretación de evidencia cualitativa y cuantitativa, y la colaboración entre las fases de descubrimiento y entrega.

El alcance no incluye: investigación académica profunda, técnicas estadísticas avanzadas, teoría general de design thinking como marco filosófico, ni el uso de herramientas específicas dependientes de versión.

A quién va dirigida y cómo usarla

Esta guía está orientada a profesionales de producto, negocio, growth, UX, consultoría y equipos multidisciplinares que realizan descubrimiento continuo y necesitan criterio sólido para validar supuestos antes de invertir en desarrollo.

Para aprovechar al máximo esta guía, se recomienda:

• Estudiar cada capítulo en orden, ya que existe una progresión natural desde la preparación de entrevistas hasta las decisiones estratégicas de pivote.
• Prestar especial atención a las secciones de errores típicos, pues representan las trampas más frecuentes en la práctica.
• Practicar con los ejercicios y casos situacionales antes de enfrentarse a las evaluaciones.
• Utilizar las listas de verificación como herramientas de trabajo real, no solo como material de estudio.

Cómo aprender usando el banco de preguntas

El banco de preguntas asociado a este tema evalúa habilidades prácticas de decisión situacional y revisión de artefactos. Para aprender eficazmente:

• Analiza el razonamiento detrás de cada respuesta correcta e incorrecta, no solo memorices la opción correcta.
• Identifica los patrones de error que se repiten: confundir opiniones con comportamientos, generalizar desde casos aislados, definir problemas como ausencia de features.
• Practica la evaluación crítica de artefactos como guiones de entrevista, notas, mapas de supuestos y planes de test.
• Desarrolla el hábito de preguntarte "¿qué evidencia sustenta esta afirmación?" antes de cada decisión.

1. Diseño de objetivo de entrevista

Qué vas a conseguir

Al dominar este tema serás capaz de:

• Formular objetivos de entrevista que exploren comportamiento y contexto real, no opiniones superficiales.
• Diseñar guiones que eviten preguntas sugestivas y de confirmación.
• Ajustar el enfoque de cada entrevista según las hipótesis específicas que necesitas explorar.
• Salir de cada conversación con aprendizajes accionables en lugar de respuestas vagas.

Conceptos clave

El propósito real de una entrevista de descubrimiento

Una entrevista de descubrimiento no es una encuesta oral ni una sesión de venta disfrazada. Su propósito fundamental es explorar el comportamiento pasado y el contexto real del usuario para entender sus necesidades genuinas. La diferencia entre una entrevista efectiva y una inútil radica en si buscas aprender algo nuevo o confirmar lo que ya crees.

El objetivo de aprendizaje concreto es el corazón de toda entrevista efectiva. Antes de diseñar cualquier pregunta, debes poder completar la frase: "Queremos aprender [X] y lo sabremos si observamos [Y]". Sin esta claridad, la conversación será difusa y los datos no serán accionables.

Preguntas de comportamiento versus preguntas de opinión

Las preguntas que generan evidencia útil se centran en comportamiento pasado específico, no en intenciones futuras ni preferencias abstractas.

Preguntas que generan señal útil:

• "Cuéntame la última vez que tuviste este problema: cómo lo detectaste, qué hiciste y qué fue lo más difícil."
• "¿Qué intentaste hacer para resolverlo y qué pasó?"
• "Muéstrame cómo lo haces actualmente."

Preguntas que generan ruido:

• "¿Te gustaría tener esta funcionalidad?" — Genera respuestas de cortesía sin valor predictivo.
• "¿Cuántas incidencias crees que podrías resolver si tuvieras alertas automáticas?" — Pide estimaciones especulativas.
• "¿No crees que sería mejor centralizarlo todo en una sola pantalla?" — Es sugestiva y empuja hacia una respuesta.
• "¿Qué opinas de nuestra idea?" — Mezcla descubrimiento con venta.

La distinción clave es temporal: las preguntas útiles apuntan al pasado observable; las preguntas problemáticas apuntan a futuros hipotéticos o a valoraciones abstractas.

La trampa del sesgo de confirmación

Cuando el equipo ya tiene una solución en mente, existe una tendencia natural a diseñar preguntas que confirmen esa idea. Un objetivo como "Validar si los usuarios quieren la nueva pantalla de alta" ya contiene la solución embebida y empuja hacia respuestas que la apoyen.

Reformula siempre hacia la exploración: "Entender cómo se registran hoy, dónde se atascan y qué intentan conseguir" permite descubrir necesidades reales sin predeterminar la solución.

Señales de alerta de que tu objetivo tiene sesgo de confirmación:

• Incluye el nombre de una funcionalidad específica.
• Usa verbos como "validar", "confirmar" o "demostrar" en relación a una solución.
• Define éxito como un número mínimo de respuestas positivas.

Estructura de una entrevista efectiva

La secuencia óptima fluye de lo general a lo específico:

1. Establecer contexto y confianza: dedica los primeros minutos a que el entrevistado se sienta cómodo antes de preguntas más directas.
2. Explorar comportamientos pasados: pregunta sobre rutinas y situaciones específicas recientes relacionadas con el tema.
3. Profundizar en fricciones y motivaciones: una vez identificados puntos de interés, indaga en los detalles mediante preguntas de seguimiento.
4. Validar comprensión: parafrasea lo escuchado y pide confirmación o corrección.
5. Cerrar con opción de seguimiento: agradece y pregunta si puedes contactarle de nuevo.

Errores típicos y cómo evitarlos

Error	Por qué ocurre	Cómo evitarlo
Preguntar "¿te gustaría X?"	Parece directo y eficiente	Reformula hacia comportamiento pasado: "¿Cuándo fue la última vez que...?"
Mezclar venta con descubrimiento	Presión por demostrar valor del producto	Separa las sesiones; en discovery no presentas soluciones
Objetivo vago ("recoger feedback")	Falta de hipótesis clara	Define qué supuesto exploras y qué evidencia lo validaría
Salir sin respuestas accionables	Preguntas demasiado genéricas	Prepara preguntas de seguimiento para profundizar en cada tema

Lista de verificación: preparación de entrevista

• [ ] He definido la hipótesis o supuesto que quiero explorar.
• [ ] He identificado qué evidencia específica validaría o invalidaría esa hipótesis.
• [ ] Mis preguntas se centran en comportamiento pasado, no en opiniones futuras.
• [ ] He revisado el guion para eliminar preguntas sugestivas.
• [ ] He reclutado participantes representativos del segmento objetivo.
• [ ] Tengo un sistema para capturar notas sin perder contacto visual.

2. Calidad de notas y captura de señal

Qué vas a conseguir

Al dominar este tema serás capaz de:

• Capturar hechos, decisiones y fricciones específicas durante las entrevistas.
• Distinguir claramente entre observaciones directas e interpretaciones propias.
• Etiquetar incertidumbres y temas que requieren más exploración.
• Producir notas que permitan una síntesis rigurosa posterior.

Conceptos clave

La jerarquía de la captura de información

Durante una entrevista, debes capturar información en un orden de prioridad específico:

1. Citas textuales: palabras exactas del entrevistado entre comillas. Son datos objetivos verificables.
2. Contexto específico: quién, cuándo, en qué situación. Permite segmentar y priorizar hallazgos.
3. Interpretaciones marcadas: tus inferencias sobre el estado emocional o las motivaciones, claramente etiquetadas como tales.
4. Incertidumbres pendientes: temas que requieren más exploración en futuras entrevistas.

Mezclar estos niveles desde el inicio contamina los datos originales y dificulta la síntesis posterior.

Citas textuales versus valoraciones

La diferencia entre una nota útil y una inútil radica en su verificabilidad.

Notas que capturan señal:

• "Paso 2 horas al día en reuniones de seguimiento" — Cita textual con dato verificable.
• "Usa combinación de email, hoja de cálculo y mensajería para coordinar" — Observación factual sobre herramientas actuales.
• "Mencionó 3 casos esta semana donde el cliente esperó más de 48h" — Hecho concreto con frecuencia.

Notas que pierden señal:

• "Le gusta el sistema actual" — Valoración vaga sin evidencia.
• "Está contenta con los tiempos de respuesta" — ¿Qué tiempos? ¿Comparados con qué?
• "Buena actitud general hacia cambios" — Interpretación sin sustento observable.

Una señal de alerta: si tus notas suenan a adjetivos ("bien", "mal", "le encantó") probablemente te falta evidencia concreta.

Separar observación de interpretación

Es legítimo y útil anotar interpretaciones, pero deben estar claramente marcadas. Usa un sistema de etiquetas:

• [CITA] para palabras textuales del entrevistado.
• [OBS] para observaciones factuales (qué hizo, qué herramientas usó).
• [INTERP] para tus interpretaciones sobre significado o emociones.
• [?] para incertidumbres que requieren seguimiento.

Por ejemplo:

• [CITA] "Paso 20 minutos al día buscando tickets antiguos"
• [OBS] Mostró frustración visible al describir el proceso de búsqueda
• [INTERP] Parece que la findability es un problema mayor que la velocidad
• [?] ¿Cuántos tickets busca típicamente? ¿Qué información necesita de ellos?

Procesamiento post-entrevista

La memoria de detalles cualitativos decae rápidamente. Reserva 15-20 minutos inmediatamente después de cada entrevista para:

1. Completar notas con detalles que recuerdes pero no anotaste.
2. Separar observaciones factuales de interpretaciones personales.
3. Identificar los 3-5 puntos más relevantes para la hipótesis.
4. Documentar preguntas de seguimiento para futuras entrevistas.

Esperar días para completar notas resulta en pérdida de matices importantes que no podrás recuperar.

Errores típicos y cómo evitarlos

Error	Consecuencia	Cómo evitarlo
Notas vagas sin contexto	Imposibilidad de derivar insights accionables	Incluye siempre quién, cuándo, en qué situación
Mezclar datos con interpretaciones	Conclusiones no verificables que parecen datos	Usa marcadores explícitos [CITA], [INTERP]
Registrar solo lo que confirma la hipótesis	Sesgo de confirmación que invalida el discovery	Pregúntate: "¿Anoté algo que no me gustó escuchar?"
Anotar solo conclusiones para "ahorrar tiempo"	Pérdida de evidencia; imposibilidad de revisar	Captura primero datos crudos, concluye después

Lista de verificación: calidad de notas

• [ ] Tengo al menos 3 citas textuales relevantes.
• [ ] He documentado el contexto específico de cada afirmación importante.
• [ ] Mis interpretaciones están claramente marcadas como tales.
• [ ] He señalado incertidumbres que requieren más exploración.
• [ ] He completado las notas dentro de las 2 horas posteriores a la entrevista.
• [ ] Incluí información que contradice mi hipótesis inicial.

3. Síntesis de insights accionables

Qué vas a conseguir

Al dominar este tema serás capaz de:

• Identificar patrones significativos en múltiples fuentes de datos cualitativos.
• Formular insights que conecten observaciones con implicaciones para producto.
• Distinguir entre una cita interesante y un insight validado.
• Priorizar aprendizajes por impacto e incertidumbre.

Conceptos clave

La jerarquía de análisis cualitativo

El análisis cualitativo asciende a través de cuatro niveles, cada uno sustentado por el anterior:

1. Observación: dato específico de una fuente individual. Ejemplo: "Ana mencionó que tarda 30 minutos buscando documentos."
2. Patrón: recurrencia detectada en múltiples fuentes. Ejemplo: "6 de 10 entrevistados mencionaron fricciones con la búsqueda de información."
3. Insight: comprensión nueva que conecta el patrón con una causa o motivación. Ejemplo: "Los usuarios pierden tiempo porque la estructura de carpetas no refleja cómo piensan sobre los proyectos."
4. Implicación: acción o decisión derivada del insight. Ejemplo: "Deberíamos explorar una navegación basada en proyectos además de carpetas."

La confusión más común es llamar "insight" a una cita interesante o a un patrón sin interpretación. Un insight válido siempre responde: "¿Qué aprendimos que no sabíamos y qué significa para el producto?"

De citas a patrones: el proceso de agrupación

El primer paso de la síntesis es agrupar observaciones similares por temas emergentes. Esto requiere:

1. Revisión exhaustiva: lee todas las notas sin intentar categorizarlas inicialmente.
2. Identificación de temas: agrupa citas que tratan sobre el mismo fenómeno.
3. Cuantificación: cuenta cuántas fuentes diferentes mencionan cada tema.
4. Priorización: ordena por frecuencia y por relevancia para las hipótesis.

La cuantificación es crucial: "varios usuarios mencionaron problemas de velocidad" es menos útil que "7 de 12 entrevistados mencionaron fricciones relacionadas con tiempo de espera".

El error de generalizar desde un caso aislado

Un comentario de un único usuario es un dato interesante, no un insight validado. Generalizar a partir de un caso aislado ("Los usuarios necesitan integración con Slack" basado en una cita de una persona) puede llevar a priorizar funcionalidades que solo interesan a una minoría.

Antes de formular un insight, verifica: ¿En cuántas fuentes diferentes aparece este patrón? La regla práctica es buscar evidencia en al menos 3-5 fuentes antes de afirmar un patrón.

Excepciones como señales

Cuando la mayoría de entrevistados coincide pero algunos casos no encajan, no descartes las excepciones como "ruido". Analiza qué tienen en común los casos diferentes:

• ¿Tienen un rol diferente?
• ¿Usan el producto de otra manera?
• ¿Su contexto organizacional es distinto?

Las excepciones a menudo revelan segmentos con necesidades diferentes o casos de uso que no habías considerado. La pregunta clave es: "¿Qué tienen en común entre sí estos casos que no encajan?"

Estructura de un insight bien formulado

Un insight efectivo sigue la estructura:

"Observamos que [patrón cuantificado] porque [interpretación de causa]. Esto implica que deberíamos [acción concreta]."

Ejemplo bien formulado:

"Observamos que 5 de 8 usuarios mencionan fricciones con contenido demasiado largo porque sus jornadas fragmentadas no permiten sesiones de aprendizaje extensas. Esto implica que deberíamos evaluar formato de microlearning como alternativa."

Ejemplo mal formulado:

"Los usuarios necesitan una experiencia más personalizada." — Genérico, sin patrón cuantificado, sin causa, sin implicación específica.

Errores típicos y cómo evitarlos

Error	Por qué es problemático	Cómo evitarlo
Lista de citas sin agrupación	No permite ver patrones ni priorizar	Agrupa por temas y cuantifica recurrencia
Generalizar desde un caso	Puede priorizar necesidades de una minoría	Verifica patrón en al menos 3-5 fuentes
Insight sin implicación práctica	No guía decisiones de producto	Añade "esto significa que deberíamos..."
Ignorar casos contradictorios	Pierde información sobre posibles segmentos	Documenta excepciones y explora qué las diferencia

---

4. Enmarcado de problema (JTBD/uso)

Qué vas a conseguir

Al dominar este tema serás capaz de:

• Separar síntoma, causa y necesidad subyacente en cualquier solicitud de usuarios.
• Describir problemas en términos de situación, motivación y resultado esperado.
• Identificar las alternativas actuales que los usuarios emplean.
• Evitar definir problemas como "falta de feature".

Conceptos clave

La trampa de definir el problema como ausencia de solución

Uno de los errores más frecuentes y costosos en producto es definir el problema como "falta de X funcionalidad". Cuando el equipo recibe solicitudes como "necesitamos exportación a PDF", la tendencia natural es asumir que el problema es la ausencia de esa función.

Sin embargo, "Los usuarios no tienen un botón de exportación a PDF" embebe la solución en el problema y cierra la exploración. Las preguntas que deberían hacerse son:

• ¿Para qué necesitan el PDF?
• ¿A quién se lo envían?
• ¿Qué hacen con él después?

Quizás necesitan compartir datos con stakeholders externos, y un enlace compartible sería mejor solución que un PDF. Reformula siempre: "El usuario intenta lograr [objetivo] pero actualmente [fricción] porque [causa]".

Estructura del Job-to-be-Done

Un JTBD bien formulado describe el progreso que el usuario busca, independiente de soluciones específicas. La estructura canónica es:

"Cuando [situación específica], quiero [progreso o motivación], para [resultado esperado]."

Ejemplo bien formulado:

"Cuando coordino entregables entre 3 equipos remotos, quiero visibilidad del estado real de cada tarea, para anticipar bloqueos antes del deadline. Actualmente uso combinación de email + hoja de cálculo compartida."

Ejemplo mal formulado:

"Cuando necesito gestionar mi trabajo, quiero una herramienta fácil de usar, para ser más productivo."

La diferencia es la especificidad: el primer ejemplo describe una situación concreta, un progreso observable y un resultado medible; el segundo es genérico y circular.

Componentes esenciales de un buen enmarcado

1. Situación o contexto: el disparador específico que genera la necesidad. No es suficiente decir "cuando trabajo"; debe ser "cuando coordino entregables entre 3 equipos remotos".

2. Motivación o progreso: lo que el usuario intenta lograr expresado como cambio de estado. No es la funcionalidad deseada sino el resultado intermedio.

3. Resultado final: el beneficio último que el usuario espera obtener. Conecta con sus objetivos más amplios.

4. Alternativas actuales: cómo resuelve el problema hoy. Esto define el estándar a superar y revela restricciones reales.

Del síntoma a la causa raíz

El enmarcado correcto requiere excavar bajo el síntoma visible:

1. Identificar el síntoma: lo que el usuario reporta directamente. "El sistema es lento."
2. Explorar causas: mediante preguntas de seguimiento. "¿Qué estabas intentando hacer cuando lo sentiste lento?"
3. Definir la necesidad: en términos de resultado deseado. "Necesito encontrar información específica rápidamente para tomar decisiones."
4. Documentar contexto: restricciones y situaciones de uso relevantes.

A menudo, el síntoma "lento" revela un problema de findability (encontrar información), no de rendimiento técnico. Optimizar la base de datos no resolverá frustraciones de búsqueda.

Errores típicos y cómo evitarlos

Error	Ejemplo	Cómo reformular
Problema como falta de feature	"No tienen exportación a PDF"	"Necesitan compartir datos con externos de forma que puedan consultarlos offline"
JTBD circular	"Quiero gestionar proyectos para ser más productivo"	Especifica situación concreta y resultado observable
Ignorar alternativas actuales	"Ninguna alternativa identificada"	Siempre hay alternativas: email, Excel, papel, ignorar el problema
Saltar a solución	"El problema es que necesitan un dashboard"	Describe la fricción sin prescribir la solución

Lista de verificación: enmarcado de problema

• [ ] He descrito la situación específica que dispara la necesidad.
• [ ] El progreso deseado está expresado sin mencionar funcionalidades.
• [ ] He documentado las alternativas que el usuario usa actualmente.
• [ ] He separado el síntoma visible de la causa subyacente.
• [ ] El enmarcado permite explorar múltiples soluciones posibles.

---

5. Mapeo de supuestos y riesgos

Qué vas a conseguir

Al dominar este tema serás capaz de:

• Identificar y hacer explícitos los supuestos implícitos de cualquier proyecto.
• Clasificar supuestos por tipo: deseabilidad, viabilidad y factibilidad.
• Priorizar qué supuestos validar primero usando criterios de impacto e incertidumbre.
• Proponer tests proporcionados al nivel de riesgo de cada supuesto.

Conceptos clave

Los tres tipos de supuestos

Todo proyecto nuevo descansa sobre supuestos de tres categorías:

Deseabilidad: ¿Los usuarios quieren esto? ¿El problema es real y prioritario para ellos?

• "Los equipos de finanzas tienen este problema como prioridad."
• "Los usuarios cambiarán de su herramienta actual."
• "Están dispuestos a pagar 200€/mes por resolverlo."

Viabilidad: ¿Es un negocio sostenible? ¿Podemos capturar valor?

• "El boca a boca será suficiente para crecer."
• "El coste de adquisición será menor que el valor de vida del cliente."
• "Podemos operar con márgenes positivos."

Factibilidad: ¿Podemos construirlo? ¿Tenemos las capacidades técnicas?

• "El equipo puede implementar la API en 6 semanas."
• "El servidor actual soporta la carga esperada."
• "Podemos integrar con los sistemas existentes."

El error de priorizar lo fácil sobre lo crítico

Un patrón común es que los equipos priorizan validar supuestos técnicos (factibilidad) porque son más fáciles de testear internamente, dejando sin explorar los supuestos de mercado.

Sin embargo, si nadie pagará 200€/mes por tu solución, la capacidad técnica de construirla es irrelevante. La secuencia correcta para la mayoría de productos nuevos es:

1. Deseabilidad primero: ¿El problema existe y es prioritario?
2. Viabilidad después: ¿Es un negocio sostenible?
3. Factibilidad al final: ¿Podemos construirlo técnicamente?

Invertir en factibilidad antes de validar demanda puede resultar en un producto técnicamente sólido que nadie quiere.

Criterios de priorización

Usa una matriz de dos dimensiones para priorizar supuestos:

Impacto si es falso: ¿Qué tan grave sería para el proyecto si este supuesto resulta incorrecto?

• Alto: el proyecto no tiene sentido si es falso (ej: disposición a pagar).
• Medio: requiere ajustes significativos (ej: canal de distribución).
• Bajo: es solucionable con cambios menores (ej: capacidad de soporte).

Incertidumbre: ¿Qué tan seguros estamos de que es verdadero?

• Alta: no tenemos datos ni experiencia previa.
• Media: tenemos indicios pero no evidencia sólida.
• Baja: tenemos datos o experiencia que lo respaldan.

Prioriza el cuadrante de alto impacto + alta incertidumbre, aunque sea difícil de testear.

Supuestos implícitos del liderazgo

Los supuestos más peligrosos suelen ser los que nadie cuestiona porque vienen de la dirección. Frases como "los usuarios cambiarán sin resistencia" o "el boca a boca será suficiente" son supuestos de alto riesgo que merecen validación.

Incorporar estos supuestos al mapa los hace visibles y evaluables objetivamente. Evitar el tema por jerarquía perpetúa puntos ciegos que pueden hundir el proyecto.

Proceso de mapeo de supuestos

1. Listar todos los supuestos: haz el listado inicial en equipo; diferentes roles ven supuestos que otros dan por obvios.
2. Clasificar por tipo: deseabilidad, viabilidad, factibilidad.
3. Evaluar cada uno: por impacto si es falso y por incertidumbre.
4. Priorizar para validar: empieza por los de alto impacto y alta incertidumbre.
5. Diseñar tests: proporcionales al nivel de riesgo.

Errores típicos y cómo evitarlos

Error	Consecuencia	Cómo evitarlo
Validar lo fácil, no lo crítico	Supuestos letales quedan sin explorar	Usa matriz impacto × incertidumbre
Supuestos implícitos nunca listados	Puntos ciegos que hunden el proyecto	Sesión explícita de mapeo con todos los roles
Prioridad invertida (factibilidad antes que deseabilidad)	Construir algo que nadie quiere	Sigue la secuencia: deseabilidad → viabilidad → factibilidad
Supuestos vagos no testeables	No se pueden validar ni invalidar	Reformula con criterios medibles

Lista de verificación: mapeo de supuestos

• [ ] He listado supuestos de deseabilidad, viabilidad y factibilidad.
• [ ] He incluido supuestos implícitos del liderazgo o la cultura del equipo.
• [ ] Cada supuesto está formulado de manera testeable.
• [ ] He evaluado cada uno por impacto-si-falso e incertidumbre.
• [ ] Los supuestos de deseabilidad están priorizados sobre los técnicos.
• [ ] Tengo un plan de test proporcional al riesgo de cada supuesto crítico.

---

6. Planificación de test de prototipo

Qué vas a conseguir

Al dominar este tema serás capaz de:

• Diseñar tareas realistas que generen señal de usabilidad genuina.
• Definir criterios observables de éxito sin contaminar los resultados.
• Minimizar los sesgos del moderador y de los participantes.
• Extraer conclusiones válidas sin sobregeneralizar.

Conceptos clave

Tareas como objetivos, no como instrucciones

El error más común en tests de prototipo es diseñar tareas que indican exactamente cómo completarlas, eliminando la señal de descubribilidad.

Tarea problemática:

"Pulsa el botón verde de 'Nuevo proyecto' arriba a la derecha, rellena el formulario y guarda usando el icono de disquete."

Tarea efectiva:

"Crea un nuevo proyecto llamado 'Prueba Q1'."

La diferencia es fundamental: la primera evalúa si el usuario sigue instrucciones; la segunda revela si el diseño es intuitivo, dónde se confunde y qué modelo mental aplica.

Reformula siempre las tareas como objetivos sin indicar el método, y observa el camino que sigue el usuario.

El problema del moderador creador

Cuando el diseñador que creó el prototipo modera las sesiones de test, introduce sesgos sutiles pero significativos:

• Sesgo de confirmación: interés emocional en el éxito del diseño.
• Guía inconsciente: puede indicar sutilmente el "camino correcto".
• Interpretación sesgada: tiende a atribuir confusiones al usuario, no al diseño.
• Ayuda excesiva: su conocimiento del diseño le lleva a "aclarar dudas" que eliminan señal.

La solución es separar roles: usa un moderador neutral que no haya participado en el diseño, y el creador observa sin intervenir.

Participantes representativos versus participantes convenientes

Testear con compañeros del equipo o amigos introduce múltiples sesgos:

• Conocen el contexto y la terminología interna.
• Tienen incentivos sociales para ser positivos.
• No representan al segmento objetivo real.

La señal obtenida de participantes internos está fundamentalmente comprometida. Para obtener datos válidos, recluta usuarios externos representativos del segmento objetivo, aunque sea más difícil y costoso.

Observar comportamiento versus pedir opiniones

Los tests de prototipo deben generar datos sobre comportamiento, no sobre preferencias.

Enfoque problemático:

• "¿Te gusta el diseño?"
• "¿Qué te parece esta pantalla?"
• "¿Lo usarías si tuvieras esto?"

Enfoque efectivo:

• Observar dónde hace clic primero.
• Registrar pausas y expresiones de confusión.
• Cronometrar el tiempo hasta completar la tarea.
• Notar qué elementos ignora o no encuentra.

El criterio de éxito no es "que diga que sí" sino métricas observables: tasas de completitud, errores cometidos, tiempo requerido, elementos no descubiertos.

Niveles de fidelidad según el objetivo

El nivel de fidelidad del prototipo debe corresponder al objetivo del test:

Objetivo	Fidelidad recomendada
Validar si el concepto se entiende	Bocetos en papel, wireframes
Explorar flujo de navegación	Prototipo clickable de media fidelidad
Evaluar usabilidad de interacciones específicas	Prototipo de alta fidelidad
Testear propuesta de valor	Landing page

El error típico es construir alta fidelidad para todo, desperdiciando tiempo. Regla: usa la fidelidad mínima que responda tu pregunta de investigación.

Errores típicos y cómo evitarlos

Error	Señal de advertencia	Cómo corregirlo
Tareas guiadas	Las instrucciones mencionan ubicaciones o elementos específicos	Reformula como objetivos sin indicar método
Moderador es el creador	El diseñador propone moderar "porque conoce mejor el diseño"	Asigna moderador neutral; diseñador observa
Participantes internos	Los 5 participantes son compañeros del equipo	Recluta usuarios externos del segmento objetivo
Pedir opiniones	Las tareas preguntan "¿te gusta?" o "¿qué te parece?"	Diseña tareas que generen comportamiento observable

Lista de verificación: plan de test de prototipo

• [ ] Las tareas están formuladas como objetivos sin indicar el método.
• [ ] El moderador no participó en el diseño del prototipo.
• [ ] Los participantes son externos y representativos del segmento.
• [ ] Los criterios de éxito son observables y medibles.
• [ ] Tengo un protocolo para registrar comportamiento sin intervenir.
• [ ] La fidelidad del prototipo es apropiada para el objetivo del test.

7. Definición de MVP orientado a aprendizaje

Qué vas a conseguir

Al dominar este tema serás capaz de:

• Diseñar MVPs como experimentos de aprendizaje, no como "versiones pequeñas de todo".
• Definir la hipótesis principal y qué señal la validaría.
• Eliminar elementos que no aportan al aprendizaje buscado.
• Considerar alternativas no-producto como concierge o mago de Oz.

Conceptos clave

MVP como experimento, no como producto reducido

El error más extendido es entender MVP como "producto con menos funcionalidades". Un MVP real es el mínimo necesario para aprender algo específico, no el mínimo necesario para tener un producto.

Enfoque erróneo:

"MVP incluye: registro, perfil, notificaciones, dashboard, integraciones, panel admin. Hipótesis: los usuarios usarán la plataforma. Criterio: publicar en 6 semanas."

Esto es un backlog de componentes, no un experimento de aprendizaje. La hipótesis es genérica y no hay criterio de validación.

Enfoque correcto:

"Hipótesis: Los equipos de finanzas pagarán 200€/mes por un servicio que automatice la reconciliación de facturas. MVP: Servicio concierge donde hacemos la reconciliación manualmente para 5 clientes durante 2 semanas. Criterio: al menos 3 de 5 solicitan continuar y están dispuestos a pagar."

La diferencia fundamental: el primero construye para luego "ver qué pasa"; el segundo aprende antes de construir.

Alternativas no-producto

Antes de escribir código, considera si puedes validar la hipótesis con alternativas más ligeras:

• MVP Concierge: entregas el servicio manualmente, visible para el usuario. Valida si hay demanda real y disposición a pagar antes de automatizar.

• MVP Mago de Oz: el usuario cree que interactúa con un sistema automático, pero hay operación humana oculta. Valida la experiencia de usuario sin invertir en desarrollo.

• MVP Landing Page: una página que describe la propuesta de valor y captura intención (email, reserva, prepago). Valida interés inicial antes de construir nada funcional.

• MVP Single Feature: el mínimo código necesario para testear una hipótesis específica, sin infraestructura adicional.

La regla es: "¿Cuál es lo mínimo para aprender X?" no "¿Cuál es el mínimo producto funcional?"

El costo de "no escalar"

Un argumento frecuente contra las alternativas manuales es que "no escalan". Pero en etapas tempranas, la escalabilidad es irrelevante:

• Si nadie quiere el servicio manual, no hay nada que escalar.
• Si hay demanda, habrás validado antes de invertir en automatización.
• El costo de operar manualmente para 10 usuarios es muy inferior al costo de desarrollar una plataforma completa.

Descartar opciones no-producto porque "no escalan" desperdicia la oportunidad de aprender rápido y barato.

Errores típicos y cómo evitarlos

Error	Consecuencia	Cómo evitarlo
MVP como lista de funcionalidades	Scope creep, pérdida de velocidad	Define primero la hipótesis, luego el mínimo para testarla
Sin hipótesis definida	Incapacidad de interpretar resultados	Formula "Creeremos que [X] si observamos [Y]"
Sin criterio de éxito previo	Racionalización post-hoc de cualquier resultado	Establece umbrales antes de lanzar
Descartar alternativas manuales	Inversión innecesaria cuando un test manual habría bastado	Siempre pregunta "¿Podemos validar esto sin código?"

Tipos de MVP según la hipótesis a validar

Hipótesis a validar	Tipo de MVP recomendado
¿Hay interés inicial en la propuesta?	Landing page con captura de email
¿Pagarían por este servicio?	Concierge con servicio manual
¿La experiencia propuesta resuelve el problema?	Mago de Oz con operación humana oculta
¿Esta funcionalidad específica tiene valor?	Single feature con mínimo código

Lista de verificación: definición de MVP

• [ ] He definido la hipótesis principal que quiero validar.
• [ ] He especificado qué señal validaría o invalidaría la hipótesis.
• [ ] He considerado alternativas no-producto (concierge, mago de Oz, landing).
• [ ] Cada elemento incluido aporta al aprendizaje buscado.
• [ ] Tengo un criterio de éxito definido antes de lanzar.
• [ ] El alcance es realmente el mínimo para aprender, no el mínimo para tener un producto.

8. Criterios de éxito y señales

Qué vas a conseguir

Al dominar este tema serás capaz de:

• Establecer criterios de éxito antes de ejecutar cualquier experimento.
• Definir métricas primarias, secundarias y guardrails.
• Reconocer los límites de confianza según el tamaño de muestra.
• Evitar el p-hacking informal y la racionalización post-hoc.

Conceptos clave

El principio de definición previa

El criterio de éxito debe definirse antes de lanzar el experimento, no después de ver los resultados. Definir "qué nos parece bueno" a posteriori es una forma de p-hacking informal que permite racionalizar cualquier resultado como éxito.

Criterio problemático:

"Métricas a medir: visitas, tiempo en página, scroll depth, clics, bounce rate, conversiones, shares. Criterio de éxito: Decidiremos después de ver los datos qué resultados nos parecen buenos."

Criterio válido:

"Métrica primaria: tasa de conversión ≥5% con al menos 200 visitas. Guardrail: bounce rate <70%. Definido el 15 de enero, antes del lanzamiento."

La diferencia: el segundo no deja espacio para ajustar el criterio según convenga.

Jerarquía de métricas

Un experimento bien diseñado distingue entre tipos de métricas con funciones diferentes:

• Métrica primaria: determina éxito o fracaso del experimento. Debe ser una sola, claramente definida, con umbral específico.

• Métricas secundarias: proporcionan contexto adicional sin cambiar la decisión de éxito/fracaso. Ayudan a entender el "por qué" pero no definen el "qué".

• Guardrails: alertan si el experimento causa daño colateral. Son umbrales que no deben cruzarse, independientemente del resultado de la métrica primaria.

• Métricas de diagnóstico: ayudan a explicar las causas de los resultados. Útiles para la iteración posterior.

La confusión típica es tener múltiples "métricas primarias", lo que diluye el criterio y permite cherry-picking post-hoc.

Límites del tamaño de muestra

Con muestras pequeñas, las fluctuaciones normales pueden parecer señales significativas. Un experimento con 50 usuarios puede mostrar variaciones de ±10% o más solo por azar.

Criterio problemático:

"Umbral de éxito: cualquier incremento positivo valida la hipótesis."

Con n=50, "cualquier incremento positivo" no es significativo. Deberías definir el efecto mínimo detectable dada tu muestra esperada y reconocer explícitamente los límites de confianza del resultado.

Antes de lanzar, calcula: ¿Qué tamaño de efecto puedo detectar de forma confiable con esta muestra? Si necesitas detectar diferencias del 5% pero tu muestra solo permite detectar diferencias del 20%, tu experimento no responderá la pregunta.

El problema del grupo de control

Sin grupo de control, no puedes atribuir cambios a tu intervención. Un incremento en sesiones diarias después de activar notificaciones podría deberse a estacionalidad, otras campañas, o factores externos.

El diseño mínimo para atribuir causalidad incluye:

• Grupo de tratamiento que recibe la intervención.
• Grupo de control equivalente que no la recibe.
• Aleatorización en la asignación.

Sin estos elementos, los resultados son correlacionales, no causales.

Errores típicos y cómo evitarlos

Error	Consecuencia	Cómo evitarlo
Definir umbral después de ver resultados	P-hacking que permite justificar cualquier cosa	Documenta criterios con fecha antes de lanzar
Medir muchas métricas sin priorizar	Capacidad de seleccionar la favorable post-hoc	Define una métrica primaria clara
Umbral de "cualquier mejora"	Confundir ruido con señal	Calcula efecto mínimo detectable dada la muestra
Sin grupo de control	Conclusiones de causalidad injustificadas	Diseña con grupo control cuando sea posible

Lista de verificación: criterios de éxito

• [ ] Tengo una única métrica primaria claramente definida.
• [ ] El umbral de éxito está especificado numéricamente.
• [ ] Los criterios están documentados con fecha anterior al lanzamiento.
• [ ] He definido guardrails para detectar daño colateral.
• [ ] He calculado si mi muestra esperada permite detectar el efecto relevante.
• [ ] Si busco causalidad, tengo grupo de control.

9. Calidad de evidencia y control de sesgos

Qué vas a conseguir

Al dominar este tema serás capaz de:

• Ponderar la calidad de evidencia cualitativa y cuantitativa.
• Detectar sesgos comunes en cómo se obtuvo la señal.
• Diferenciar correlación de causalidad en contextos prácticos.
• Pedir evidencia adicional cuando la existente es insuficiente.

Conceptos clave

Los cuatro sesgos críticos

Sesgo de confirmación: buscar e interpretar información que apoya creencias previas. Se manifiesta cuando el equipo solo ve los datos que confirman su idea y descarta o minimiza los contradictorios.

Mitigación: pregunta activamente "¿Qué evidencia contradiría nuestra hipótesis?" y búscala con el mismo rigor que la evidencia favorable.

Sesgo de supervivencia: analizar solo casos exitosos ignorando los que fallaron. Ocurre cuando encuestas de satisfacción se envían solo a usuarios que completaron un proceso, excluyendo a quienes abandonaron.

Mitigación: incluye explícitamente a los que "no sobrevivieron" (abandonaron, fracasaron, se fueron) en tu muestra.

Sesgo de selección: muestra no representativa del segmento objetivo real. Típico cuando reclutamos participantes de nuestra red de contactos o usuarios existentes más enganchados.

Mitigación: define criterios de selección antes de reclutar y verifica que la muestra refleja tu segmento objetivo, no tu audiencia cautiva.

Sesgo de deseabilidad social: respuestas que buscan agradar al investigador o proyectar una imagen favorable. Los usuarios tienden a decir que "usarían" o "pagarían" para no parecer negativos.

Mitigación: enfócate en comportamiento pasado observable en lugar de intenciones futuras. "¿Cuánto pagaste la última vez?" es más fiable que "¿Cuánto pagarías?".

Señales de evidencia débil

No toda evidencia tiene el mismo peso. Aprende a reconocer señales de evidencia que parece validación pero no lo es:

• Likes y comentarios en redes: son señales de bajo coste que no implican disposición a pagar ni uso real. 47 likes en un post de LinkedIn no validan demanda.

• Feedback de la red propia: amigos, contactos y suscriptores existentes tienen incentivos sociales para ser positivos. "3 amigos emprendedores dijeron que lo usarían" no es validación.

• Apertura de emails: una tasa de apertura del 89% en tu newsletter indica que tienes buenos suscriptores, no que tu nuevo producto tendrá demanda.

• Evidencia más sólida incluye: reservas con pago, registros de desconocidos, cartas de intención de clientes fuera de tu red, comportamiento observable (no declarado).

Correlación versus causalidad

En contextos prácticos de producto, es fácil confundir correlación con causalidad:

• "Después de añadir la feature, aumentaron las conversiones" no significa que la feature causó el aumento.
• "Los usuarios que usan X feature tienen mayor retención" no significa que X causa retención (quizás los usuarios más comprometidos simplemente usan más features).

Para reclamar causalidad necesitas: grupo de control, aleatorización, y control de factores confundidores. Sin estos elementos, mantén la humildad epistémica: "observamos correlación" es diferente de "X causa Y".

Errores típicos y cómo evitarlos

Error	Ejemplo	Cómo evitarlo
Tomar likes como validación	"47 likes = demanda validada"	Busca señales de compromiso real (pago, tiempo invertido)
Seleccionar participantes sesgados	"Encuestamos a usuarios que completaron onboarding"	Incluye a quienes abandonaron o fracasaron
Ignorar señales contradictorias	"2 usuarios negativos son outliers"	Investiga qué diferencia a los casos contradictorios
Concluir causalidad sin control	"Después de X, pasó Y, entonces X causó Y"	Reconoce límites: "observamos correlación"

Lista de verificación: calidad de evidencia

• [ ] He identificado posibles sesgos en cómo se obtuvo la muestra.
• [ ] La evidencia incluye señales de compromiso real, no solo opiniones.
• [ ] He buscado activamente evidencia que contradiga mi hipótesis.
• [ ] Distingo explícitamente entre correlación y causalidad.
• [ ] He incluido a usuarios que abandonaron o fracasaron, no solo a los exitosos.
• [ ] La muestra es representativa del segmento objetivo, no de mi red de contactos.

10. Decisiones pivot/persevere

Qué vas a conseguir

Al dominar este tema serás capaz de:

• Integrar evidencia mixta con coste de oportunidad para tomar decisiones.
• Evitar la falacia del coste hundido y el apego emocional a las ideas.
• Diseñar siguientes experimentos razonables cuando hay incertidumbre residual.
• Comunicar decisiones con trade-offs claros a stakeholders.

Conceptos clave

Las opciones reales ante evidencia

Ante resultados de un experimento, las opciones no son binarias. El espectro completo incluye:

1. Perseverar: la evidencia es suficientemente positiva para continuar en la dirección actual.
2. Iterar: ajustar elementos específicos manteniendo la dirección general.
3. Pivotar: cambiar un aspecto fundamental (segmento, propuesta de valor, canal) manteniendo los aprendizajes.
4. Parar: abandonar la iniciativa porque la evidencia indica que no es viable.

La mayoría de decisiones reales caen en los casos intermedios (iterar, pivotar), no en los extremos.

La falacia del coste hundido

Uno de los sesgos más peligrosos en decisiones de producto es justificar perseverar por el tiempo o recursos ya invertidos:

"Llevamos 6 meses trabajando en esto y el equipo está muy comprometido. Además, los 2 usuarios que completaron fueron muy entusiastas."

El tiempo invertido es irrelevante para la decisión futura. Lo relevante es: dada la evidencia actual, ¿cuál es la mejor inversión de los próximos recursos?

Señales de alerta de coste hundido:

• Argumentos que mencionan "el esfuerzo invertido" o "lo que hemos construido".
• Enfocarse en los pocos casos positivos ignorando la mayoría negativa.
• Resistencia emocional a considerar el pivote o el abandono.

Capturar aprendizajes antes de pivotar

Un pivote responsable no es un cambio de dirección impulsivo. Requiere:

1. Documentar qué se aprendió: ¿por qué no funcionó? ¿Qué supuestos eran falsos?
2. Formular nueva hipótesis: basada explícitamente en los aprendizajes anteriores.
3. Validar antes de invertir: diseñar un experimento para la nueva dirección antes de comprometer recursos de desarrollo.
4. Comunicar con transparencia: compartir tanto los aprendizajes como el razonamiento detrás del cambio.

Pivotar sin capturar aprendizajes arriesga repetir los mismos errores. La frase clave es: "Aprendimos que [hipótesis anterior] era falsa porque [evidencia]. La nueva hipótesis es [X] y la validaremos con [experimento]."

Señales que sugieren considerar un pivote

• La mayoría de usuarios no completa el flujo propuesto.
• Hay confusión recurrente con la propuesta de valor (no con la interfaz).
• El problema que resolvemos no es prioritario para el segmento.
• La disposición a pagar es significativamente menor a lo necesario.
• Segmentos diferentes muestran necesidades contradictorias.

Marco de decisión ante evidencia mixta

Cuando la evidencia no es claramente positiva ni negativa, considera:

Factor	Preguntas clave
Calidad de la evidencia	¿Es suficientemente robusta para decidir? ¿Hay sesgos en la muestra?
Magnitud de las señales	¿Las diferencias son significativas o podrían ser ruido?
Coste de oportunidad	¿Qué otras iniciativas estamos dejando de hacer?
Reversibilidad	¿Podemos iterar o la decisión es definitiva?
Incertidumbre residual	¿Un experimento adicional aclararía la situación?

Si la incertidumbre residual es alta y el coste de un experimento adicional es bajo, diseña un test más específico antes de decidir.

Errores típicos y cómo evitarlos

Error	Señal de advertencia	Cómo evitarlo
Perseverar por apego	"Hemos invertido demasiado para cambiar"	Evalúa solo la evidencia futura, no el pasado
Pivotar sin aprendizaje	"Esto no funcionó, probemos otra cosa"	Documenta qué fue falso y por qué antes de cambiar
Concluir con señal débil	"2 de 15 completaron, suficiente para seguir"	Define umbrales de decisión antes del experimento
Ignorar coste de oportunidad	Continuar por inercia	Compara explícitamente con alternativas

Lista de verificación: decisión pivot/persevere

• [ ] He evaluado la evidencia sin considerar el esfuerzo ya invertido.
• [ ] He documentado los aprendizajes del intento actual.
• [ ] Si pivoto, tengo una nueva hipótesis basada en los aprendizajes.
• [ ] Si la evidencia es mixta, he considerado un experimento adicional.
• [ ] He evaluado el coste de oportunidad de continuar.
• [ ] Puedo comunicar la decisión con trade-offs claros.

Cierre y síntesis

Mapa conceptual del descubrimiento de producto

El proceso de descubrimiento sigue un flujo iterativo que conecta todos los temas de esta guía:

┌─────────────────────────────────────────────────────────────────┐
│                    CICLO DE DESCUBRIMIENTO                      │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  1. ENMARCAR EL PROBLEMA (Cap. 4)                               │
│     → Separar síntoma de causa                                  │
│     → Definir JTBD sin prescribir solución                      │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  2. MAPEAR SUPUESTOS (Cap. 5)                                   │
│     → Listar supuestos de deseabilidad, viabilidad, factibilidad│
│     → Priorizar por impacto × incertidumbre                     │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  3. DISEÑAR EXPERIMENTO                                         │
│     → Entrevistas (Cap. 1, 2, 3)                                │
│     → Tests de prototipo (Cap. 6)                               │
│     → MVP de aprendizaje (Cap. 7)                               │
│     → Definir criterios de éxito (Cap. 8)                       │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  4. EVALUAR EVIDENCIA (Cap. 9)                                  │
│     → Detectar sesgos en la muestra                             │
│     → Ponderar calidad de la señal                              │
│     → Distinguir correlación de causalidad                      │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│  5. DECIDIR (Cap. 10)                                           │
│     → Perseverar / Iterar / Pivotar / Parar                     │
│     → Capturar aprendizajes                                     │
│     → Comunicar con trade-offs claros                           │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
                    [Volver a paso 1 o 2]

Principios transversales

A lo largo de todos los capítulos, emergen principios que aplican de forma transversal:

• Evidencia sobre opinión: siempre prioriza datos observables sobre preferencias declaradas. El comportamiento pasado predice mejor que las intenciones futuras.

• Definir antes de medir: los criterios de éxito, las hipótesis y los umbrales deben establecerse antes de recoger datos, no después de verlos.

• Mínimo para aprender: tanto en MVPs como en experimentos, pregunta "¿cuál es lo mínimo necesario para aprender X?" no "¿cuál es lo mínimo funcional?"

• Excepciones como señales: los casos que "no encajan" a menudo revelan segmentos valiosos o supuestos falsos. Invierte en entenderlos.

• Separar observación de interpretación: en notas, en síntesis, en decisiones. Mantén clara la distinción entre lo que viste y lo que crees que significa.

Recomendaciones de estudio

Para preparar las evaluaciones de este tema:

1. Practica la evaluación crítica: lee artefactos (guiones, notas, planes de test, criterios de éxito) y pregúntate: ¿Qué defecto tiene? ¿Cómo lo mejoraría?

2. Desarrolla el hábito de cuestionar: ante cualquier afirmación, pregunta: ¿Qué evidencia la sustenta? ¿Qué sesgos podrían afectarla?

3. Estudia los errores típicos: cada capítulo incluye errores frecuentes. Asegúrate de reconocerlos cuando aparezcan.

4. Aplica las listas de verificación: úsalas como herramientas de trabajo, no solo de estudio. La práctica real consolida el aprendizaje.

5. Conecta los temas: el descubrimiento es un proceso integrado. Entiende cómo cada tema alimenta al siguiente.

Anexos

Anexo A: glosario

Concierge MVP: técnica de validación donde el servicio se entrega manualmente, visible para el usuario, antes de automatizar.

Deseabilidad: dimensión de validación que evalúa si los usuarios quieren la solución y si el problema es prioritario para ellos.

Factibilidad: dimensión de validación que evalúa si es técnicamente posible construir la solución propuesta.

Guardrail: métrica que alerta si un experimento causa daño colateral, independientemente del resultado de la métrica primaria.

Insight: comprensión nueva que conecta un patrón observado con una causa o motivación, derivando implicaciones para producto.

JTBD (Job-to-be-Done): marco para describir el progreso que el usuario busca lograr, expresado como situación, motivación y resultado esperado.

Mago de Oz MVP: técnica de validación donde el usuario cree interactuar con un sistema automático, pero hay operación humana oculta.

MVP: producto Mínimo Viable; el mínimo necesario para validar una hipótesis específica (no "versión pequeña de todo").

Patrón: recurrencia de una observación en múltiples fuentes de datos cualitativos.

P-hacking: práctica de manipular análisis estadísticos (formal o informalmente) hasta obtener resultados favorables.

Pivote: cambio de dirección estratégica basado en aprendizajes validados, manteniendo lo aprendido y reformulando hipótesis.

Sesgo de confirmación: tendencia a buscar, interpretar y recordar información que confirma creencias previas.

Sesgo de supervivencia: error de analizar solo casos exitosos, ignorando los que fallaron o abandonaron.

Viabilidad: dimensión de validación que evalúa si el modelo de negocio es sostenible y permite capturar valor.

Anexo B: plantilla de notas de entrevista

ENTREVISTA DE DESCUBRIMIENTO

Fecha: _______________
Entrevistado: _______________ (rol, contexto)
Entrevistador: _______________
Hipótesis a explorar: _______________

---

CITAS TEXTUALES [CITA]
"..."
"..."
"..."

---

OBSERVACIONES FACTUALES [OBS]
- Herramientas que usa actualmente:
- Frecuencia del problema:
- Alternativas que ha probado:
- Contexto específico:

---

INTERPRETACIONES [INTERP]
(Marcar claramente como inferencias propias)
-
-

---

INCERTIDUMBRES Y SEGUIMIENTO [?]
-
-

---

PUNTOS CLAVE PARA SÍNTESIS
1.
2.
3.

---

Notas completadas inmediatamente después: [ ] Sí [ ] No

---

Anexo C: matriz de priorización de supuestos

Supuesto	Tipo (D/V/F)	Impacto si falso (1-5)	Incertidumbre (1-5)	Prioridad (I×U)	Test propuesto

Tipos:

• D = Deseabilidad.
• V = Viabilidad.
• F = Factibilidad.

Regla de priorización: Comenzar por los de mayor puntuación (Impacto × Incertidumbre), priorizando D sobre V sobre F cuando hay empate.