El research de usuarios antes del MVP es el paso que casi todo el mundo se salta y casi todo el mundo lamenta. La prisa por construir es real: tienes una idea, la ves clara, y hablar con gente parece un rodeo cuando lo que quieres es empezar. Pero cinco conversaciones antes de escribir una línea de código te ahorran meses y decenas de miles de euros construyendo algo que nadie pidió. En Bluka lo aplicamos antes de cada proyecto, y esta guía te explica cómo hacerlo tú, con cinco usuarios, sin herramientas caras y sin ser experto en investigación.
Research de usuarios antes del MVP: por qué bastan cinco
El research de usuarios antes del MVP con solo cinco personas funciona porque, según la investigación clásica de usabilidad de Jakob Nielsen, cinco usuarios detectan alrededor del 85 por ciento de los problemas de un producto. A partir del sexto, empiezas a oír las mismas cosas repetidas. Cinco no es un atajo pobre, es el número donde el aprendizaje por persona todavía es alto y el coste todavía es bajo.
La lógica es sencilla. Los problemas graves de una idea (que la gente no tiene ese problema, que ya lo resuelve de otra forma, que no pagaría por tu solución) aparecen en las primeras conversaciones porque son problemas compartidos, no rarezas individuales. No necesitas significancia estadística para descubrir que tu premisa es falsa. Necesitas escuchar a cinco personas de tu público objetivo con atención y honestidad. Ese es todo el aparato.
Con quién hablar (y con quién no)
El error número uno del research es hablar con la gente equivocada. Tus amigos, tu familia y tu socio no valen, porque te quieren y te dirán que la idea es genial. Necesitas cinco personas que encajen con tu usuario real: si haces una app para dueños de restaurantes, hablas con dueños de restaurantes, no con gente a la que “le gusta comer fuera”.
Encontrarlos es más fácil de lo que parece. Grupos de LinkedIn, comunidades del sector, un mensaje directo bien escrito, o incluso presentarte en persona donde estén tus usuarios. Ofrece algo por su tiempo si hace falta: media hora de tu producto gratis más adelante, una tarjeta regalo pequeña, o simplemente el argumento honesto de que estás construyendo algo para gente como ellos y su opinión de verdad cambia lo que haces. Cinco conversaciones de media hora son perfectamente alcanzables en una semana.
Qué preguntar: el problema, no tu solución
Aquí está la parte que casi todo el mundo hace mal. La tentación es enseñar tu idea y preguntar “¿te gusta?”. No lo hagas. La gente es amable y te dirá que sí para no ofenderte, y esa amabilidad te llevará directo a construir la app equivocada. El objetivo del research no es validar tu solución, es entender el problema.
Pregunta por el pasado, no por hipótesis. En lugar de “¿usarías una app que hace X?”, pregunta “cuéntame la última vez que tuviste este problema, ¿qué hiciste?”. Las respuestas sobre el comportamiento pasado son datos; las respuestas sobre el comportamiento futuro son buenos deseos. Escucha cómo resuelven hoy el problema, cuánto les molesta, cuánto tiempo o dinero les cuesta, y si han intentado pagar por algo que lo arregle. Si nadie ha buscado nunca una solución, quizá el problema no duele lo suficiente para construir un negocio encima.
Estas cinco preguntas sirven de esqueleto para casi cualquier conversación:
- Cuéntame la última vez que te enfrentaste a este problema.
- ¿Qué hiciste para resolverlo? ¿Qué usas hoy?
- ¿Qué es lo más frustrante de cómo lo resuelves ahora?
- ¿Has intentado alguna vez pagar por algo mejor? ¿Qué pasó?
- Si esto no se arreglara nunca, ¿qué te supondría?
Cómo escuchar sin contaminar la respuesta
Escuchar bien es una habilidad, y la más importante es callarte. Después de una pregunta, resiste el impulso de llenar el silencio. Los tres segundos incómodos de pausa son cuando la persona te da la respuesta de verdad, no la educada. No termines sus frases, no sugieras respuestas, no defiendas tu idea cuando digan algo que no te gusta.
Toma notas literales de las palabras que usan, no de tu interpretación. Si un usuario dice “pierdo la mañana entera cuadrando las comandas a mano”, eso vale mucho más que tu resumen de “el usuario tiene ineficiencias operativas”. Las palabras exactas de tu cliente son oro para el producto y para el marketing después. Y presta especial atención a las emociones: la frustración, el hartazgo o el alivio son señales de dónde hay un problema real por el que alguien pagaría.
Qué haces con lo que aprendes
Tras cinco conversaciones, siéntate y busca patrones. Lo que oíste tres o más veces es una señal fuerte; lo que oíste una vez puede ser una peculiaridad. Ordena lo aprendido en tres cubos: qué se confirma de tu idea, qué te sorprendió, y qué se derrumbó. Ese tercer cubo es el más valioso, porque es lo que te habría costado dinero descubrir construyendo.
A veces el research mata la idea, y eso es una victoria, no un fracaso: acabas de ahorrarte un año y un presupuesto. Más a menudo, la idea sobrevive pero cambia de forma, y descubres que el problema que de verdad duele no es el que pensabas. Ese ajuste, hecho antes de construir, es la diferencia entre un MVP que la gente usa y uno que ignora. Escribimos sobre esta trampa exacta en notas de campo: un Figma precioso sin usuarios, que es lo que pasa cuando saltas este paso.
El research no reemplaza construir, lo dirige
Que quede claro: cinco conversaciones no te dicen exactamente qué construir, te dicen qué no construir y por dónde empezar. Después sigue haciendo falta un MVP real, lanzado a usuarios reales, para aprender lo que ninguna entrevista revela. El research antes del MVP no sustituye a construir, hace que lo que construyas apunte al problema correcto desde el primer día. Sobre por qué ese primer MVP debe ser pequeño y honesto, tienes el mito de los 25.000 euros del MVP.
Si tienes una idea y no sabes si el problema es real o solo te lo parece a ti, esa es la conversación con la que empezamos cada proyecto. Cuéntanos tu proyecto y te ayudamos a diseñar estas primeras cinco conversaciones antes de gastar un euro en desarrollo. Casi siempre es la media hora mejor invertida de todo el proyecto.
.webp)
.webp)
