Preguntar a tus clientes lo que quieren no funciona
Los constructores de productos sostienen que implementar directamente las solicitudes de funciones de los clientes suele salir mal, porque los usuarios normalmente describen sus propias soluciones imaginadas en lugar de los problemas subyacentes que necesitan resolver. En cambio, los comentaristas abogan por enfoques como “jobs to be done”, observar el comportamiento real, indagar en los dolores de raíz y validar la disposición a pagar, advirtiendo al mismo tiempo contra sobreponderar a las minorías ruidosas, la política interna o las demandas puntuales impulsadas por ventas. La tensión central está entre respetar la opinión del usuario y ejercer una fuerte visión de producto para crear soluciones que los clientes realmente adopten y paguen.
Límites de “Preguntar a los clientes qué quieren”
- Muchos sostienen que los clientes a menudo describen soluciones cercanas a lo que ya tienen, no lo que realmente les ayudaría.
- Las peticiones suelen ser contradictorias o mutuamente excluyentes; la gente solo se da cuenta de los sacrificios cuando se la presiona.
- Las minorías ruidosas pueden distorsionar la demanda percibida (p. ej., teléfonos pequeños, vestidos con bolsillos).
- Algunos ven la idea del título como un cliché sobreutilizado para ignorar necesidades legítimas de los usuarios.
Centrarse en problemas / jobs to be done
- Hay un fuerte apoyo a preguntar: “¿Qué problema estás resolviendo?” o “¿Qué trabajo estás contratando para que haga este producto?”
- Las historias del batido y del trayecto al trabajo: mejorar el “producto” solo tenía sentido una vez que se entendió el trabajo real (desayuno fácil mientras se conduce, trayecto más corto).
- Se aplica una lente similar a AirPods, Segway frente a scooters, coches frente a “caballos más rápidos”.
Observación frente a preguntas directas
- Observar cómo trabajan los usuarios (grabaciones de pantalla, acompañamiento, reuniones de soporte) se considera más revelador que los deseos autorreportados.
- Problema XY: los usuarios describen su propia solución propuesta; hay que profundizar para descubrir el dolor subyacente.
- Sin embargo, algunos se quejan de que las respuestas demasiado vehementes de “en realidad no quieres X” pueden ser irritantes cuando X está realmente bien pensado.
Visión de producto frente a feedback
- Se distingue entre:
- Creación de producto visionaria (intuición, investigación previa, oportunidad temporal).
- Refinamiento iterativo (pruebas de usabilidad, corrección de errores, flujos confusos).
- Ejemplos como los teléfonos con pantalla táctil muestran que ir contra las preferencias declaradas puede tener éxito si la experiencia global es mejor, aunque los errores (sin apps/3G/copiar y pegar) muestran que la visión es falible.
Validación, MVPs y experimentos
- Algunos insisten en “no construir antes de validar”; otros dicen que su mejor trabajo surgió de construir primero para su propio problema conocido.
- La validación puede significar: la presencia de un problema doloroso, soluciones improvisadas por los usuarios, compromisos de pago o experimentos rápidos y de bajo costo (flujos manuales, conmutadores rápidos) antes de una implementación completa.
Complicaciones empresariales/B2B
- Comprador ≠ usuario: las funciones pueden existir solo para satisfacer compras, cumplimiento o listas de verificación (p. ej., SAML/SSO), aunque rara vez se usen.
- Las demandas de funciones impulsadas por ventas (“no puedo cerrar sin X”) son comunes; a veces están justificadas, a menudo son erróneas y son costosas para el mantenimiento a largo plazo.
Conclusiones generales
- Escucha ampliamente, pero toma poco al pie de la letra; sintetiza en lugar de implementar de forma literal.
- Pregunta qué quieren los usuarios hacer, qué no quieren y por qué pagarían realmente.
- Ser un usuario real de tu propio producto se cita repetidamente como una brújula poderosa.