El producto de software con más éxito de la historia de las finanzas es feo, parece de los años 80 y cuesta cerca de 32.000 dólares al año por usuario. La mayoría de quienes lo pagan usan una fracción mínima de sus miles de funciones. Por cualquier métrica de “features”, el terminal de Bloomberg debería haber sido desbancado hace décadas.
No lo ha sido. Genera más de 12.000 millones de dólares al año, casi todos en suscripciones. Y la pregunta interesante no es por qué es tan caro, sino por qué nadie lo abandona.
Bloomberg no vende funciones, instaló un comportamiento
Un trader organiza su jornada entera alrededor de esa pantalla negra y ámbar: el teclado, los atajos, el flujo de trabajo. Su chat interno, Instant Bloomberg, conecta a unos 325.000 profesionales. Si tu contraparte está ahí, tú tienes que estar ahí. Salir del Terminal no es cambiar de herramienta, es cambiar de vida profesional. El coste de irse no es económico, es psicológico.
Eso es hacer producto: instalar un comportamiento nuevo en alguien. Que mañana haga algo distinto a lo que hacía ayer, decida distinto, trabaje distinto, porque tu producto se lo hace más fácil, más obvio o más inevitable. Si nadie cambia nada, no has hecho producto digital. Has hecho software, que no es lo mismo ni se le parece.
He leído hace poco que los PMs no valen para nada. Quien dice eso no ha hecho producto en su vida, y confunde hacer producto con productizar, que es el hermano tonto y fácil de hacer producto.
Productizar: superficie sin nada debajo
Productizar es lo contrario: añadir superficie sin instalar nada debajo. Una integración porque la competencia la tiene. Una alerta porque un cliente grande la pidió. Una vista nueva porque alguien dijo en una reunión “estaría bien tenerla”. Cada cosa tiene su lógica individual. Ninguna tiene un comportamiento objetivo detrás. Localmente correcto, globalmente incoherente, y esto no es solo cosa de la IA.
La diferencia existe y se ha medido.
Pendo analizó el uso real de producto en cientos de empresas y concluyó que el 80% de las funciones de un software medio se usan rara vez o nunca. Apenas un 12% genera el 80% del uso diario. Su estimación: unos 29.500 millones de dólares de I+D en la nube gastados en features que casi nadie toca. El clásico informe Chaos del Standish Group daba una cifra parecida: en torno al 64% de las funcionalidades se usan rara vez o nunca. Las metodologías de ambos estudios son discutibles, conviene saberlo, pero la dirección es la misma midas como midas.
Eso es lo que produce productizar a escala: superficie que existe sin cambiar nada, cada vez más equipo para mantener algo que no aporta a la cuenta de resultados. Bueno, sí aporta: a la baja.
La feature factory
¿Por qué casi todas las organizaciones acaban ahí? John Cutler lo bautizó como feature factory: empresas que miden su éxito por cuánto entregan (features lanzadas, story points cerrados) en lugar de por qué cambia en el usuario.
Lo gracioso es que suelen ser productivas en el sentido convencional: envían rápido, mantienen velocidad alta, exhiben un historial visible de trabajo terminado. Han optimizado la actividad de construir, no el resultado de construir. Y caen ahí sin proponérselo, porque productizar genera señales de progreso inmediatas (releases, demos, changelogs, reuniones donde enseñar algo nuevo) mientras que cambiar comportamiento es invisible durante meses. Casi ninguna organización premia lo invisible. Premia la actividad. Y productizar es actividad.
El botón con la estrellita
El ejemplo de manual lo tenemos delante. En 2024 y 2025, medio sector del software metió un “copiloto” de IA en la esquina de la pantalla, un botón con una estrellita. ¿Por qué? Porque el inversor y el mercado lo esperaban.
El resultado fue el previsible cuando añades superficie sin mapa de comportamiento. Hubo CRMs que vieron caer la adopción alrededor de un 20% tras lanzamientos de IA apresurados que complicaron la experiencia, y una mayoría de pilotos de IA empresariales terminó sin impacto medible en la cuenta de resultados. El botón se metió para existir, no para cambiar lo que hace el usuario. Y una función de IA que no cambia el flujo de trabajo es, exactamente, una función más que nadie usa.
2026: la IA pone a prueba a Bloomberg
Aquí se pone interesante. Esa misma IA ha empezado a poner a prueba a Bloomberg. Perplexity lanzó un producto que aspira a replicar parte del flujo del Terminal por unos 200 dólares al mes frente a los casi 32.000 al año. Según un sondeo del sector, alrededor de un tercio de los hedge funds y gestoras planean reducir o eliminar terminales en los siguientes 18 meses.
Y esto es lo importante para cualquiera que construya producto: cuando el coste de cambiar se desploma, descubres si habías instalado un comportamiento genuino (algo que el usuario no abandonaría aunque irse fuera gratis) o si solo vivías de la fricción y la inercia de la suscripción. La IA está a punto de hacer dos cosas a la vez: volver barata de copiar cualquier feature, y barato de cruzar cualquier coste de cambio. Lo único que sobrevive a las dos es haber cambiado de verdad lo que alguien hace.
El único test que merece la pena
De ahí sale el único test que merece la pena aplicar antes de meter algo en un roadmap. Completa esta frase antes de escribir una sola línea de especificación:
Gracias a esto, [tipo de usuario] pasará de hacer [X] a hacer [Y], y lo sabremos cuando veamos [métrica Z].
Si no puedes completarla, todavía no tienes una idea de producto. Tienes una idea de feature. No es lo mismo, y la diferencia compone con el tiempo: instalar comportamiento crea ventaja acumulada (el usuario vuelve porque ha reorganizado su vida alrededor de ese hábito), acumular features crea deuda de atención (más opciones, ninguna razón más fuerte para quedarse).
No quiero decir que productizar sea malo. A veces es lo correcto: alcanzar paridad competitiva, no perder un cliente que amenaza con irse, ganar tiempo. El problema no es hacerlo. Es hacerlo en modo automático, sin saberlo, hasta llevar dos años sin poder responder a una pregunta sencilla: ¿qué comportamiento nuevo instalamos este trimestre?
Esa es, al final, la única pregunta que separa a los dos tipos de equipo. Y en la década que viene, cuando copiar una feature cueste una tarde y cruzar un coste de cambio cueste una suscripción de 200 dólares al mes, va a ser la única que importe.
Ese test, “de X a Y, lo sabremos con Z”, es el padre de los criterios de aceptación. Primero decides qué comportamiento instalas; luego viene la disciplina de ingeniería de asegurarte de que el código de verdad lo entrega, porque un build en verde no es una feature correcta. Esa segunda parte es la que PaellaDoc automatiza. Pero la primera la decides tú, y si te cuesta responder a la pregunta, ya tienes la respuesta.