- El modelo SaaS alguna vez convenció a la industria de TI con la promesa de "paga solo por lo que necesitas y concéntrate en el negocio, no en la tecnología", pero en la práctica terminó deformándose en una estructura de lock-in para los clientes
- Los principales proveedores se enfocan más en mantener los pagos recurrentes y recolectar datos que en la satisfacción del cliente, y hasta los llamados Customer Success Managers no son más que un rol para evitar la fuga de clientes
- En toda la industria, bajo el nombre de "best practice", se evita el cambio y la innovación, produciendo al final un ecosistema de software uniforme y mediocre
- El mercado SaaS se ha convertido en una estructura excesivamente controlada y predecible, como los centros comerciales de Estados Unidos en los años 80, donde las grandes plataformas cumplen a la vez el papel de arrendador y tienda
- La verdadera solución no es usar el mismo sistema que todos, sino construir un sistema de información adaptado a la organización, algo que puede lograrse con enfoques alternativos como el autoalojamiento
La promesa y la realidad del modelo SaaS
- En sus inicios, SaaS promovía ideales como "pay as you go" y "enfócate en el negocio antes que en la tecnología", prometiendo una operación de TI más eficiente
- El mensaje persuadía a los usuarios diciendo que podían ahorrar capital y tiempo y reducir la carga de gestionar tecnología
- Pero en la práctica, grandes proveedores como Microsoft, Google e Intuit evolucionaron hacia una estructura que prioriza la dependencia del cliente antes que el enfoque en el cliente
- Después de cada interacción hacen encuestas de satisfacción, pero eso no es más que otro mecanismo para recolectar big data
- Los resultados de la encuesta son secundarios; en realidad solo quieren que el cliente se quede y siga pagando
- Los datos recolectados se usan únicamente para mejoras graduales en los márgenes
La paradoja del Customer Success Manager
- Casi todas las empresas SaaS crearon el rol de Customer Success Manager
- Se les asigna a las cuentas para ayudar con el onboarding y evitar la deserción
- El "éxito" no significa el éxito real de la organización, sino simplemente lograr que use suficientemente el producto
- Hacer productos que el cliente considere útiles no es malo en sí, pero con el tiempo el modelo de negocio SaaS se deformó hasta apoyarse no en el éxito del cliente sino en la sumisión y la inercia
- Al llegar a cierto punto, la base de clientes y el producto se vuelven tan grandes que cambiar se vuelve imposible
Safety in Numbers — la ilusión de seguridad en los números
- Muchas empresas adoptan SaaS por la psicología de "como todos lo hacen" y por los efectos de red
- Si todos los demás lo hacen, se vuelve la ruta de menor resistencia: tal vez buena, o al menos lo suficientemente buena
- Los efectos de red tienen valor, pero los números solo son seguros hasta cierto punto
- Los números ocultan riesgos invisibles, especialmente riesgos tipo black swan
- Son riesgos raros pero catastróficos, tan infrecuentes y potencialmente devastadores que nadie realmente piensa en ellos
- Los sistemas de respaldo, recuperación ante desastres y continuidad del negocio pueden proteger contra la falla de un sistema individual, pero no contra la pérdida de contexto y know-how
- El verdadero problema no es la pérdida, sino la acumulación
- Demasiados programas, APIs, integraciones y una complejidad excesiva disfrazada de sistema sofisticado
- No existe un sistema de recuperación de contexto, pero las organizaciones exitosas dependen del contexto, no de los datos
- Tener terabytes de datos no sirve de nada si no sabes por qué los tienes, qué significan y cómo usarlos
El exceso de información y la trampa de la toma de decisiones
- La información y el contenido son infinitos y probabilísticos, y no necesariamente predecibles
- Más información no lleva a mejores decisiones; solo lleva a más datos
- Esto se alimenta del miedo y el riesgo de no saber
- No se puede conocer toda la información antes de decidir, pero al enfrentarse a lo desconocido y la incertidumbre, adoptar una "best practice" ofrece una cómoda manta de seguridad
Undifferentiated Best Practices — buenas prácticas sin diferenciación
- En toda la industria hay una confianza ciega en las plantillas de "best practice"
- El problema de las best practices es que asumen que el mundo dejó de cambiar
- En la realidad, el mundo no es estático; sigue cambiando y exige mejora continua y evolución
- Adoptar ciegamente best practices convertidas en plantilla no es el camino para ser el mejor, sino el camino para terminar en un promedio mediocre
- Se abusa de la lógica de "no reinventemos la rueda"
- Se afirma que no hace falta gastar tiempo y esfuerzo resolviendo problemas que ya fueron resueltos
- En la práctica, esto solo sirve para destacar en alcanzar paridad con la competencia
- Este enfoque produce mediocridad insípida y funciona como una estructura que bloquea la diferenciación real y el progreso
Bland and Generic Applications — un ecosistema de software uniformado
- Si observas el entorno del software comercial, hay miles de aplicaciones en miles de categorías, pero al final siguen ofreciendo solo distintas variaciones de apps para tomar notas o calendarios
- Algunos programas pueden verse más bonitos o sentirse más intuitivos, pero la definición del problema y la forma de abordarlo son similares
- La razón por la que el software resuelve una y otra vez los mismos problemas solucionables es que los desafíos que quedan son realmente difíciles de resolver con tecnología
- La comunicación y la colaboración están llenas de matices y sutilezas que se resisten a la digitalización
- Esto no se limita a las empresas SaaS; la mayoría de las compañías de software se sumó al tren del SaaS para comercializar y vender sus productos
- Una versión gratuita con apenas las funciones suficientes para empujarte hacia una membresía pagada
- Y después, las clásicas tres opciones de suscripción de good, better, best
- Agregar más herramientas de comunicación no mejora la calidad de la comunicación; solo aumenta enormemente su volumen, generando más ruido y más fatiga
Let’s Go to the Mall — las similitudes entre SaaS y los centros comerciales de los años 80
- SaaS se convirtió en una tecnología parecida a los centros comerciales de Estados Unidos en los años 80
- Excesivamente cara, predecible, y con productos casi idénticos en todos los centros comerciales
- No se trata de un mercado dinámico, sino de un mercado fuertemente controlado
- El landlord establece la plataforma y los minoristas acuden a esa gran ubicación para obtener enormes ganancias y ventajas de escala
- Los minoristas que pueden pagar la renta del centro comercial ofrecen una experiencia altamente controlada
- Los centros comerciales de los años 80 no eran lugares para la experimentación audaz ni para asumir riesgos; el riesgo estaba en firmar el contrato de arrendamiento
- Google y Microsoft son a la vez las tiendas del centro comercial y también el landlord que controla toda la experiencia
- Apple opera su propio centro comercial, más brillante pero no diferente
- Hoy en día, muchos centros comerciales físicos serían pueblos fantasma si el Apple Store no atrajera tráfico
- En algún momento, la cultura se cansó de la experiencia del centro comercial, y Estados Unidos quedó lleno de malls abandonados
- Ese modelo funciona hasta cierto punto, pero las modas cambian
- Entonces aparecen tiendas pequeñas con productos cuidadosamente curados que atraen a la multitud
- El futuro de la tecnología de la información será muy parecido
- Lo importante no es tener el mismo sistema que todos los demás
- Lo importante es tener un sistema de información adecuado para ti
1 comentarios
Opiniones de Hacker News
Se habla del fenómeno de que los consumidores, así como no quieren pagar el “precio real” de la comida o la ropa, también se resisten a pagar el precio real del software
Antes comprabas una herramienta como Postman por $40 una sola vez, pero ahora el modelo es pagar $30/mes por suscripción
SaaS tiene la ventaja de permitir mantener siempre la versión más reciente
Pero el desarrollo de software es, por naturaleza, un trabajo económicamente costoso, y su valor se ha subestimado gracias al trabajo no remunerado de quienes contribuyen al open source
Siente que en los últimos 20 años se ha creado una enorme cantidad de software, pero casi no ha habido avances realmente innovadores
Señala que, aunque el rendimiento de las computadoras mejoró entre 10 y 20 veces, el software se volvió más lento y más complejo
Se critica que el software actual muchas veces se impone a los consumidores y funciona como un caballo de Troya para la recolección de datos y la vigilancia
La gente paga por comida, agua y vivienda, pero no quiere pagar por software
Se dice que, con una inversión y un equipo de tamaño razonable, no habría necesidad de cobrar tarifas al nivel de Adobe por una simple GUI para
curlAdemás, se señala que SaaS tampoco recompensa mejor a quienes contribuyen al open source
La empresa ya pasó por varios clientes y se comenta que Postman está terminando por seguir el mismo camino
Se desea que desaparezcan los posts alarmistas del tipo “AWS se cayó” y que se vuelva a una discusión normal
Se recuerda que antes era perfectamente posible operar con servidores on-premise, e incluso de forma mucho más eficiente que ahora
Ahora hasta los desarrolladores tienen que entender AWS, además de preocuparse por los riesgos de seguridad y por fugas de conocimiento a través de los LLM
Se lamenta que el avance tecnológico haya terminado creando un entorno de desarrollo distópico, y se extrañan las UX simples e intuitivas
Se argumenta que para la mayoría de las empresas es razonable usar SaaS “suficientemente bueno” para correo, calendario, VPN, CRM, etc.
Herramientas como Google Workspace, HubSpot o Power BI se sienten muy superiores a los productos offline del pasado
Se entiende que meter tanta información en una pantalla pequeña es difícil, pero aun así se siente torpe
Se critica la estructura de SaaS que vende las funciones de seguridad por niveles como si fueran rehenes
Si alguien cae en phishing, se dice que es problema de la empresa, no responsabilidad del vendor
Se plantea el tema inevitable de la “piratería” en la discusión sobre SaaS
El hecho de no requerir instalación facilitó muchísimo la adopción
Se añade que el robo de propiedad intelectual es común, pero que los datos al final tienen la tendencia natural a querer ser libres
SaaS en sí no es un mal concepto, y como estructura de pago según uso puede ser razonable
El problema es que el modelo de suscripción se ha vuelto excesivo y que, por el vendor lock-in, mover los datos se vuelve imposible
Como en la estrategia de “moat” de AWS, el usuario termina sin poder salir por las dependencias que él mismo construyó
Por eso se aconseja no depender de SaaS para funciones esenciales
Se señala que enfatizar solo el lado negativo de SaaS es desequilibrado
El SaaS B2B puede dar grandes ventajas a los clientes mientras se mantenga la competencia
Los vendors tienen incentivos para mejorar continuamente el producto y ofrecer nuevas funciones gratis con tal de evitar el churn
En cambio, se recuerda que el software on-premise antiguo tenía contratos de mantenimiento caros y de baja calidad
Al final, se dice que el comprador tiene que elegir un punto de compromiso
Se comenta que productos como Photoshop o AutoCAD habrían sido útiles para freelancers si hubieran tenido opciones de suscripción de corto plazo
Pero en la práctica no es fácil activar y desactivar una suscripción libremente
Se enfatiza que comprar una sola vez es suficiente
Se analiza que el lock-in fundamental de SaaS viene de la combinación de dos elementos
Se sostiene que hay que separar (unbundle) esas dos cosas, y se explica que la primera podría ya estar encaminada con Nix
La tarea pendiente es crear un modelo de negocio de soporte basado en self-hosting
Se cree que técnicamente es posible resolverlo, aunque todavía no se ha implementado