El rendimiento es una feature

Sobre por qué el rendimiento es un factor clave en la adopción de software y qué podemos hacer para diferenciarnos a través del mismo.

Soy un usuario habitual de modelos del lenguage (LLMs). En mi día a día, alterno principalmente entre ChatGPT, Claude o Gemini según la necesidad.

Desde que Claude publicó su versión Opus, este modelo se había convertido en mi primera opción. Sus resultados para mis casos de uso eran simplemente mejores.

Sin embargo, últimamente mis primeras consultas se las está llevando ChatGPT-4o, un modelo, a mi parecer, inferior a OPUS pero que responde mucho más rápido.

La velocidad de respuesta ha hecho que cambie mis preferencias. Estoy seguro de que no soy el único.

La relación entre el rendimiento y la facturación

La relación entre latencia, el tiempo de espera entre una acción y su respuesta, y las ventas está más que analizada.

En un estudio de Deloitte de 2020, Milliseconds make millions, observaron que una mejora de tan sólo 0.1 segundos en el tiempo de carga de un sitio web móvil:

• Conseguía avanzar a más usuarios a lo largo de un embudo de conversión.

• Mejoraba el número de páginas vistas, la tasa de conversión y hasta el importe medio del ticket.

En otro estudio reciente, The State of Mobile Experience 2023, publicado por Embrace.io, una plataforma de observabilidad, destacan:

• La velocidad es crítica: un 20% de los usuarios no esperan más de cinco segundos para hacer login, completar una compra o reproducir un contenido multimedia.

• El 48% de usuarios reconoce sufrir un problema diariamente, tales como, lentitud en la apertura, cuelgues, crashes o botones que no responden. 

• El 60% de usuarios desinstala la aplicación si crashea unas pocas veces.

Según un ingeniero de Amazon en referencia a tests internos de la compañía, cada 100ms adicionales de tiempo de espera les costaba el 1% de la facturación. Marissa Mayer, VP de Google, también contó una historia similar sobre un experimento en el que aumentaron de 10 a 30 los links de las respuestas del buscador. ¿El resultado? Una caída del 20% en tráfico y revenue. ¿Por qué? Porque el tiempo de la carga de páginas de resultados pasó de 0.5 a 0.9 segundos.

El rendimiento es diferencial

Para los que no conozcáis la historia de Spotify, The Playlist es una miniserie de Netflix que narra los inicios de la compañía sueca desde distintos puntos de vista. 

El episodio dedicado a su fundador, Daniel Ek, pone especial énfasis en la obsesión que tenía porque la carga de una canción fuera lo más rápida posible, hasta el punto de que pareciera magia.

Ek sabía que, si quería tener algo que hacer contra la piratería con un producto de pago como Spotify, necesitaría ofrecer una experiencia de uso que fuera absolutamente diferencial frente a la opción de acudir a The Pirate Bay y descargarte la última canción de tu artista favorito.

Sus ingenieros lo consiguieron, a base de mucho trabajo de infraestructura e incluso creando sus propios protocolos de streaming propietarios. El resto es historia.

Resulta interesante trazar un paralelismo entre Spotify y los LLMs. Los LLMs se nutren de datos que en su gran mayoría son comunes para todos ellos, y de hecho, ya empieza a haber poca diferencia entre los resultados de unos y otros. Por su lado, Spotify se nutre de un catálogo de canciones que no controla y que también está a disposición de sus rivales. En esta situación, Spotify se diferenció por el rendimiento. Mi experiencia con ChatGPT-4o me lleva a pensar que OpenAI esté haciendo lo mismo.

Medir el rendimiento es fundamental

Por cuestiones de compatibilidad, en la oficina compramos un PC de 100€ para probar cómo se comportaba nuestra tecnología en máquinas con procesadores antiguos (2013 en este caso).

Hace unos días lo arranqué para hacer una prueba y me sorprendió lo rápido que lo hizo (Win10) y lo fluido que iba. Sin exagerar, arrancaba 4 o 5 veces más rápido que mi muy potente sobremesa de 2023 con el que trabajo habitualmente.

Digo esto porque pese a que el rendimiento es fundamental, la realidad es que la industria está en unos niveles desastrosos en este sentido.

Mi sensación es que las empresas que ponen el foco en el rendimiento son las menos, quizás porque escasean los fundadores de perfil técnico realmente preocupados por su craft, y quizás sobran los perfiles de negocio que sólo quieren ver salir funcionalidades por la puerta.

También sobre todo porque el rendimiento es algo que se da por supuesto pero que no se ve, y en muchas ocasiones, tampoco se mide. Y al mismo tiempo, también es muy fácil degradarlo poco a poco sin que tenga efectos aparentes hasta que ya es demasiado tarde.

Es por ello que medirlo y visualizarlo es fundamental. Los ingenieros, disponen de herramientas de observabilidad que recomiendo conocer, como Datadog o NewRelic, pero los Product Managers también podemos disponer de medidas de rendimiento indirectas a controlar en nuestras tools del día a día.

Por ejemplo, algunas que uso a diario y que podemos medir fácilmente con herramientas como Amplitude:

• Tiempo de apertura de la app 

• Tiempo en completar el login

• Tiempo en completar el proceso de onboarding

• Tiempo en cargar el contenido de la aplicación

• Tiempo en llegar al wow/aha moment

• Tiempo en completar una compra

Estas y otras métricas relacionadas con rendimiento las tengo volcadas a varios dashboards donde soy capaz de ver su evolución hora a hora, diaria, semanal o mensualmente. De esta forma, puedo saber donde estamos ahora mismo y saber si estamos mejorando o empeorando la experiencia de uso a lo largo del tiempo.

Más importante aún, tenerlo medido también impone cierta disciplina al equipo, porque sabes que en el momento que se desvíe va a saltar la alerta y todos nos vamos a poner a revisar qué ha ocurrido. Dicho de otro modo, podemos utilizar nuestra métrica de rendimiento como guardarraíl de todo lo que subimos a producción.

El rendimiento no es sólo velocidad. Otro tema al que veo prestar mucha menos atención de la que merece es al número de errores que genera nuestro producto. ¿Cuántos crashes está dispuesto a soportar un usuario antes de desinstalar? Según el estudio de Embrace, pocos. ¿Cuántos errores de login va a sufrir antes de irse a buscar otra alternativa? Existen herramientas como Sentry, que facilitan enormemente controlar estos errores. Mi consejo para cualquier PM o startup, es que empiece a utilizarla.

El rendimiento forma los cimientos de la experiencia de usuario

Desde mi punto de vista, el rendimiento tanto a nivel de velocidad como de número de errores, forma los cimientos sobre los que se asienta cualquier experiencia de usuario que queramos construir. 

El diseño más atractivo y el hook mejor diseñado fracasarán si lo construimos sobre una base endeble y descuidada. En 2024 y en el futuro, donde cada milisegundo cuenta, cuidar la velocidad y eficiencia puede ser la diferencia entre liderar un mercado y quedarse atrás.

El primer paso es sencillo. Medidlo, visualizadlo y haced que forme parte de vuestros indicadores claves de negocio, tanto como la adquisición, la retención o la facturación. Una vez medido, considerad si también puede ser un factor que os diferencia de la competencia. Recordad el caso de Spotify u OpenAI, y en general, el caso de todas aquellas aplicaciones que usáis en vuestro día a día simplemente porque vuelan.

Sólo los que disfrutan de un monopolio pueden imponer experiencias de uso subóptimas a sus usuarios. Muy probablemente trabajes en el lado opuesto, compitiendo en un sector donde un líder destacado domina con claridad. Si quieres hacerte un hueco, no descuides el rendimiento de tu producto. En un entorno donde la mediocridad abunda, puede ser la clave para hacerte un hueco en el mercado.