¿Hay una dictadura del dato? ¿Hacemos demasiado caso al dato y muy poco a la intuición y experiencia? ¡No es lo que veo! Prácticamente 4/5 empresas con las que hablo no está midiendo las funcionalidades que lanza. No saben qué impacto tienen.
Os cuento algunas ideas
La clave desde luego es unir el cualitativo con el cuantitativo, y de manera continúa.
Yo suelo 1) usar datos para sacar clientes con los que hablar, 2) hablar con ellos y profundizar en lo que los datos no me pueden decir, 3) volver a los datos para profundizar
Uno de los principales problemas que veo en en España es que MUY pocas empresas miden sus productos. Lanzan una funcionalidad sin eventos, y a por la siguiente feature.
La excusa de siempre es el tiempo. No tengo tiempo. ¡Bullshit! Maduremos.
Has gastado semanas o meses de desarrollo, haciendo múltiples hipótesis, pero no tienes tiempo de invertir unas horas o un par de días en sacar datos para ver si la feature se 1) descubre, 2) activa, 3) retiene.
¿De verdad vas a seguir construyendo encima? ¿Es una base sólida?
Un caso muy bueno es que obtengas el 50% de impacto que esperabas. Si dedicas un poco más, entiendes el uso y feedback de clientes, y podrás plantear pequeñas iteraciones para alcanzar el 80% en seguida.
Esto requiere 1) que tengas datos, y 2) hables con clientes.
Cuando miras los datos, ves de manera muy clara qué está funcionando muy bien y dónde tienes los problemas. Puedes sacar qué tipo de usuarios han 1) descubierto, 2) activado y 3) retenido. Y con ello, hacer iteraciones con muy bajo coste y mucho impacto.
Sin datos, tu roadmap lo dictará lo que digan tus clientes que más os contacten, o lo que ventas crea que más le bloquea para vender, o lo que el CEO haya pensado hoy mientras se duchaba.
Con datos, podréis tener conversaciones para confirmar, descartar y plantear hipótesis.
También puede interesarte

40 clics para pagar dos horas de aparcamiento
Un parquímetro me ha recordado por qué contar los clics y los segundos que le cuesta a tu usuario completar una tarea es clave al diseñar un producto.

5 comportamientos que definen a un Product Engineer
La IA hace que programar sea rápido. El reto que queda es entender el problema, plantear una buena arquitectura y fasear con criterio.
