Investigación de usuarios que mueve el roadmap, no solo confirma suposiciones

El PM ya había decidido. El documento del roadmap tenía tres sprints de profundidad, los tickets de Jira estaban redactados y el engineering manager tenía una estimación preliminar. Entonces el equipo de diseño dijo "probablemente deberíamos hablar con los usuarios primero", y se agendó un proyecto de investigación.

Cinco llamadas. Cinco clientes seleccionados a mano por el CSM porque eran "comprometidos y dispuestos a conversar." Un documento en Notion con dieciséis citas, cuatro de ellas discretamente favorables, ninguna sorprendente. El PM leyó el resumen, dijo "esto confirma lo que pensábamos" y publicó la funcionalidad seis meses después. La adopción se estabilizó en el 11%. La retrospectiva post-lanzamiento lo llamó "un problema de mensajería."

No era un problema de mensajería. Era un problema de investigación disfrazado de investigación con usuarios. El estudio no fracasó porque la metodología fuera incorrecta. Fracasó porque nadie estaba dispuesto a dejar que cambiara la decisión. Eso no es investigación. Es una ceremonia.

Si ha estado atrapado en este ciclo y está cansado de él, este es el playbook. Cubre cuándo usar qué tipo de investigación, cómo dimensionar los estudios correctamente, cómo escribir hallazgos que sobrevivan a un PM escéptico y cómo escapar de la trampa de "los usuarios dijeron que quieren X" que silenciosamente orienta los roadmaps SMB según quien gritó más fuerte en el último QBR.

Investigación generativa vs evaluativa: elija primero la herramienta correcta

La forma más rápida de desperdiciar un presupuesto de investigación es elegir la categoría equivocada. La investigación generativa responde "¿qué problema estamos resolviendo?" La investigación evaluativa responde "¿lo que construimos resuelve ese problema?" Parecen similares desde afuera (ambas involucran usuarios, ambas producen citas), pero responden preguntas en direcciones opuestas y requieren tamaños de muestra, reclutamiento y aceptación de stakeholders diferentes.

La mayoría de los equipos B2B SaaS recurren a la evaluativa cuando la pregunta real es generativa. Alguien dice "necesitamos probar el nuevo dashboard" y se agenda una prueba de usabilidad antes de que nadie haya preguntado si el dashboard es lo correcto que construir. Para cuando se ejecuta la prueba, la respuesta que puede dar es estrecha: si los usuarios encuentran los botones. La pregunta que importaba (¿debería existir este dashboard?) ya no está sobre la mesa porque el prototipo ya está construido.

Use la tabla como función de forzamiento. Antes de especificar un estudio, escriba la decisión que el equipo está a punto de tomar. Si la decisión es "¿deberíamos construir esto?", necesita investigación generativa. Si es "¿deberíamos publicar la versión que construimos?", necesita evaluativa. Si es "¿deberíamos iterar sobre la versión que publicamos?", necesita continua. La mayoría de las solicitudes de "necesitamos investigación de usuarios" son en realidad una de estas tres, y quien hace la solicitud por lo general no sabe cuál.

La prueba de usabilidad con 5 usuarios: la regla real de Nielsen, no el meme

El artículo de Jakob Nielsen de 1993 encontró que 5 usuarios son suficientes para identificar aproximadamente el 85% de los problemas de usabilidad en un estudio. Ese número se comprimió en "siempre pruebe con 5" y ha sido citado por personas que no han leído el artículo durante treinta años. La regla de los 5 usuarios se cumple bajo condiciones específicas, y esas condiciones son más estrechas de lo que la mayoría de los equipos de producto asume.

La regla aplica cuando tiene un segmento de usuario, realizando una tarea, en una interfaz. Un nuevo usuario registrándose. Un administrador configurando un ajuste único. Un usuario final archivando un informe de gastos. Dentro de ese alcance, la matemática se sostiene: para el usuario 5 ya ha visto la mayoría de los problemas, y para el usuario 8 está viendo repeticiones.

La regla se rompe en el momento en que cualquiera de esas condiciones se rompe:

• Múltiples personas. Si su producto B2B tiene administradores, usuarios finales e IT, necesita 5 de cada uno. Eso son 15 sesiones, no 5. Los administradores se confunden con cosas que los usuarios finales nunca ven.
• Problemas conceptuales, no de interacción. La regla de los 5 usuarios detecta "no pude encontrar el botón." No detecta "no entiendo para qué existe esta funcionalidad." El malentendido conceptual aparece a tasas bajas por usuario pero importa más: necesita de 12 a 15 para detectarlo con fiabilidad.
• Flujos de trabajo con ramificaciones. Un flujo de registro lineal se prueba bien con 5. Un flujo de trabajo con 6 ramas condicionales necesita cobertura de muestra en cada rama. Puede ejecutar 5 usuarios y observar que 4 de ellos nunca llegan a la rama donde vive el error.
• Comparación entre segmentos. Si la pregunta es "¿funciona esto para SMB y para enterprise?", necesita un estudio dimensionado para una comparación a nivel de segmento, que es un mínimo de 8 a 12 por segmento.

Cuando un stakeholder diga "hagamos solo 5", pregunte qué persona, qué tarea y qué decisión informará el resultado. Si la decisión es "publicar o no publicar para toda nuestra base de usuarios", 5 no son suficientes. Si la decisión es "¿está roto este flujo de registro para nuevos usuarios SMB específicamente?", 5 podría ser suficiente.

Pruebas no moderadas: Maze, UserTesting, Lyssna y lo que ocultan

Las plataformas de pruebas no moderadas han cambiado la velocidad a la que un diseñador puede ejecutar un estudio evaluativo. Maze, UserTesting y Lyssna permiten enviar un prototipo a 50 testers y tener resultados el viernes. La velocidad es real. También lo es el costo.

Las pruebas no moderadas ganan en tres cosas: velocidad (entrega en 24 a 72 horas), alcance (puede reclutar paneles que nunca conseguiría en una llamada moderada) y comparación cuantitativa (A/B test de dos diseños a escala). Para tareas claras y de bajo contexto dirigidas a una audiencia amplia, es difícil superarlas.

Pierden en tres cosas, y los productos B2B se topan con las tres:

1. Flujos de trabajo complejos. Los estudios moderados permiten observar a un usuario pensar en voz alta, preguntar "¿por qué hizo clic ahí?" y profundizar cuando se bloquea. Sin moderación, obtiene un video de alguien haciendo clic en lo incorrecto en silencio y continuando. Aprende que fallaron. No aprende por qué.
2. Interfaces con jerga especializada. Los productos B2B están llenos de términos que los usuarios solo entienden en contexto. Un tester no moderado de un panel adivinará, fallará y calificará la prueba como "fácil" porque no sabe lo que no sabe. La prueba produce datos de apariencia limpia y brechas silenciosas de comprensión.
3. La pregunta del "por qué". Cualquier cosa que requiera entender intención, motivación o razonamiento de compensación necesita un moderador. Las herramientas no moderadas han mejorado en las preguntas de seguimiento, pero una pregunta de seguimiento grabada obtiene una respuesta ensayada. Un moderador en vivo obtiene la real.

Las tasas de finalización reales lo respaldan. Para tareas orientadas al consumidor, las pruebas B2C no moderadas tienen entre el 80% y el 95% de finalización. Para flujos de trabajo B2B SaaS, espere entre el 60% y el 75%. Esa brecha importa al dimensionar: un estudio que necesita n=20 sesiones válidas en un flujo B2B necesita de 28 a 32 inicios para alcanzarlo. Planifique la deserción.

La trampa en la que caen la mayoría de los equipos: eligen no moderada porque es rápida y luego toman decisiones que necesitaban la profundidad de una moderada. Maze le dice la tasa de clics. No le dice que 4 de 12 usuarios SMB no tenían idea de qué significaba "tenant" en su panel de configuración de IT y simplemente adivinaron la respuesta correcta.

La trampa de "la investigación mostró que los usuarios quieren X"

Aquí es donde muere la mayoría de la investigación B2B. El sesgo de selección, el sesgo de recencia y el sesgo de confirmación se acumulan, y un estudio con ocho participantes se convierte en un roadmap construido para una audiencia que no tiene.

El sesgo de selección proviene de quién responde a la convocatoria. El customer success elige a los clientes comprometidos porque responden el correo. Los clientes comprometidos tienen más probabilidades de ser enterprise, más probabilidades de ser administradores y más probabilidades de querer funcionalidades que hagan más poderoso su flujo de trabajo existente. Tome una muestra de 8 de ellos y escuchará un mensaje unificado: más permisos, más roles, más controles de nivel enterprise. Si su negocio es 70% SMB por ARR, acaba de ejecutar un estudio orientado al 30% que de todas formas no necesitaba ayuda.

El sesgo de recencia proviene del último cliente ruidoso. Un QBR ocurrió la semana pasada, el VP escuchó a una cuenta de 400.000 dólares y "los usuarios quieren SSO" entró en el documento de planificación como una cita sin n adjunto. Para cuando se reclutan participantes para la investigación, la pregunta que se hace no es "¿los usuarios quieren SSO?" sino "¿cuánto quieren los usuarios SSO?", y el reclutamiento filtra por usuarios para quienes SSO sería valioso.

El sesgo de confirmación está en las preguntas mismas. "¿Sería útil si pudiera exportar informes de forma masiva?" obtiene un sí de casi todo el mundo. "¿Cómo gestiona actualmente los informes?" le dice si la exportación masiva es un obstáculo real o algo conveniente enterrado bajo las diez cosas con las que realmente tienen dificultades a diario.

Un ejemplo real, anonimizado: un estudio de 8 administradores de 3 cuentas enterprise produjo el titular "los usuarios quieren SSO." El roadmap cambió hacia un trimestre de trabajo en SSO y SCIM. Seis meses después, la cancelación de SMB aumentó porque el equipo responsable de la activación había sido llevado al proyecto SSO. Los 8 administradores estaban contentos. Las 1.400 cuentas SMB que nunca superaron la semana 2 de activación no fueron entrevistadas. El estudio no estaba equivocado sobre los 8 administradores. Estaba equivocado en ser tratado como un estudio sobre "los usuarios."

La defensa es procedimental. Antes de reclutar, escriba: de qué segmento trata este estudio, qué proporción de los ingresos representa ese segmento y qué decisiones puede informar legítimamente este estudio. Si la respuesta a la tercera pregunta es "solo decisiones sobre este segmento", póngalo en la diapositiva de portada del informe. Los stakeholders generalizarán en exceso a menos que haga explícito el alcance.

Cómo escribir un hallazgo que cambie una decisión

La mayoría de los hallazgos de investigación mueren en la diapositiva donde están escritos. "Los usuarios estaban confundidos por el botón de exportación" pierde cualquier argumento porque no tiene n, ni segmento, ni especificidad, ni recomendación. Puede ser verdad y aun así ser ignorado.

Un hallazgo que sobrevive a un PM escéptico tiene cinco partes:

1. Observación: qué ocurrió, conductualmente
2. Evidencia: n, segmento, tarea, tipo de estudio
3. Inferencia: qué significa probablemente esto
4. Recomendación: qué hacer al respecto
5. Nivel de confianza: cuán seguro está

Comparación:

Malo: Los usuarios estaban confundidos por el botón de exportación.

frente a:

Bueno: 6 de 8 administradores (n=8, nivel enterprise, prueba de usabilidad moderada, tarea de exportación de informe semanal) abandonaron el flujo de exportación en el paso de selección de formato. Tres dijeron en voz alta que no sabían qué significaba "delimitado"; dos hicieron clic en el formato incorrecto sin notarlo. Inferencia: el selector de formato es una barrera de comprensión, no de descubribilidad. Recomendación: establecer CSV como predeterminado con una opción de "más formatos" en modo colapsado, publicar tras una bandera de feature y medir el delta de abandono. Confianza: media. La muestra es pequeña y solo enterprise; un seguimiento no moderado de 2 semanas entre SMB lo confirmaría.

El segundo gana porque le dice al PM exactamente qué se sabe, qué se infiere y qué acción se deriva. El PM escéptico puede atacar cualquiera de las cinco partes, pero tiene que atacar una parte específica. No puede simplemente decir "muestra pequeña" y marcharse, porque la recomendación ya lo contempla con un plan de seguimiento.

Un segundo patrón que ayuda: presente los hallazgos encabezados por la decisión que afectan, no por la metodología. "Necesitamos cambiar el valor predeterminado de exportación" llega. "Ejecutamos un estudio moderado con 8 administradores" adormece a la audiencia antes de que llegue la recomendación.

Cómo presentar la investigación a un PM escéptico

Una presentación de 23 diapositivas de investigación entregada a un PM en el standup no cambiará un roadmap. Será reconocida, archivada e ignorada. Los PM son tomadores de decisiones bajo presión de tiempo. La investigación tiene que encontrarlos donde están.

Cinco cosas que realmente funcionan:

Comience con la decisión. Abra con "este estudio informa si publicamos el nuevo flujo de exportación tal como está, lo publicamos con un cambio o lo reconstruimos." Luego la metodología, luego los hallazgos. El PM ahora lee para tomar una decisión, no para evaluar la investigación.

Anticipe las objeciones. Antes de presentar, escriba las tres objeciones que espera ("muestra pequeña", "esos no son nuestro ICP", "ya decidimos"). Aborde cada una en la presentación antes de que sea planteada. Decir "n=8 es pequeño para afirmaciones entre segmentos, razón por la cual este estudio solo habla de administradores enterprise en la tarea de exportación" neutraliza el ataque de muestra pequeña antes de que aterrice.

Traiga el clip sin procesar, no el resumen. Un video de 45 segundos de un administrador mirando fijamente el desplegable de formato y diciendo "no tengo idea qué significa ninguna de estas opciones" vale quince diapositivas de citas. Los PM confían más en sus propios ojos que en su síntesis. Herramientas como Dovetail y UserTesting hacen que extraer clips sea rápido.

Ancle a una métrica que al PM ya le importe. Si el PM es responsable de la activación, enmarque los hallazgos en torno al impacto en la activación. Si es responsable de la retención, enmarque en torno a la retención. "Esta fricción en la exportación afecta la activación en la semana 2 para nuevos administradores" supera siempre a "esta fricción en la exportación es un problema de UX."

Nombre el costo de ignorarlo. "Si publicamos tal como está, esperamos que aproximadamente el 30 al 40% de los nuevos administradores abandone la tarea de exportación en el primer mes, basándonos en la tasa de abandono de la sesión moderada" le da al PM algo que ponderar frente a la fecha de publicación.

Una regla práctica: si un hallazgo de investigación no cabe en una sola diapositiva con la decisión, la evidencia, la recomendación y una cita, todavía no es un hallazgo. Es una entrada del cuaderno. Siga trabajando en él antes de llevarlo a la sala.

Qué hacer esta semana

Elija una próxima decisión del roadmap. Escriba qué se está decidiendo, quién lo decide y qué tendría que ser verdad para que la decisión cambie. Luego pregunte: ¿tiene el equipo evidencia de lo que tendría que ser verdad? Si no, ahí está el estudio. Si sí, la investigación ya se ha hecho y el siguiente paso es hacerla visible.

La investigación que mueve el roadmap es aquella orientada a una decisión específica, dimensionada para la afirmación que necesita respaldar y presentada en un formato en el que un PM ocupado pueda actuar. Todo lo demás es un taller. Los talleres están bien. Solo no los confunda con estudios.

Más información

• Crítica de diseño que mejora el trabajo, no el ánimo del diseñador
• Trabajar con PM que creen que el diseño es decoración
• Velocidad de publicación para diseñadores
• Plantilla de descripción de puesto: Product Designer