Obligaron a todos los ingenieros a tomar llamadas de ventas y en 2 semanas reescribieron por completo la plataforma

• 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

[meteorizer]

Al final, probablemente sea un tema de eficiencia.
Hay muchas ventajas en coordinarse directamente con el cliente, pero la continuidad del trabajo se rompe con frecuencia por la comunicación constante, como reuniones y llamadas, y eso reduce el tiempo que se puede invertir en desarrollo.
Si es así, la empresa tendría que planear contrataciones para responder a esa baja en la productividad.
El problema es que, por lo general, ni siquiera piensan hacerlo.
Al final, por falta de tiempo, es muy probable que con el paso del tiempo terminen enfrentando una caída en la calidad.
Creo que hay que considerar bien los pros y los contras.

[laeyoung]

No estoy seguro de por qué en Hacker News lo dejaron con un enlace a old reddit, pero la ruta de la interfaz actual de Reddit está aquí.

[xguru]

Parece que en Hacker News, cuando publican URLs de Reddit, la mayoría las sube usando old reddit. Supongo que es porque también es más ligero.

[cnaa97]

Si la meta de una organización es elevar el piso, reconozco que una organización por roles, como un equipo compuesto solo por desarrolladores web frontend o un equipo de desarrolladores de apps, tiene sentido.

Sin embargo, en equipos u organizaciones que apuntan al techo más alto, estructurarse por roles inevitablemente tiene límites.
Tal como dice el texto, surge la duda de si realmente es necesario que planificadores, diseñadores, PM e ingenieros se repartan cada uno su trabajo y operen como la cinta transportadora de una fábrica. En lugar del típico trabajo de "encargado", donde cada quien se ocupa solo de unas pocas tareas asignadas, lo ideal es que personas con especialidades en cada área se reúnan, definan juntas un objetivo común y que todos los integrantes se apoyen mutuamente.

En muchas empresas se organizan estructuras tipo task force, como escisiones o formación de equipos, pero como también agrupan solo a las personas (roles), se produce un refuerzo negativo de tipo "estoy tratando de hacer algo, pero la empresa no me ayuda, mejor me rindo", y al final se corre el riesgo de perder solo a talentos clave, como los miembros más importantes. Por eso, incluso una organización orientada por objetivos necesita necesariamente el apoyo activo de una organización por roles.

[GN⁺]

Opinión de Hacker News

• Al final, idearon una arquitectura completamente nueva sin mi “PMing”. La razón fue que por fin entendieron de verdad quién usa nuestro producto en la práctica. Viéndolo en conjunto, la conclusión es: “Le pusimos a los ingenieros las llamadas de ventas y al final el problema era que los PM no estaban logrando comunicar bien entre clientes e ingeniería, mientras que el ingeniero de DevOps fue quien mejor convirtió las necesidades del cliente en una solución funcional con rapidez”
  • A veces los ingenieros están tan seguros de sí mismos que creen que el usuario está usando mal el producto. La lógica es que esto pasa “porque el usuario se comporta como tonto”, no porque haya un problema con el diseño complejo que yo hice. Tan solo la gente del mundo de Desktop Linux podría escribir un libro entero sobre experiencias ignorando quejas de usuarios. Si un ingeniero terco cree que él sabe más que el PM y que los usuarios, nada avanza. Pero si a ese ingeniero lo lanzas a tratar directamente con usuarios, en vez del PM amable de siempre aparecen usuarios reales y molestos que destrozan “esta maravillosa creación” como si fuera un hámster problemático. Ese proceso da miedo, pero también golpea fuerte el ego del ingeniero. Desde mi perspectiva, esto no se trata de demostrar que el PM es tonto, sino de volver humilde al ingeniero. Con el tiempo la arrogancia del ingeniero regresa, así que este proceso hay que repetirlo periódicamente
  • Soy la única persona en un equipo de ingeniería mecánica de una gran empresa que sabe programar. El equipo interno de IT desarrolla varios programas, pero a la mayoría de mi equipo le parecen malos. Así que diseño herramientas para rehacerlos o para complementar esos programas “malos” que no se pueden reemplazar, y así facilitar el trabajo. No creo que yo desarrolle mejor que el equipo interno de IT, sino que por la perspectiva de usuario real entiendo mejor qué necesitamos de verdad mi equipo y yo. Y como además soy quien usa ese software, naturalmente también tengo más motivación. Por eso el título del post me resonó. Aunque también creo que lo que describe el texto perfectamente puede pasar en el trabajo real. No estoy familiarizado con procesos formales de desarrollo de software o gestión de proyectos
  • Dirijo una pequeña startup tecnológica que factura 2 millones de dólares al año. A veces, cuando falta personal de soporte, yo mismo me hago cargo de atención al cliente durante algunos días. Cada vez me sorprende descubrir un montón de quejas de clientes que nunca llegan al equipo de ingeniería. El personal de soporte tiende a enfocarse en “resolver” el problema por su cuenta, así que las mejoras de fondo no terminan escalando hacia ingeniería
  • Llama la atención que nadie se pregunte por qué el software estaba tan mal desde el principio. No creo que se le pueda echar toda la culpa a un solo PM. En realidad, es un problema sistémico de organizaciones Agile/Scrum y similares, donde la responsabilidad se difumina y los desarrolladores se la pasan resolviendo tickets mal armados en ciclos demasiado rápidos, y así terminan saliendo productos mediocres. Es un resultado muy común cuando una organización de software “moderna” se vuelve obesa
  • Mi primer pensamiento al leer esto fue: “Así era como se construía software antes de que los PM se metieran en todo”. Cuando sientas a un ingeniero al lado de la persona que realmente opera el sistema, muchas veces el PM deja de ser necesario y todo el mundo termina mucho más feliz. Claro, hay PM extraordinarios, pero en mi experiencia los PM tienden a obsesionarse con defender su territorio y, sorprendentemente, muchas veces saben poco tanto de ingeniería como del cliente
• He vivido varias veces situaciones donde los ingenieros están desalineados con el producto. Un colega agrega algo sin avisar y de pronto la UI se vuelve confusa, o el contenido del sitio web ya no coincide con el producto real. Además, por ciclos largos como [producto -> PM -> sistema de seguimiento de bugs -> ingeniero -> arreglo -> QA -> producto], se corrigen las cosas importantes, pero las pequeñas molestias tardan muchísimo en arreglarse. Si dejas solo [producto <-> ingeniero], la productividad puede mejorar de forma sorprendente. Muchos ingenieros ni siquiera han vivido directamente la experiencia completa del producto, y a veces ni saben bien qué cambió entre este año y el anterior
  • Yo también tuve una experiencia parecida y, curiosamente, esto pasaba más seguido en lugares con muchos PM. La peor experiencia que tuve fue en una empresa que intentó imponer una proporción fija de PM y “Product Designers” según la cantidad de ingenieros. Si sumabas diseñadores, producto, proyecto y programa, terminabas con más gente que ingenieros. El resultado fue todavía peor. También era desgastante andar esquivando la burocracia de los PM y su miedo a que uno invadiera su función. Los PM excelentes son valiosísimos, pero siento que hoy el título de Product Management ha atraído a demasiada gente burocrática y obsesionada con el proceso. Los influencers de Product Management también están empeorando el problema
  • Aun así, tampoco creo que obligar a ingenieros a entrar a llamadas de ventas sea la respuesta correcta. Para llevar bien una llamada se necesitan muchas habilidades blandas, y los ingenieros no están entrenados para eso, ni es algo que normalmente se evalúe al contratarlos. (Con “llamada de ventas” me refiero a una llamada inicial de consulta antes de un demo o un PoC. En demos de preventa complejos, aunque vaya un ingeniero, en principio ese rol debería recaer en producto)
  • Hay muchísimas formas en que esto puede salir mal, y yo he visto todos esos casos en persona. Por ejemplo, cuando un PM o PO monopoliza toda la comunicación con el cliente, o cuando el cliente evita hablar con los desarrolladores y solo transmite interpretaciones del user manager, o cuando el desarrollador quiere dedicarse únicamente a escribir código, o cuando se obliga a que toda comunicación pase solo por PM y el bug tracker. También, cuando usas una plataforma de software comercial, las limitaciones técnicas pueden volver muy malos los flujos de trabajo. Siempre hay algo que bloquea la comunicación, y puede ser el cliente, el mando medio o el desarrollador. Incluso pasa mucho que ya se decidió desde el principio una solución equivocada y se empieza a trabajar sin que desarrolladores o usuarios conozcan los detalles. Hay muchísimos caminos para no llegar a construir un sistema realmente bueno para el usuario
  • Creo que es muy importante que los ingenieros entiendan profundamente el producto en sí. El encaje del lado producto es más difícil que la ingeniería básica. La mayoría de los productos que he visto fracasar terminaron fallando por razones de producto, así que tiene más sentido enfocar la fortaleza del equipo en eso
• Por otro lado, también pasa que los ingenieros terminan degradados al rol de soporte técnico. Si das soporte directo a cada cliente, terminas acumulando hotfixes y soluciones a medida para cada cuenta, nada de eso se prueba bien y solo crece la deuda técnica; luego llega un competidor grande, bien financiado, con un producto mejor armado, y te deja atrás rápidamente. Me parece un fallo clásico de gestión de producto. Significa que el PM no supo transmitir bien las necesidades del cliente al equipo de ingeniería, o tampoco supo hacer presión en sentido contrario. Poner ingenieros en llamadas de ventas no escala cuando la base de clientes ya creció y maduró. Si un product manager realmente quiere que un ingeniero haga llamadas de ventas, entonces por justicia ese ingeniero también debería recibir parte de la comisión de esas cuentas. Yo jamás haría llamadas de ventas sin comisión
• En entornos como startups, donde todos necesitan una empatía profunda con las necesidades del cliente, es una estrategia excelente. Cuando participé en definir realmente los requisitos del producto y entendía a fondo el trabajo operativo, la tasa de éxito de los proyectos fue mucho mayor. El resultado fue mucho mejor que cuando solo “me pasaban” requisitos para implementarlos tal cual
  • ¿Quieres decir que era más fácil seguir lo que tú mismo habías escrito como guía, o que por participar directamente salió una mejor UX?
• “Reescritura terminada en 2 semanas, 60% menos funcionalidades, una barra de progreso simple, integración con Slack, flujo de trabajo ‘done-for-you’ -> 70% menos tickets de soporte”. Si eso es real, entonces algo estaba gravemente mal
  • Reddit es famoso por la avalancha de historias inventadas, y este relato, esté inspirado en algo real o sea completamente ficticio, está lleno de elementos típicos de escritura estilo Reddit con un aire de storytelling de negocios estilo LinkedIn
  • Yo diría que esto es un caso de B2B SaaS que pasó por varios pivotes y quedó con guías de producto muy pobres. Y sí, este tipo de desorden es mucho más común de lo que uno pensaría
  • Por el tono de frases cortas estilo LinkedIn seguidas por cierres dramáticos repetidos, se nota fácilmente que esto es ficción
  • Es Reddit, así que obviamente es inventado. No entiendo cómo algo así termina volviéndose tema de conversación
• Si el resultado fue este, entonces habría que despedir de inmediato a PM, PO y al equipo de marketing. Hay dos cosas claras: primero, esa gente no entendía qué querían realmente los clientes, o no supo transmitirle bien esas necesidades al equipo de desarrollo, o ambas. Segundo, tienen la cabeza tan metida en el sistema que quizá sería mejor eliminar por completo todos los pasos intermedios entre clientes y desarrollo
• En un trabajo anterior, los ingenieros sí entraban regularmente a llamadas comerciales. Era interesante experimentar qué querían ciertos clientes y cómo se vendía nuestro producto, pero no fue algo revolucionario. Las funcionalidades que querían ya estaban en el roadmap, y también había una función confusa, pero estaba diseñada así por requisitos especiales del cliente más grande. El equipo de desarrollo quería simplificarla, pero hacerlo implicaba no cumplir con lo que pedía esa gran cuenta. Al final hicieron una versión “light” más fácil de usar para que la usaran todos menos ese gran cliente. Pero ese cambio no ocurrió por acompañar llamadas de ventas; todos sabían desde el principio que era difícil, solo que no se podía cambiar hasta que entrara al roadmap
• Me identifiqué mucho con la parte de “por fin entendieron bien quiénes eran los usuarios reales”. Se suele decir que “el mayor problema de la mayoría de los ingenieros es el overengineering”, pero en realidad muchas veces el overengineering ocurre porque no entienden bien los casos de uso del cliente. Ese es el problema más de fondo. Incluso como ingeniero, una de las frustraciones que más vivo es que otros ingenieros ni siquiera intentan entender cuál es el producto que realmente se vende. Sea por adecuación al rol, por orgullo o por la razón que sea, casi siempre es un problema de cultura organizacional o de estructura de incentivos
• Hace tiempo trabajé en una empresa que hacía soluciones de robocalls para CRM, y en un offsite decidieron que todo el mundo debía hacer cold calls personalmente y seguir el guion. No tenían ni entendimiento ni interés en la ansiedad que eso provocaba en la gente que no era de ventas. Después de eso empecé a pensar en cambiarme de trabajo
• Una vez vi algo parecido. El equipo de monitoreo insistía en que “todas las alertas debían ser registradas como tickets directamente por los ingenieros de primera línea”. El problema era que había más de 10 mil alertas por hora. Los problemas importantes quedaban enterrados en todo ese ‘ruido’, la gerencia ya estaba agotada, y en un momento se forzó un “a ver, equipo de monitoreo, abran ustedes mismos todos los tickets y resuélvanlos”. Al día siguiente, al excluir las alarmas de baja prioridad, las alertas únicas bajaron a apenas unas decenas por hora, y el resto se fue cerrando en orden. Solo entonces “todo el tablero en verde” se volvió algo real (antes solo pintaban todo de verde a la fuerza para enseñárselo a los medios y a Gartner Group)