- Una startup hizo que los ingenieros participaran directamente en llamadas de ventas, lo que terminó cambiando de raíz la forma en que desarrollaban el producto
- Durante esas llamadas descubrieron que los productos de la competencia eran demasiado complejos para usuarios no técnicos y que los clientes, más que logs o métricas, solo querían una marca de verificación (check verde) que confirmara que el monitoreo funcionaba, además de pedir básicamente: "¿no puede alguien hacerlo por nosotros?"
- Gracias a eso, un equipo centrado en backend pudo entender la perspectiva del usuario y empezó a diseñar por su cuenta una nueva arquitectura, sin intervención del PM
- En solo 2 semanas, recortaron 60% de las funcionalidades de la plataforma, añadieron una barra de progreso, una integración con Slack y flujos de trabajo done-for-you; como resultado, los tickets de soporte bajaron 70%
- La lección fue que los usuarios solo quieren resolver su problema, no les importa el código elegante, y que cada funcionalidad genera un costo no en código, sino en confusión para el usuario
Contexto y experimento
- Un ingeniero senior de DevOps se oponía a participar en llamadas de ventas, pero aceptó con la condición de probar al menos 5 llamadas
- El fundador pensó que solo si los ingenieros escuchaban directamente el lenguaje y los problemas de los clientes cambiaría el diseño del producto
Insights obtenidos en las llamadas de ventas
- Decían que los productos de la competencia eran demasiado complejos para usuarios no técnicos
- Los clientes querían una confirmación intuitiva, como una simple marca verde, más que métricas complejas
- Muchos clientes pedían un "servicio gestionado", porque más que usar la herramienta querían tercerizar la resolución del problema
Resultado de la reescritura del producto
- El equipo eliminó 60% de las funciones existentes y se concentró en lo esencial
- Añadieron una simple barra de progreso para mejorar la experiencia de uso
- Simplificaron el flujo de consultas mediante una integración con Slack
- Ofrecieron flujos de trabajo done-for-you para reflejar de forma directa lo que pedían los clientes
- Al final, los tickets de soporte cayeron 70% y mejoraron mucho la usabilidad y la satisfacción con el producto
Lecciones clave
- Los usuarios no quieren una solución técnica elegante; quieren que su problema se resuelva
- Entender al usuario es más importante que la precisión técnica
- Cada funcionalidad tiene un costo, no de código sino de confusión para el usuario
Cambio en la cultura del equipo
- Después de esto, la empresa volvió obligatorio que todos los ingenieros participen en 5 llamadas de ventas por trimestre
- Se consolidó una cultura en la que los ingenieros escuchan de primera mano el cansancio de los clientes y esa idea de que "solo tiene que funcionar bien", desarrollando así un mejor instinto de producto
Resumen de los principales comentarios en Reddit
- Debate sobre el rol del PM
- Algunos señalaron que el problema era la falta de un buen Product Manager y que hacer que los ingenieros también atendieran llamadas con clientes era ineficiente
- Otros respondieron que el PM a veces no pasa de ser un traductor y que los mejores resultados aparecen cuando los ingenieros se hacen cargo directamente de los problemas del cliente
- El valor del contacto con el cliente
- Varios comentarios enfatizaron que la experiencia de que los ingenieros escuchen directamente la voz del usuario genera insights muy poderosos
- También hubo quienes dijeron que, en startups en etapa temprana o equipos pequeños, es común que los ingenieros también cumplan parcialmente el rol de PM
- Mirada crítica
- Hubo críticas del tipo: "esto solo le trasladó a los ingenieros un fracaso de liderazgo/cultura"
- También apareció el argumento de si realmente recortar funciones y simplificar equivale a mejorar, advirtiendo que a largo plazo puede ignorar a los power users y sus necesidades avanzadas
- Casos positivos compartidos
- Hubo muchas experiencias de otras industrias, como banca y dispositivos médicos, donde también existían programas para que todos los empleados pasaran por soporte al cliente o ventas
- Varias personas coincidieron en que el dogfooding o la experiencia de estar cara a cara con el cliente ayuda tanto a la calidad del producto como a la cultura del equipo
- Conclusión general
- Hacer que el equipo viva de forma directa los problemas del cliente es una herramienta de aprendizaje muy potente,
- pero al mismo tiempo, a largo plazo, debería combinarse con capacidades profesionales de PM, UX y diseño para construir una estrategia de producto equilibrada
Aún no hay comentarios.