El otro día tuve una llamada con un desarrollador que estaba creando un nuevo producto B2B. Quería mi consejo. Mi respuesta fue sencilla: deja de programar y habla con 20 potenciales clientes. Él mismo sabía que le iba a decidir eso, pero para él lo fácil es programar.
Hace unos meses una PM me dijo que ejecutaban pero no solucionaban los problemas. Mi respuesta fue que fuera a visitar la operación y viera in situ lo que funcionaba o no de su producto. Según ella misma, en dos días aprendió más que en seis meses.
Hace unas semanas un Head of Product Engineering me contó que no estaba funcionando un nuevo producto que usaba un equipo de Sales en otra ciudad. Se cogió un vuelo y se fue para allá. Descubrió y solucionó in situ todos los problemas que tenían. Le despidieron como a un héroe.
El otro día os conté el proceso de pivot de Meetzy https://lnkd.in/dhPDMZyb
Mi consejo fue claro:"1) Habla con 20 clientes al menos para entender sus pains"2) Asegúrate que eliges un pain nivel 4/5
Su anterior pain era 2/5, este es 4 o 5/5.
Y si el consejo es tan obvio, y tan repetitivo, ¿por qué lo hacemos tan poco desde producto e ingeniería?
Dejad las excusas. Hablad con vuestros actuales y potenciales clientes.
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.
