Por qué tu producto empeora cada día
¿Te has fijado que tu producto empeora día a día? No eres el único. Sale demasiado barato empeorar algo que funciona. Analizamos por qué sucede y cómo podemos prevenirlo.
En 1993 se filtró un correo interno de un ingeniero de Silicon Graphics (SGI), una de las tecnológicas más punteras de la época. El correo era una amarga queja sobre los problemas de rendimiento de su última release y un posible análisis de sus causas.
Resulta curioso que, habiendo pasado cerca de 30 años, las dos primeras líneas se podrían haber escrito ayer sobre cualquiera de los productos que desarrollamos hoy en día:
Release 5.1 is a disappointment. Performance for common operations has dropped 40% from 4.0.5, we shipped with 500 priority 1 and 2 bugs, and a base Indy is much more sluggish than a Macintosh. Disk space requirements have increased dramatically.
The primary cause is that we attempted far too much in too little time. Management would not cut features early, so we were forced to make massive cuts in the final weeks of the release.
Cualquiera diría que 30 años es tiempo más que suficiente para haber aprendido a hacer las cosas mejor, pero la realidad es que no es así y aún menos fuera de EEUU dónde probablemente vayamos con 10 años de retraso en aspectos relacionados con desarrollo de producto.
En el correo se dan varias razones que llevaron a SGI a realizar una entrega tan desastrosa:
Tratar de abarcar más de lo que podían conseguir
SGI sobreestimó lo que podían conseguir en el plazo de tiempo dado para sacar la release. La capa directiva se negó a recortar funcionalidades y, obviando la Ley de Brook, aplicó la receta mágica cuando un desarrollo se retrasa, contratar a externos para acelerar las cosas.
Sólo cuando la situación fue ya insostenible, management decidió empezar a recortar el alcance de la entrega, pero para entonces ya era demasiado tarde y terminó afectando a la calidad de la misma.
Delirios de la capa directiva
Otro de los problemas aducidos en el email son los “delirios” en la capa directiva. Ésta tiende a favorecer las posturas optimistas y, si alguien vende que puede hacer un proyecto en cuatro meses en lugar de seis, se lo termina llevando.
Este sesgo hacia al optimismo se extiende recorriendo toda la cadena de mando, quienes terminan tomando decisiones basadas en estimaciones irreales. El problema viene cuando esas decisiones llegan a la capa que debe ejecutarlas, quienes de salida ya saben que son irrealizables, afectando a su motivación y desempeño.
Desconexión entre marketing e ingeniería
Es probable que en SGI en los 90 la función de marketing fuera la que definiera y dictase el roadmap de producto.
El ingeniero se queja entre la desconexión entre lo que es posible y lo que demanda Marketing. Por ejemplo, podemos querer añadir la funcionalidad más ambiciosa posible, pero si el producto no está preparado técnicamente para soportarlo, cualquier esfuerzo que hagamos en esa dirección será baldío.
Hasta aquí llegan las razones aducidas en el email, pero han pasado 30 años, así que añadiré algunas más sobre por qué creo que nuestros productos tienden a empeorar con el tiempo.
Tragedia de los Comunes
En economía se describe un fenómeno denominado Tragedia de los Comunes, según el cual agentes individuales con acceso a un recurso del bien común tenderán a maximizar su beneficio pese a que ello pueda destruirlo.
Un ejemplo típico es el de los caladeros de peces. Un conjunto de barcos pesqueros actuando de forma independiente en su propio beneficio, pueden esquilmar rápidamente un caladero y extinguirlo pese a que ello pueda afectar a su supervivencia a largo plazo.
Tengo la opinión de que en el desarrollo de producto nos puede ocurrir algo parecido. Cualquier empresa suele tener un producto de éxito a modo de bien común, sobre el que equipos de producto de forma autónoma trabajan para conseguir sus objetivos particulares.
La teoría económica nos dice que esta autonomía mal entendida, como en el caso de los barcos pesqueros, pondrá en riesgo el bien común si no nos encargamos de protegerlo adecuadamente.
Ausencia de métricas de calidad
En el libro Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs, el ex-ingeniero de Apple Ken Kocienda, describe el proceso de desarrollo de su navegador de Internet, Safari.
Kocienda destaca como el equipo de producto al cargo definió cómo su métrica más importante la velocidad de carga de una página web. Tras añadir cualquier funcionalidad, tenían que correr un test que validasen que la velocidad de carga no había empeorado.
Mi experiencia me dice que las métricas de calidad y servicio son más la excepción que la norma. De esa forma, nuestras aplicaciones cada vez cogen más y más grasa, y lo que antes era un producto sencillo para nuestro cliente, termina convirtiéndose en una telaraña de features entrelazadas que terminan poniéndose en el camino de lo que vino a hacer en primer lugar.
¿Qué podemos hacer para evitar que nuestros productos empeoren día a día?
Fomenta el pensamiento crítico
Especialmente en la capa directiva, pero también en nuestro día como Product Managers, es importante que a la hora de enfrentarnos a una nueva iniciativa analicemos la situación críticamente y no nos dejemos llevar por el sesgo del optimismo.
Para pensar críticamente necesitamos confrontar posturas activamente. Esto es especialmente importante en esfuerzos de gran alcance. No quieres embarcarte en ningún proyecto que pueda abarcar más de un par de meses sin haber confrontado realmente que ese proyecto pueda dar resultados en ese tiempo.
Busca experiencias similares en el pasado. Si tu último proyecto del mismo estilo se retrasó, lo más probable es que vuelva a ocurrir lo mismo. Busca a aquellos que hayan pasado experiencias similares en tu empresa u en otras y pregúntales su opinión al respecto.
Estresa la iniciativa antes de enfrentarte a ella como forma de reducir el riesgo.
El CPO como garante del bien común
Desde mi punto de vista, en toda empresa de producto debe haber una figura que se encargue de velar por el bien común. Apple tenía a Steve Jobs. Linux tiene a Linus Torvalds. Tesla y SpaceX a Elon Musk.
Son figuras controvertidas, a veces comparadas a dictadores benevolentes, que deciden sobre el futuro de iniciativas y el destino de sus compañías, pero desde mi punto de vista, a veces son necesarias.
Como hemos observado al hablar de la Tragedia de los Comunes, equipos autónomos de producto pueden tender a optimizar localmente sus decisiones de forma que sean buenas para ellos pero malas para el conjunto. Personalmente me parece vital que haya una figura en cada empresa que tenga la visión de conjunto de lo que se está haciendo y frene todo aquello que pueda perjudicar al bien común.
El mejor capacitado para hacerlo suele ser el CPO, pero para eso tiene que ser un CPO fuerte capaz de tomar decisiones y alinear a su equipo en torno al bien común. Os sorprendería la cantidad de líderes de producto que piensan que su trabajo es simplemente gestionar voluntades.
Define métricas para medir la calidad del servicio
No midas sólo revenue. Define aquellas métricas en tu aplicación que sean claves para la satisfacción del cliente y añade tests a tu herramienta de integración continua que valide que ningún equipo las empeora.
Si desarrollas una aplicación Desktop por ejemplo, aspectos como el tiempo de carga de la misma son críticos. Si no defines una métrica que lo controle, este aumentará linealmente conforme tus equipos de producto añadan más y más funcionalidades. Un día la espera será tan exasperante, que comenzará a afectar a tu conversión y ya no podrás dar marcha atrás.
El tiempo que tarda un usuario en completar la acción por la que acudió en primer lugar también puede ser importante. Cuánta más complejidad añadimos a un producto, más probable es que terminemos complicando la vida de nuestros usuarios. Cuántos más casos de uso queramos cubrir, más complejo será el onboarding por ejemplo.
Generalmente, el producto ideal hace una única cosa y lo hace extremadamente bien. Si quieres añadir más capacidades, asegúrate muy bien de que tu propuesta de valor principal no se vea perjudicada.
Conclusión
Lamentablemente, sale demasiado barato empeorar un producto que funciona. Las ambiciones de la capa directiva, la ausencia de figuras fuertes de Producto que puedan defenderlo por encima de gestionar voluntades, y también de métricas que nos permitan medir la calidad del servicio pueden propiciar que nuestros productos empeoren con el tiempo.
Es por ello importante que la capa directiva aplique y fomente el pensamiento crítico. Que el CPO asuma el rol que le corresponde tomando decisiones que protejan el bien común. Y que nos apoyemos en métricas que nos permitan medir la calidad del producto.
Silicon Graphics quebró en 2009 por cierto. ¿Quieres seguir sus pasos?
📖 Contenidos recomendados de la semana
Robert Cialdini - The Principles of Persuassion — The Knowledge Project 🔊
Kwan’s Hierarchy of Product Needs: The Four Levels of Product Managers
Why it’s difficult to build teams in high growth organisations
"It depends" / The development Mix (Product, Engineering, Hygiene) — @eferro
Metaverse! Metaverse? Metaverse!! — Benedict Evans
The Brazen Strategy Behind China Tech’s Growth - Future a16z
🙌 ¡Comparte!
Cómo siempre, muchas gracias por estar ahí. Si te ha gustado el post y crees que le podría interesar a alguien de tu entorno sé libre de reenviarle este correo. También puedes utilizar estos enlaces para compartirlo directamente en Twitter o LinkedIn y así contribuirás a que esta lista llegue a más gente.
Muchísimas gracias de antemano, Simón.