Un inversor que pone una suma pequeña pero acompaña el proyecto estratégicamente, puede ser enormemente valioso. En cambio, un inversor que pone mucho dinero pero presiona constantemente para ejecutar sus caprichos, condena cualquier proyecto.

Ese último tipo de inversor puede ser una fuente de subsistencia para el equipo mientras dure el dinero. Pero la relación que establece con el equipo está viciada por una confusión de roles desde el principio: quien tiene plata, tiene razón. Una relación que se sostiene y se profundiza hasta que el proyecto se cae por su propio peso y falta de dirección.

La confusión de fondo que sostiene esas relaciones viciadas: tener razón, no es lo mismo que estar en lo cierto.

Tener razón es un hecho social: los demás te dan la razón. Algo que dura, mientras dura la relación de poder.

Estar en lo cierto, en cambio, es función de conocimiento, competencia y experiencia en el propio dominio en el que se plantea el problema. Y se pone a prueba contra la realidad. Que es la que tarde o temprano, se impone determinando el éxito o fracaso final del emprendimiento.

El problema estructural: los pasajeros que quieren pilotear

Los pasajeros de un avión no tienen autoridad para decirle al piloto cómo manejar el avión. Los pasajeros de primera clase, que pagaron boletos más caros, no tienen más poder de voto sobre la ruta o la altitud de vuelo.

Esto parece obvio en aviación. En los emprendimientos, se viola constantemente.

El problema surge de la desesperación. Un equipo que necesita dinero urgente, puede no tener claridad sobre qué está resignando en la negociación. Y a la vez, la presión bajo la que se encuentra, puede llevarlo a que no se permita establecer límites. Porque frente a un inversor volátil (quizás el único que se logró conseguir), la más minima negativa podría poner en riesgo la continuidad de las conversaciones… y la propia supervivencia.

Y es así como el equipo termina aceptando condiciones en las que el inversor impone dirección sobre áreas que no conoce.

Esa relación viciada desde el principio se perpetúa: el inversor, al ver que sus condiciones se aceptan, pone más condiciones. El equipo, cada vez más dependiente del dinero, acepta condiciones cada vez más desviadas de las condiciones para prosperar. El inversor, cada vez más insatisfecho con resultados que responden a sus propias instrucciones equivocadas, presiona más.

Es una espiral descendente que termina inevitablemente cuando el dinero se acaba, o el proyecto colapsa bajo el peso de la incoherencia estratégica acumulada.

Los inversores que operan desde el Sistema 1

Muchos inversores exitosos llegan a las negociaciones con una convicción muy riesgosa: que su éxito pasado les da criterio estratégico y autoridad universal.

Usando el modelo de Daniel Kahneman (y la extensión XDM), muchos inversores operan con desde el Sistema 1 (intuición, patrones reconocidos, respuestas automáticas) en situaciones que requieren análisis del Sistema 2 (metódico, racional, basado en supuestos explícitos contrastables con evidencia y sostenido en un marco teórico apropiado).

Confunden haber acumulado capital en una configuración particular de oportunidad, tiempo y recursos, con tener criterio infalible para tener éxito en cualquier proyecto en cualquier industria.

El Metaverso de Zuckerberg es un caso reciente sumamente documentado de este patrón: recursos prácticamente ilimitados, decisiones unilaterales, sordera total a las señales del mercado, y miles de millones de dólares dilapidados en algo que el mercado nunca quiso. Eso no convierte a Zuckerberg en un tonto: lo convierte en alguien que apostó muy fuerte en algo sobre lo que había señales claras de no funcionaría, pero cuyo ego no le permitió procesar esas señales.

La lección para los inversores que observan a Zuckerberg desde afuera: exactamente el mismo mecanismo opera en menor escala cuando un inversor presiona por funcionalidades de moda (“ponele Bitcoin”, “ponele Metaverso”, “ponele inteligencia artificial”), porque sintió que ese elemento es el que los iba a subir al tren del éxito del momento. Cuando lo que suele terminar haciendo, es dejándolos acostados sobre las vías.

El patrón de la funcionalidad de moda

La presión por features de moda, es uno de los síntomas más comunes de un inversor que opera desde el Sistema 1.

El mecanismo es predecible:

1. El inversor se entera sobre una tecnología o tendencia a través de medios generalistas.
2. Siente que estar subido a esa tendencia es lo que distingue a los proyectos exitosos.
3. Presiona para incorporarla al producto, independientemente de si tiene sentido estratégico.
4. El equipo, dependiente del financiamiento, incorpora la feature.
5. La feature no tiene coherencia con el producto, no es adoptada por los usuarios, y se convierte en un salvavidas de plomo. En el mejor de los casos, consume recursos que hubieran servido para algo útil. En el peor, es la clara causa de fracaso.

En esta industria llevamos décadas de ver este patrón, desde “hay que tener una punto com”, “necesitamos una App”, y más recientemente: Blockchain, Metaverso, NFTs, y con IA generativa incorporada a productos donde no tiene ningún sentido estratégico.

El resultado invariable: el producto pierde foco, el equipo pierde tiempo y recursos, y el inversor, al ver que la feature mágica no generó los resultados esperados, culpa a la ejecución (el equipo) en lugar de al diagnóstico (mandarse un mail a sí mismo).

La tensión soberbia / humildad del inventor

Los inventores y emprendedores viven una tensión del ego que también resulta relevante:

• Si lo único que hacés es mirar los errores de los demás y contar cuántas cosas funcionaron mal, te hundís en la resignación: de alguna manera vamos a fracasar. Desde esa posición, es prácticamente imposible avanzar.
• Si tomás el camino exactamente opuesto (soslayar los riesgos porque creés que vos sos un genio y los demás eran estúpidos) sos soberbio, ciego y necio. Tarde o temprano, esos riesgos ignorados se manifestarán como problemas reales. Y en el raro caso de que la soberbia finalmente ceda, quizás se logre finalmente el entendimiento de por qué “los otros estúpidos” lo tuvieron tan difícil.

La posición apropiada, requiere de sostener las dos verdades simultáneamente: la mayoría de los proyectos fracasan por razones identificables y evitables. Y los proyectos que tienen una idea genuinamente buena y ejecución competente, pueden tener chance si entienden y eligen bien dónde pelear.

Esa tensión es exactamente la que la Matriz Estratégica del Inventor ayuda a entender, no en el dominio emocional, sino en el analítico. Si entendés qué tenés, dónde está, y qué podés hacer con ello, podés tomar decisiones informadas en lugar de apostar basado en ego o en resignación.

La fábula del timador, el burro y el Rey

También hay embaucadores que saben que existen inversores con dinero y sin criterio… y se dedican a explotarlos.

El esquema es mantener a los inversores contentos con promesas, hitos cosméticamente cumplidos, y narrativas de “estamos muy cerca del breakthrough”. Con humo y espejos logran vivir de millonarios ingenuos, hasta que el proyecto fracasa… sin que nadie quede señalado como responsable. Después de unas vacaciones en alguna isla paradisíaca, actualizan su LinkedIn como “emprendedores seriales”, dan algunas charlas, quizás hasta vendan algún curso… hasta arrancar otro “emprendimiento”.

Es la fábula del estafador que acuerda con el rey que en diez años va a lograr que un burro hable, a cambio de un pago mensual generoso, y bajo condición de pena de muerte si no lo logra. Un amigo le dice que está loco, que acaba de firmar su sentencia de muerte. El estafador responde: “En diez años, se muere el rey, me muero yo, o se muere el burro.”

Para los inversores que reconocen este patrón: un equipo que dice sí a todo no es una buena señal. Puede ser un equipo que no sabe defender lo que realmente importa en la negociación… o puede ser un timador. En ninguno de los dos casos es el equipo que querés financiar.

Cuando el inversor sí agrega valor

La historia de nuestra industria muestra un patrón claro: la participación de un inversor o acelerador mejora genuinamente un proyecto cuando el inversor estaba dentro de la industria específica del proyecto.

Cuando el inversor tiene experiencia en la industria:

• Sus proyecciones de mercado se basan en conocimiento empírico, no en analogías superficiales.
• Sus preguntas detectan riesgos que el equipo, por falta de perspectiva, puede estar pasando por alto.
• Su red de contactos aporta valor real: clientes potenciales, socios estratégicos, talento clave.
• Su influencia sobre la dirección estratégica está informada por conocimiento y evidencia, no por intuición.
• Se gana el respeto genuino del equipo, porque sus observaciones son pertinentes y útiles.

Cuando el inversor aprendió sobre la industria únicamente a través de medios generalistas, blogs tecnológicos o conferencias:

• Sus observaciones son patrones genéricos que pueden no tener aplicación en el contexto específico.
• Sus preguntas reflejan tendencias de moda, no factores estratégicamente relevantes para el negocio.
• Su red de contactos está formada por personas con el mismo nivel de información superficial que él: no aporta inteligencia de mercado, contactos estratégicos ni capacidad de abrir puertas. No es un activo, sino una audiencia ante la cual se presenta como un visionario.
• Su presión sobre funcionalidades o dirección estratégica está desconectada de la realidad del mercado específico.
• El equipo asiente para evitar confrontación, pero no internaliza sus directrices. La ejecución se vuelve un ejercicio de cumplimiento vacío, no de alineamiento real.

Casos históricos de inversores que condenaron proyectos

Caso: JC Penney y Ron Johnson

Ron Johnson fue el arquitecto de las Apple Stores, una de las innovaciones de retail más exitosas de la historia. En 2011, fue contratado como CEO de JC Penney con el mandato explícito de “hacer con JC Penney lo que hizo con Apple”.

El board de JC Penney (en el rol equivalente al inversor que presiona) quería replicar el éxito de Apple en retail. El problema: lo que funcionó en Apple Stores no era trasplantable a JC Penney: Apple Stores vendían productos con márgenes altísimos a una base de clientes que los deseaba activamente. JC Penney vendía ropa y artículos del hogar a clientes que compraban principalmente por precio y promociones.

Johnson eliminó los descuentos y cupones (el principal mecanismo de compra de los clientes existentes) sin reemplazarlos con algo que esos clientes valoraran. Las ventas colapsaron. El board que había presionado para contratar a Johnson lo despidió 17 meses después. JC Penney nunca se recuperó completamente.

Copiar el modelo de un éxito en un contexto diferente sin entender por qué funcionó en el original es una estrategia autoinmune. El board no tenía criterio sobre retail masivo: tenía admiración por Apple y creyó que contratar a alguien de Apple era suficiente.

Caso Quibi: la startup que ignoró sus propias señales

Quibi recaudó 1.75 mil millones de dólares de inversores prominentes (Disney, NBCUniversal, Alibaba, entre otros) para lanzar una plataforma de video en formato vertical para móviles. La propuesta: contenido de alta calidad en episodios de 10 minutos, diseñado específicamente para ver en el teléfono.

El problema fundamental: YouTube, TikTok, e Instagram ya habían demostrado que el contenido en formato corto funcionaba… pero generado por usuarios, no producido por Hollywood. Los inversores financiaron una producción cara para un formato que el mercado ya estaba consumiendo gratis.

Quibi ignoró las señales durante el desarrollo porque los inversores (todos con credenciales impresionantes en entretenimiento y tecnología) estaban convencidos de que la calidad de producción era el diferenciador. No lo era: la gente no quería producción cara en formato corto, sino autenticidad (o su apariencia) en formato corto.

Quibi lanzó en abril de 2020 y cerró en octubre de 2020. Seis meses, y 1.75 mil millones de dólares después.

La cantidad de dinero invertido y la reputación de los inversores no son sustitutos del ajuste entre producto y mercado. Los inversores con credenciales en contenido tradicional no tenían criterio sobre comportamiento de consumo digital móvil.

Caso WeWork y SoftBank

SoftBank invirtió aproximadamente 10 mil millones de dólares en WeWork, valuando la empresa en 47 mil millones. Masayoshi Son (CEO de SoftBank) fue el inversor principal y presionó activamente para una expansión agresiva y para que Adam Neumann (CEO de WeWork) pensara en términos de dominación global.

El resultado: WeWork intentó hacer un IPO en 2019. El prospecto reveló pérdidas masivas, estructura corporativa caótica, y un modelo de negocio que era básicamente arbitraje de arrendamientos sin ventaja estructural defendible. La valuación colapsó de 47 mil millones a menos de 10 mil millones. Neumann fue forzado a salir. WeWork eventualmente se declaró en bancarrota en 2023.

La presión de SoftBank para crecer a cualquier costo (en lugar de construir un modelo sostenible) fue uno de los factores que aceleró el colapso.

Un inversor con mucho dinero que presiona para crecer más rápido de lo que el modelo de negocio puede soportar no está protegiendo su inversión. Está apostando a que el crecimiento esconda los problemas fundamentales hasta que alguien más pague más.

Casos históricos de inversores que impulsaron proyectos

Caso Arthur Rock y Apple / Intel

Arthur Rock es uno de los inversores de venture capital más influyentes de la historia. Invirtió tempranamente en Intel (con Gordon Moore y Robert Noyce) y en Apple (con Steve Jobs y Steve Wozniak).

Su valor no fue solo el dinero. Rock tenía experiencia directa en la industria de semiconductores y computación. Cuando invirtió en Intel, entendía el mercado de semiconductores porque había financiado proyectos anteriores en esa industria. Cuando invirtió en Apple, entendía el mercado de hardware de computadoras personales.

Sus preguntas y observaciones durante el proceso de inversión identificaban riesgos reales, no modas. Su red tenía valor real para las empresas que financiaba.

Caso Don Valentine y Atari / Apple

Don Valentine (fundador de Sequoia Capital) invirtió en Atari y después en Apple. Era uno de los pocos inversores de la época con experiencia real en el mercado de electrónica de consumo: había trabajado en Fairchild Semiconductor y National Semiconductor antes de dedicarse a venture capital.

Cuando Jobs y Wozniak le presentaron Apple, Valentine reconoció el potencial porque entendía la tecnología y el mercado de primera mano, no porque hubiera leído sobre computadoras personales en una revista.

Su condición para invertir en Apple fue que Jobs y Wozniak contrataran a alguien con experiencia en negocios y marketing. Eso llevó a Mike Markkula, quien se convirtió en el primer presidente de Apple. Esa condición venía de entender que un equipo técnico brillante necesitaba complementos específicos, no de imponer una dirección estratégica ajena al producto.

Caso Benchmark Capital y eBay

Benchmark Capital invirtió en eBay en 1997. Su aporte más valioso no fue solo los 6.7 millones de dólares: fue que los socios de Benchmark tenían experiencia en mercados de consumo online y presionaron a Meg Whitman para aceptar el rol de CEO.

Whitman tenía experiencia en Hasbro y otras empresas de consumo masivo. Era exactamente el perfil que eBay necesitaba en ese momento para escalar de startup a empresa. La recomendación de Benchmark venía de entender qué necesitaba el negocio en esa etapa, no de querer controlar operaciones.

El patrón que distingue ambos casos

Analizando los casos donde el inversor agregó valor versus donde lo destruyó, emerge un patrón consistente:

El inversor que impulsa:

• Tiene experiencia directa en la industria específica del proyecto.
• Sus observaciones identifican riesgos reales basados en conocimiento, no en intuición.
• Sus condiciones para invertir están orientadas a completar lo que le falta al proyecto (talento, estructura, mercado).
• Confía en el equipo para la ejecución dentro de la dirección acordada.
• Entiende que proteger su inversión significa que el proyecto tenga éxito, no que se ejecuten sus preferencias.

El inversor que condena:

• Aprendió sobre la industria en medios generalistas o conferencias.
• Sus observaciones son patrones genéricos inaplicables al contexto específico.
• Sus condiciones para invertir están orientadas a sentirse en control, no a resolver problemas reales.
• Desconfía del equipo y busca supervisar decisiones operativas.
• Confunde el éxito del proyecto con la satisfacción de sus preferencias personales.

La señal de alarma para inversores

Un equipo que dice sí a todo, no es una buena señal.

Un equipo que no defiende su visión estratégica en la negociación con el inversor no va a defenderla después. Está frente a uno de dos casos:

• Caso A: El equipo no tiene claridad estratégica suficiente para saber qué defender. Están tan desesperados por el dinero que aceptan cualquier condición sin evaluar las consecuencias. Ese equipo no tiene las herramientas para navegar la complejidad del desarrollo del proyecto.
• Caso B: El equipo sabe que no va a poder cumplir lo que promete pero necesita el dinero para sobrevivir el próximo mes. Son los timadores de la fábula del burro.

En ninguno de los dos casos es el equipo que querés financiar si querés que tu dinero tenga alguna chance de generar retorno.

El inversor inteligente busca un equipo que defienda su visión con argumentos, que identifique claramente los riesgos, que diga “no” cuando la condición propuesta es estratégicamente incorrecta, y que explique por qué.

La conversación que pocas veces ocurre

Antes de cerrar cualquier acuerdo de inversión, ambas partes deberían tener una conversación explícita sobre roles.

El inversor debería poder responder:

• ¿Qué experiencia directa en esta industria específica me da criterio para evaluar las decisiones estratégicas de este proyecto?
• ¿Cuáles son las decisiones que voy a querer influenciar, y cuáles voy a delegar completamente al equipo?
• ¿Cómo voy a manejar el desacuerdo cuando el equipo tome una decisión que yo no hubiera tomado?

El equipo debería poder responder:

• ¿Qué decisiones estratégicas fundamentales no estamos dispuestos a negociar independientemente de las condiciones de inversión?
• ¿Qué tipo de participación del inversor nos agregaría valor real, y qué tipo nos quitaría capacidad de ejecución?
• ¿Cuál es nuestra posición si el inversor amenaza con retirar su participación si no ejecutamos algo que consideramos estratégicamente equivocado?

Esa última pregunta es la más importante y la que menos se formula. Un equipo que no tiene respuesta para ella está en una posición de negociación perpetuamente vulnerable.

Conclusión

Buscar inversión es necesario para muchos proyectos. Pero buscar inversión sin entender qué tipo de relación se está estableciendo es una de las decisiones más riesgosas que puede tomar un emprendedor.

El dinero siempre tiene condiciones. Las condiciones tienen consecuencias… y las consecuencias se acumulan.

Un proyecto que acepta condiciones estratégicamente incoherentes a cambio de financiamiento, no está resolviendo su problema de recursos. Está postergándolo mientras acumula un problema de dirección que va a ser mucho más difícil de resolver.

Los inventores y emprendedores honestos que he conocido y cayeron en esta trampa, la pasaron muy mal. Odiaron cada minuto que dedicaron a un emprendimiento en el cual lo que había sido su sueño, se convirtió en un constante reproche y en cumplir caprichos imposibles de satisfacer, porque después de un capricho venía otro.

La inversión correcta (la que viene con criterio, con conocimiento de la industria, y con respeto por el rol del equipo que conduce) puede ser una de las variables más poderosas a favor de un proyecto. La inversión incorrecta (la que viene con ego, con caprichos de moda, y con la confusión entre poner dinero y tener autoridad) puede ser exactamente lo que convierte un proyecto viable en un fracaso inevitable.

Saber distinguir las dos antes de firmar es, probablemente, una de las decisiones más importantes que puede tomar cualquier emprendedor.

La entrada El inversor que impulsa y el inversor que condena se publicó primero en Kambrica.

Los inventores tendemos a fundar nuestras expectativas sobre un modelo bastante simple:

INVENTO → ??? → PROFIT!

Los signos de pregunta en el medio, donde deberá ocurrir la magia, vendrían a ser el modelo de negocio. Y en la mayoría de los casos, nadie lo examina con claridad antes de tomar decisiones que después son irreversibles.

Hay dos versiones de este problema.

La primera es el inventor puro que cree que el valor de lo que creó se va a imponer solo, que el mundo va a reconocer la genialidad de su invención y que alguna forma de retribución va a seguir naturalmente. La realidad es que la idea podrá ser genial, pero eso no implica necesariamente que pueda sostener un negocio. Porque no es lo mismo tener una buena idea, que tener una buena oferta.

La segunda es el emprendedor que desarrolla un producto innovador pero, en lugar de entender qué tiene realmente entre manos, avanza “como le parece”, “de libro” o copia el modelo de algún caso exitoso… sin ver que no le aplica.

En la dirección estratégica de una innovación, necesitamos responder preguntas concretas. ¿Qué cosas de nuestro proyecto quedarán expuestas de forma inevitable apenas demostramos que el producto funciona? ¿Qué elementos podemos, o incluso nos conviene, mantener abiertos sin poner en riesgo la monetización futura? ¿Nuestra innovación, es un negocio sustentable por sí mismo, o es en realidad el complemento de otro modelo comercial?

La Matriz Estratégica del Inventor es el modelo que desarrollé para aportar claridad a las decisiones estratégicas de proyectos de innovación y poder contestar estas preguntas con confianza. Es el producto de tres décadas de práctica profesional, cruzado con las lecciones aprendidas allá por 2004 de mi mentor Roberto Cunningham (Director General del IAPG), y la visión de referentes como Jorge Sábato, Joel Spolsky, Frederick Lanchester y Simon Wardley.

La Matriz no prescribe qué hacer: describe el tablero. Una vez que entendés el tablero, podés elegir conscientemente qué juego querés jugar. Antes de eso, estás jugando sin saber las reglas.

El modelo: la Matriz Estratégica del Inventor

La Matriz tiene tres dimensiones:

1. La naturaleza del activo: qué tan expuesto está por su propia naturaleza, independientemente de lo que el inventor decida
2. La protección técnica: qué mecanismos técnicos puede aplicar el inventor para controlar el acceso
3. La protección legal: qué instrumentos legales puede aplicar para controlar el uso

Estas tres dimensiones se organizan en una tabla donde las filas son los niveles de naturaleza del activo, y las columnas son dos grupos independientes: protección técnica y protección legal.

Dimensión 1: La naturaleza del activo

Los activos intelectuales no son todos iguales. Tienen una naturaleza que va de más expuesto a más opaco, y esa naturaleza no depende de decisiones del inventor, sino que es una característica inherente al tipo de activo.

Nivel -1: El conocimiento preexistente

Es lo que existía antes del invento. La ciencia, la cultura, el conocimiento colectivo acumulado por la humanidad. No es apropiable por nadie. No se puede patentar una ley de la física, una reacción química conocida, o una tradición cultural colectiva. El intento corporativo de patentar variedades de quinoa andina o usos medicinales de la cúrcuma ilustra esta violación: es biopiratería sobre conocimiento que pertenece intrínsecamente al Nivel -1.

Nivel 0: Lo inevitable

Es la idea que se revela por el solo hecho de mostrar el producto. No es una decisión de apertura. Es una consecuencia irreversible de existir públicamente.

En el momento en que mostrás que tu producto funciona, revelás que esa idea es posible. Eso no puede protegerse de ninguna manera, independientemente de lo que diga el contrato, la patente, o el acuerdo de confidencialidad. Las leyes de propiedad intelectual no protegen una idea, sino implementaciones específicas.

Si una iniciativa tiene una parte que está expuesta allí, “abrirla” no es un error ni una resignación de propiedad intelectual. Es formalizar lo que ya sucede de hecho. Toda explicación que necesités dar para que la gente se interese o adopte la iniciativa cae en este terreno. Si necesitás explicar cosas para que tu proyecto sea creíble y confiable, eso que tenés que revelar es necesariamente Nivel 0. No tenés forma de protegerlo, y lo mejor que podés hacer es que tu estrategia lo incorpore con claridad.

Si el acceso a la idea, en lugar de generar clientes, es una percibida amenaza a la monetización, básicamente tenés un modelo de negocio autoinmune.

Colaborar en Nivel 0 no genera derechos ni obligaciones sobre lo que venga después. Al ser libre como el aire, este nivel no puede sostener ningún modelo de negocios, porque no podés generar un ingreso sobre algo que circula libremente y no admite una transacción para obtenerlo. Sea quien primero presentó la idea o el último en enterarse, cualquiera puede tomarla y desarrollar algo por su cuenta en capas superiores que sí se pueden proteger y monetizar. Esa estructura comercial futura le podrá deber reconocimiento moral al trabajo original del Nivel 0, pero en la práctica (y por consejo legal) el modelo comercial funciona de manera autónoma.

Las capas superiores sí pueden tener modelo comercial. El Nivel 0 abierto no cierra esa posibilidad: la habilita, generando la credibilidad y las conversaciones necesarias para financiar la propiedad intelectual protegible en niveles superiores.

La pregunta que define qué está en Nivel 0 es simple: ¿alguien que vea funcionar mi producto por primera vez puede inferir la idea detrás del producto, y que mi producto prueba que esa idea es posible? Si la respuesta es sí, está en Nivel 0.

Friendster fue el ejemplo histórico: demostró en 2002 que una red social con identidad real funcionaba. El concepto quedó revelado en Nivel 0 para el mercado entero… incluyendo a Mark Zuckerberg, que era usuario de Friendster cuando lanzó Facebook.

Nivel 1: Lo observable con esfuerzo

Es lo que requiere análisis, ingeniería inversa, o acceso especializado para ver. No se revela solo, pero tampoco está protegido por arquitectura. Con tiempo, recursos, y conocimiento técnico suficiente, es accesible.

El Nivel 1 es donde muchos inventores creen estar protegidos cuando en realidad no lo están. La ilusión de complejidad técnica no es protección.

La fórmula química del Chanel Nº5 reside aquí: aunque la marca es legendaria, cualquier laboratorio moderno puede aplicar ingeniería inversa e identificar sus componentes. La protección real de Chanel no está en la fórmula sino en el control de la cadena de suministro de sus ingredientes específicos, que es Nivel 2.

Nivel 2: Lo controlable

Es lo que el inventor puede mantener en un entorno bajo su control directo. Puede ser un código que corre exclusivamente en un servidor propio, una base de datos de calibración, o los parámetros de un proceso industrial que nunca abandonan la planta. Aquí reside la decisión estratégica real: la exposición no es inherente sino que depende de la arquitectura y la disciplina técnica del inventor.

Coca-Cola opera en este nivel. Al mantener su fórmula como secreto comercial bajo control físico estricto, ejerce una protección que lleva más de 140 años vigente: mucho más de los 20 que hubiera durado una patente.

Nivel 3: Lo intangible

La comunidad, la reputación, la autoridad, el posicionamiento. Este nivel no se patenta ni se guarda en un servidor. Es el único activo verdaderamente permanente, y se construye como consecuencia de las decisiones tomadas en los niveles inferiores. A diferencia de los otros niveles, no admite barreras de protección técnica o legal: solo se cultiva y se sostiene, y puede ser destruido desde adentro por las malas decisiones de quienes lo gestionan.

La red de usuarios, periodistas y políticos en Twitter/X es el ejemplo paradigmático. El microblogging es Nivel 0 y el código podría replicarse en semanas, pero la concentración de capital social de esa plataforma es irreplicable de un día para otro. Aun tras las decisiones más controversiales de su nueva gestión, la plataforma retiene su peso gravitacional sobre todos los clones que surgieron para reemplazarla.

Dimensiones 2 y 3: Las decisiones de protección

El eje horizontal del modelo detalla las barreras que el inventor puede interponer. Son dos grupos de decisiones independientes entre sí.

Protección técnica

La barrera arquitectónica o física. Se divide en tres mecanismos en orden creciente de robustez:

Ofuscación. Ocultar el código fuente, la fórmula, o el proceso. Es el mecanismo más débil: colapsa con un solo evento de descubrimiento. Un ex-empleado, una filtración, o el avance de las herramientas de análisis pueden destruirla. El código de Stac Electronics dependía de esto y colapsó en una sala de reuniones.

Fricción de acceso. Hacer que el acceso sea costoso sin controlarlo absolutamente. Es más robusto que la ofuscación pero sigue siendo temporal: colapsa cuando el cambio tecnológico reduce el costo de acceso a cero. El CD musical obligaba a comprar un objeto físico; Napster redujo esa fricción a cero en 1999 y el modelo de negocio de la industria discográfica nunca fue el mismo.

Control del recurso indispensable. El mecanismo más robusto. No oculta la información; controla la infraestructura física, el hardware, o la cadena de suministro sin la cual el activo no puede funcionar, independientemente de quién conozca el concepto. El Apple Silicon eliminó el mercado informal de los “Hackintosh” que existía en la era Intel. No porque cambiara ninguna ley, sino porque el recurso (el procesador) volvió a ser inaccesible para terceros.

Protección legal

Opera de forma independiente de la protección técnica. Sus instrumentos principales son:

Patente. Protege la implementación específica. Exige revelar el funcionamiento a cambio de un monopolio temporal de aproximadamente 20 años. Tiene alcance jurisdiccional: una patente en Argentina no protege en Noruega.

Copyright. Protege la expresión específica, no la idea. Existe automáticamente en la mayoría de las jurisdicciones y tiene una duración mucho mayor que la patente.

Marca registrada. Protege el nombre e identidad. A diferencia de la patente, no tiene vencimiento mientras se mantenga activa. La Aspirina es marca registrada de Bayer en Argentina y Alemania, pero es un término genérico de dominio público en Estados Unidos, pérdida que ocurrió como reparación de guerra en 1918.

Licencia abierta. Define qué pueden hacer otros con el activo. Una licencia GPL, por ejemplo, permite el uso libre pero exige que todo derivado mantenga las mismas condiciones de apertura. No protege la idea sino que regula su uso.

El principio transversal: proteger es demorar

Ninguna protección técnica o legal sobre un activo es para siempre. Las patentes vencen. Las arquitecturas se vulneran. Los recursos cambian. Proteger es simplemente comprar tiempo.

Una vez que asumís esa premisa, la decisión estratégica se reduce a elegir qué construís con el tiempo que comprás. Hay tres modelos:

Explotación y retirada. Explotás el producto al máximo mientras dura la protección, sin pretensión de extender el negocio más allá de ese límite. Cobrás la renta y cuando la barrera cae, te retirás con el capital. Es una apuesta de un solo tiro, consciente y legítima.

La escalera. Usás el tiempo y el capital que te da tu protección actual para desarrollar el próximo producto. Sabés que tu patente actual vencerá, pero planificás que para cuando eso ocurra ya tendrás la siguiente generación protegida. Es el juego de las corporaciones maduras.

El foso intangible. Usás el tiempo de ventaja para construir una comunidad, una reputación, o un estándar de mercado en Nivel 3. Para cuando los competidores logran replicar tu tecnología, ya no importa: el valor de tu negocio se trasladó a un activo que es inmune a la ingeniería inversa.

Los juegos posibles

Una vez ubicado en la Matriz, el inventor puede elegir su estrategia:

El juego de las patentes (Edison). Registro metódico, licenciamiento activo, y litigio cuando es necesario. Requiere espalda jurídica y acepta que en 20 años la invención será pública. El objetivo es extraer el máximo valor durante la ventana de exclusividad.

El juego del secreto comercial (Coca-Cola). Opacidad estricta y control interno permanente. Protección ilimitada en el tiempo, pero vulnerabilidad total si el secreto se filtra: no hay recurso legal que recupere información revelada.

El juego del recurso indispensable (Apple). Controlar el cuello de botella físico o logístico que hace posible el acceso al activo. No depende de secretos ni de que nadie descifre nada: depende de una posición estructural difícil de replicar.

El juego de la comunidad (Linux). Liberar deliberadamente el Nivel 0 y el Nivel 1 para que la adopción construya un ecosistema de Nivel 3 que ningún competidor puede copiar. El negocio no está en el código sino en la autoridad y los servicios que rodean a la comunidad.

El juego híbrido (Android/Google). Google open-sourceó Android para generar adopción masiva: cualquier fabricante puede usar el sistema operativo libremente. Pero los Google Play Services (la tienda de aplicaciones, los mapas, el login de Google, los datos de comportamiento de miles de millones de usuarios) son completamente propietarios. Los fabricantes que quieren Android con la experiencia completa tienen que aceptar las condiciones de Google. La apertura de la capa visible generó un lock-in invisible en la capa de servicios.

Casos en profundidad

Stac Electronics vs. Microsoft: el costo de mostrar lo que no debías

En 1993, Stac Electronics había creado Stacker, el primer software de compresión de disco en tiempo real para DOS. El concepto era Nivel 0: cualquiera que lo viera funcionar podía entender que era posible. Pero el algoritmo específico estaba patentado y el código fuente estaba protegido por ofuscación: los binarios distribuidos no venían con fuente.

Microsoft quería incluir compresión en MS-DOS 6.0 e inició negociaciones con Stac para licenciar Stacker. Durante el proceso, ingenieros de Stac mostraron código fuente en la sala de reuniones, creyendo que el contexto los protegía.

La negociación fracasó. Microsoft lanzó DoubleSpace. El código era funcionalmente idéntico al de Stacker.

Stac antes de la reunión:

Stac después de mostrar el código:

La protección legal no cambió. La técnica colapsó en un instante por una decisión humana en una sala de reuniones. Stac ganó el juicio y obtuvo 120 millones de dólares, pero la contrademanda de Microsoft (basada en un trade secret que Stac había visto durante las mismas reuniones) los dejó en una posición que los obligó a un acuerdo y los condenó como empresa independiente.

La lección no es no negociar. Es saber exactamente qué nivel estás exponiendo antes de entrar a la sala.

Friendster: validar el mercado para que otro se lo lleve

Friendster demostró en 2002 que las redes sociales con identidad real funcionaban. En el momento en que el producto funcionó públicamente, esa idea pasó a Nivel 0 para el mercado entero. Friendster tenía ventaja de tiempo pero no construyó ningún recurso indispensable en Nivel 2 ni logró consolidar una comunidad de identificación ideológica en Nivel 3.

El resultado: validaron el mercado, educaron a los usuarios sobre el comportamiento de las redes sociales, y le pavimentaron el camino a Facebook, que ejecutó mejor sobre exactamente la misma base de Nivel 0. Friendster terminó vendiendo sus patentes a Facebook por 40 millones de dólares en 2010 y cerró en 2015.

Twitter/X: cuando el Nivel 3 es el único activo real

Técnicamente, Twitter/X no guarda ningún secreto. El microblogging es Nivel 0 y el código podría replicarse en semanas. Mastodon, Bluesky, y Threads lo hicieron. Ninguno logró desplazarla.

El verdadero activo de Twitter nunca fue la tecnología. Fue la concentración irreplicable de periodistas, políticos, científicos y figuras públicas que convirtieron a la plataforma en la plaza pública digital. Elon Musk pagó 44 mil millones de dólares en 2022: no por el código, sino por esa red. Y la gestión posterior demostró que el Nivel 3 puede destruirse desde adentro: las decisiones más controversiales generaron migraciones que no hubieran sido posibles si el intangible seguía intacto.

Conclusión

La Matriz Estratégica del Inventor no resuelve el problema del inventor. Lo hace visible.

El signo de pregunta del modelo “invento, ???, profit” no desaparece con la Matriz. Pero la Matriz te permite, por primera vez, hacer las preguntas correctas sobre qué hay en ese espacio.

El problema real no es proteger lo que se tiene. Es entender qué se tiene, en qué nivel está, y qué se puede hacer con ello de forma realista. Edison supo qué jugaba. Coca-Cola supo qué jugaba. Linux supo qué jugaba. Apple bajo Jobs supo qué jugaba

Stac no sabía qué jugaba cuando entró a negociar con Microsoft. Friendster no sabía qué jugaba cuando validó el mercado para que otros lo aprovecharan.

Si te resulta evidente que necesitás esta clase de claridad para desenredar los procesos de toma de decisiones en tu proyecto, pongámonos en contacto.

Anexo: 30 casos para los tres modelos estratégicos

El propósito de este anexo no es la exhaustividad sino la calibración: mostrar que los tres modelos estratégicos son patrones que se repiten en industrias, épocas y escalas completamente distintas.

Modelo 1: Explotación y retirada

Este modelo funciona cuando el inventor reconoce con honestidad que su ventaja es temporal y acota sus ambiciones en consecuencia. No es un fracaso estratégico, sino una estrategia consciente y legítima.

1. The Million Dollar Homepage (2005). Alex Tew vendió un millón de píxeles a un dólar cada uno para pagar su universidad. El concepto era irrepetible por definición (solo hay un “primer sitio en hacer esto”) y él lo sabía. Cobró, cerró y no intentó construir un negocio publicitario.
2. Flappy Bird (2013). Dong Nguyen creó el juego en dos días, lo vio llegar a 50 millones de descargas, y lo retiró voluntariamente cuando la atención pública se volvió insoportable. Dejó dinero sobre la mesa de forma deliberada.
3. Wordle (2021). Josh Wardle creó el juego para su pareja. Se viralizó. Lo vendió al New York Times por siete cifras sin pretensión de convertirse en un estudio de videojuegos. Identificó el momento de máximo valor y salió.
4. Hoverboards (2015). Los titulares de las primeras patentes licenciaron agresivamente durante el pico de demanda y se retiraron antes de que la inundación de clones chinos colapsara los márgenes. Jugaron la ventana de tiempo con precisión.
5. Pet Rock (1975). Gary Dahl vendió piedras con manual de instrucciones y se convirtió en millonario en seis meses. Nunca pretendió que fuera otra cosa. Es el caso más puro del modelo: inventó una moda, la explotó, y se retiró.
6. Fidget Spinners (2017). El pico de demanda duró menos de un año. Los fabricantes que lo entendieron explotaron la ventana y salieron. Los que creyeron que era una categoría duradera quedaron con inventario.
7. Snuggie (2008). Una manta con mangas vendida por infomercial. Se exprimió la marca hasta el agotamiento natural del interés sin intentar diversificación.
8. Billy Bob Teeth (1994). Tom Shepard diseñó prótesis dentales cómicas. Generó millones en el mercado de Halloween y novedades sin buscar expansión.
9. El Cubo Rubik (1980s). Ernő Rubik licenció masivamente durante el pico cultural de los años 80. El cubo volvió al olvido, resurgió décadas después, y el modelo de licenciamiento sostuvo el negocio en ambas olas.
10. Aereo (2012-2014). Empresa que retransmitía señales de TV por antenas individuales miniaturizadas, explotando un vacío legal. Operó hasta que la Corte Suprema de EEUU cerró el vacío. Era un modelo construido explícitamente sobre una ventana legal temporal.

Modelo 2: La escalera

Este modelo requiere visión de largo plazo y la disciplina de invertir en el siguiente escalón antes de que el actual colapse. Es el juego de las organizaciones que sobreviven décadas.

1. Gillette. De la navaja de doble filo a Mach 3, a Fusion, a ProGlide. Cada generación de producto se lanza cuando la patente de la anterior está por vencer, manteniendo la exclusividad de forma continua desde 1901.
2. Intel. El modelo “Tick-Tock”: un año optimizaban el proceso de manufactura (Tick), el siguiente renovaban la arquitectura (Tock). Sacaban una nueva generación justo cuando la anterior se convertía en commodity.
3. Pfizer. Viagra → Lipitor → vacunas COVID. Cada megablockbuster financia la investigación del siguiente. Cuando vence una patente, el siguiente producto ya tiene años de desarrollo acumulado.
4. Qualcomm. Construyó portafolios de patentes iterativos sobre cada generación de telefonía móvil: CDMA, 3G, 4G, 5G. Cada estándar nuevo incorpora sus patentes esenciales antes de que nadie más pueda competir en ese espacio.
5. Dyson. De la aspiradora ciclónica sin bolsa al ventilador sin aspas al secador de pelo supersónico. Cada producto lleva la misma lógica de rediseño radical de un objeto cotidiano a una categoría nueva.
6. 3M. Portafolio de patentes en adhesivos y abrasivos que se renueva constantemente. El Post-it fue un accidente que se convirtió en producto; esa capacidad de aprovechar hallazgos laterales es parte del modelo.
7. Corning. Pyrex en los años 1910, fibra óptica en los 70, Gorilla Glass en 2007, Ceramic Shield en 2020. Cada tecnología de vidrio especializado nace de la anterior.
8. ARM. Cada nueva versión de su arquitectura de procesadores se diseña para ser el estándar de la siguiente generación de dispositivos. Su negocio es licenciar arquitecturas, no fabricar chips, lo que les permite estar en todos lados sin fabricar nada.
9. DJI. Iteración agresiva de drones y estabilizadores de cámara. Cuando un competidor logra replicar el modelo actual, DJI ya tiene el siguiente en el mercado.
10. DuPont. Nylon en los 30, Kevlar en los 60, Teflón en los 70, Lycra, Tyvek. Un siglo de escalera de materiales avanzados donde cada invención financia la investigación de la siguiente.

Modelo 3: El foso intangible

Este modelo requiere paciencia y la convicción de que la comunidad construida es más valiosa que cualquier protección técnica o legal. Es el más difícil de ejecutar y el más difícil de destruir una vez logrado.

1. Linux / Red Hat. El kernel de Linux es libre y abierto. Red Hat construyó un negocio de servicios, soporte y certificaciones sobre esa base. IBM compró Red Hat en 2019 por 34 mil millones de dólares. No por el código, sino por la comunidad, la reputación y los contratos de servicio.
2. Wikipedia. La tecnología de un wiki es replicable en horas. La comunidad de editores que mantiene más de 60 millones de artículos con estándares de verificación y neutralidad no lo es. Es el activo real.
3. Stack Overflow. Un foro de preguntas y respuestas técnicas. La tecnología es trivial. El activo es la base acumulada de soluciones verificadas por la comunidad y la reputación profesional que los programadores construyeron ahí durante años.
4. Airbnb. La tecnología de reservas de alojamiento es trivial. El activo real es la red de confianza entre anfitriones y huéspedes construida a lo largo de millones de transacciones verificadas. Replicar esa confianza desde cero requiere tiempo que el dinero no puede comprar.
5. GitHub. Git es un protocolo de control de versiones abierto que cualquiera puede usar. GitHub es la red social donde los programadores construyeron su reputación profesional y donde viven los proyectos de código abierto más importantes del mundo. Microsoft pagó 7.5 mil millones de dólares por ese intangible.
6. Craigslist. Tecnología de los años 90, diseño sin cambios desde hace dos décadas, y sin embargo sigue siendo el clasificado local dominante en EEUU. Su activo es la liquidez local: la cantidad de compradores y vendedores en cada ciudad que hace que la plataforma funcione. Ningún competidor con mejor tecnología pudo replicar esa masa crítica.
7. Waze. El ruteo GPS es Nivel 0. Cualquier app de mapas puede calcular una ruta. El activo de Waze es el reporte en tiempo real de millones de conductores sobre accidentes, policías, y cortes de tráfico, datos que solo existen si hay una comunidad activa generándolos. Google compró Waze en 2013 por 1.1 mil millones de dólares por esos datos y esa comunidad.
8. WordPress. El software de gestión de contenidos está completamente comoditizado. El foso es la comunidad de decenas de miles de desarrolladores de plugins y temas que eligieron WordPress como plataforma para sus negocios. Migrar ese ecosistema es prácticamente imposible.
9. Roblox. El motor gráfico es secundario frente a los que ofrece Unity o Unreal. El activo real es la red de millones de creadores que construyeron juegos en Roblox y los millones de usuarios que juegan a esos juegos. La plataforma vale por la comunidad que la habita.
10. Strava. Registrar una actividad con GPS es una función que tiene cualquier reloj deportivo o aplicación de fitness. El activo de Strava es la red social de atletas: los segmentos con rankings, los KOMs, los clubes, la reputación acumulada en años de actividad. Eso no se migra con un botón.

Santiago Bustelo
Julio de 2026

La entrada La Matriz Estratégica del Inventor se publicó primero en Kambrica.

El problema es que Figma y otras, ya están dejando de ser herramientas de diseño, para ser herramientas de producción. Y diseñar y producir son procesos totalmente distintos, y fundamentalmente incompatibles.

Al fusionar ambos, la herramienta impone sus propias decisiones de diseño. El resultado no es mayor eficiencia, sino productos clones del promedio estocástico. Productos que aceleran la comoditización de tu producto y tu marca.

Y cuando todo se parece, el mercado empieza a elegir exclusivamente por precio. No es una falla de tu equipo de diseñadores; es la consecuencia directa de tomar decisiones estratégicas basadas en el apuro operativo.

El resultado es que el 80% de los proyectos que se lanzan, son indistinguibles.
Porque responden a las reglas de la IA, no las de tus clientes.

Esto no se arregla con diseñadores que programan. Toda metodología de desarrollo desde 1970 reconoce que diseño e implementación van por separado. Fusionarlas siempre sonó tentador. Pero operacionalmente, jamás funcionó.

La presión por producir siempre ahoga la capacidad de crear.

El apuro por “no perderse el tren” nos está haciendo terminar abajo de las vías en lugar de arriba del vagón.

En Kambrica trabajamos con IA desde 2009, mucho antes de que fuera una moda corporativa. Hace poco se vendió Keepcon, una de las compañías tecnológicas con las que trabajamos en sus fases iniciales. En palabras de su fundador: cuando no tenían clientes ni tecnologia, nuestro prototipo permitió a los inversores aterrizar una idea abstracta, entender el modelo de negocio y cerrar su primera ronda de inversión.

Empecé mi carrera en UX hace 30 años, diseñando y desarrollando simuladores de negocios para formación gerencial. Hoy ayudo a líderes y gerentes a tomar mejores decisiones en la intersección entre negocio, diseño y tecnología.

Si buscás una adopción de IA con resultados reales, el apuro es el peor consejero.
Nosotros te ofrecemos experiencia.

Pongámonos en contacto.

–

Santiago Bustelo
Junio, 2026

La entrada ¿Cómo estás encarando la adopción de IA en tu equipo de diseño? se publicó primero en Kambrica.

Kambrica nos aportó gran valor al ayudarnos a ponernos en el lugar de los clientes e incorporar la lógica de UX en la transformación de nuestra forma de dar servicio.

Gerente Propuesta de Valor

Compañía multinacional de seguros y servicios financieros

* Este proyecto se presenta de forma anonimizada, en el marco de acuerdos de confidencialidad corporativa.

Cuando el proyecto entra a una reunión y sale convertido en una máquina de quemar presupuesto

Cuando una organización corporativa inicia un proyecto digital, el problema entra a una reunión y sale convertido en una estructura enorme de recursos, plataformas y meses de desarrollo. No porque sea realmente necesario, sino porque los incentivos de la industria están puestos ahí.

Las software factories facturan crecimiento del proyecto: más equipos, más horas, más complejidad. Nunca menos. En este caso, la organización empezaba las reuniones con una conclusión tomada: “necesitamos una App”. Los usuarios llamaban para consultar información de sus productos financieros y no utilizaban el sitio web existente, que “había quedado viejo”.

Ante este pedido, los comerciales de las agencias se frotaban las manos: “¡Claro que necesitás una App!”. Y tiene que ser para iPhone, Android y tablets. Con un backend moderno, QA, DevOps, múltiples equipos y varios meses de ejecución. En minutos, una idea se había transformado en un equipo de 12–14 personas.

Nosotros hicimos algo distinto: redujimos el problema antes de escalar la estructura. Porque ejecutar rápido la primer interpretación que se tiene del problema, no es agilidad: es desperdicio a gran velocidad. Y evitarlo, nos llevó tan solo una hora.

Una sola reunión alcanza para desenredar el proyecto

Aplicando nuestra metodología XDM (Experience Decision Making), trabajamos separando tres capas que en la mayoría de los proyectos aparecen mezcladas desde el inicio: hechos, interpretaciones, y propuestas de solución.

Ese análisis reveló un dato que nadie había considerado: la frecuencia de consulta de los usuarios estaba entre seis meses y dos años. Eso invalidaba la hipótesis de desarrollar una App: los datos mostraban que a los usuarios se les “llenaba” el teléfono cada tres meses… proponiéndoles eliminar las Apps que no usaban.

El proyecto tenía que contemplar entonces una primer etapa de investigación UX estratégica para entender por qué los usuarios rechazaban el sitio existente y preferían llamar. Sin esa información, cualquier iniciativa era una apuesta a ciegas.

El cliente pensaba que el sitio era “viejo” y “feo”. Quizás tenía razón. Pero las verdaderas respuestas estaban delante de las pantallas.

Mientras que la interfaz (UI) vive dentro de las pantallas, lo que los usuarios experimentan (UX) es lo que sucede delante de ellas.

Ese fue el foco de la investigación estratégica que en tan sólo dos semanas, reveló el problema de fondo: el sitio mostraba menos de la mitad de la información que los usuarios necesitaban para sus procesos de toma de decisiones. Por eso los usuarios llamaban.

La interfaz no estaba fallando por cuestiones tecnológicas o estéticas.
Sino porque no respondía las preguntas que tenían los clientes.

Algo que ninguna agencia se había propuesto atender, perpetuando la trampa de todo RFP.
Después de 4 a 6 meses, el cliente habría recibido exactamente lo que pidió. Pero que no era lo que realmente necesitaba.

Reducir complejidad e incertidumbre antes empezar la ejecución

Nuestra metodología parte de un hecho: los grandes proyectos no fracasan por razones técnicas. Fracasan porque las complejidades se revelan y atienden recién cuando toda la estructura ya está en movimiento.

Por eso trabajamos despejando complejidades de UX, institucionales y tecnológicas desde el inicio del proyecto.

Porque verdadera agilidad no es ejecutar apurados el primer plan que parece tener sentido: es tener la cintura para cambiar dirección cuando aparece nueva evidencia.

1. Complejidades UX: la distancia entre el Negocio y las personas

Para identificar y reducir esta distancia, trabajamos relevando procesos reales de toma de decisiones, entendiendo qué información necesitan los usuarios, cómo la interpretan, y a qué procesos o herramientas de soporte terminan acudiendo.

Eso permite redefinir la arquitectura de información, los criterios de visualización y las prioridades del producto antes de cristalizar decisiones de diseño UI y desarrollo.

2. Complejidades institucionales y políticas

En proyectos corporativos, gran parte del desgaste aparece cuando la solución ya está avanzada y comienzan los rechazos internos: branding, marketing, compliance, stakeholders.

Por eso desde el primer día, realizamos un mapa político de todas las áreas afectadas. Las incorporamos tempranamente en el proyecto en tracks paralelos, despejando todos los riesgos (tales como inconsistencias entre manuales y criterios internos) antes de que impacten en el proyecto.

Nuestro resultado son proyectos sin retrabajos políticos ni ciclos interminables de aprobación.

3. Complejidades IT: factibilidad técnica

En la industria de Banca, Finanzas y Seguros, existe una capa tecnológica crítica de sistemas legados, cuyos responsables deben estar involucrados desde el primer momento. En este caso, la cantidad de información financiera involucrada generaba esperas incompatibles con la experiencia que el producto necesitaba entregar.

Nuestra solución fue construir un motor de front-end inteligente y agnóstico, capaz de reutilizar información ya obtenida, reducir roundtrips innecesarios y realizar carga progresiva de datos sin bloquear la navegación y uso del sistema.

Eso permitió resolver performance sin degradar experiencia, ni sumar más arquitecturas a un stack de por sí sumamente complejo.

Resultados

Mientras las agencias proponían estructuras enormes y costosas para “cumplir con el pedido”, Kambrica superó los objetivos con un equipo reducido, foco estratégico y dirección clara.

Porque nuestros incentivos no están puestos en colocar gente ni vender horas, sino en resolver el problema correcto.

En este caso, el proyecto no necesitaba una App, ni una plataforma tecnológica de punta. Necesitaba entender qué estaba fallando entre la organización y sus clientes.

Sin diagnóstico y dirección, la velocidad solo escala el error.

La mayoría de las organizaciones no necesita más velocidad.
Necesita mejores diagnósticos antes de escalar estructuras, presupuesto y complejidad. Eso es lo que hacemos.

Si sos responsable del éxito de productos o proyectos y sospechás que el problema que tienen entre manos está siendo interpretado de forma incorrecta, hablemos.

Podemos ayudarte a verlo antes de que el costo, la complejidad y el riesgo político sigan creciendo.

La entrada Banca, Finanzas & Seguros se publicó primero en Kambrica.

Pero saber que alguien tiene 39 grados de fiebre, no nos dice cómo bajarla. Porque medida no es diagnóstico.

Y de la misma manera en que la fiebre no es “más rayitas en el termómetro”, una conversión no es “un click en un CTA”.

Una conversión es cuando una persona se convierte en otra. Por ejemplo:

• cuando un visitante, se convierte en usuario (empieza a usar el producto)
• cuando un usuario, se convierte en cliente (empieza a pagar por el uso)

Eventos que suceden en la pantalla (como hacer click en “crear cuenta”), sirven para “medir las conversiones”. Pero la conversión ocurrió mucho antes que ese evento.

El click ocurrió porque un dedo se acercó al botón. El dedo, porque un cerebro lo dirigió. Y ese cerebro, por una larga cadena de evaluaciones, información y decisiones, consideró que hacer eso, era mejor que no hacerlo.

Descifrar esa cadena causal y detectar dónde podemos intervenir es función de la investigación cualitativa y la consultoría estratégica.

¿Querés pasar de medir los síntomas de tu producto a operar sobre las causas?

Hablemos.

La entrada Medida no es diagnóstico se publicó primero en Kambrica.

Por ejemplo, le das a “analizar” tu sitio de “forma experta”. Y básicamente, te dice que hagas todo lo que no estás haciendo.

Te lo dice de forma confiada y convincente. Hasta genera cierto sentido de urgencia.

Pero se revela como un truco de feria cuando sabés que eso que no estás haciendo ahora, es por haberlo intentado antes. Y haber comprobado que no funciona.

Cuando al mago se le ven los hilos

La IA, puesta a “hacer recomendaciones”, lo que hace en realidad es completar una plantilla con “lo más probable”.

Y de la misma forma en que te rellena los textos con la insufrible plantilla “No es X. Es Y”, tiene una plantilla de “recomendación experta”:

• Título que suena a hallazgo.
• Supuesta evidencia del problema.
• Presunto impacto verosímil.
• Conclusión preocupante y tajante.

Cada vez conozco más responsables de producto y emprendedores que están ejecutando esas recomendaciones, sin ver resultados.

Porque las IA están entrenadas con lo que se puede encontrar dentro de una pantalla.
Y los resultados no vienen de ahí.
Vienen de lo que pasa delante de las pantallas.

¿Cuánto tiempo llevás implementando las recomendaciones de tu IA, sin ver resultados?

Hablemos. Podemos ayudarte a cambiar el foco a donde realmente importa.

La entrada La IA haciendo recomendaciones de “mejoras”, parece mágica. se publicó primero en Kambrica.

Alguien detecta un problema serio en la experiencia de usuarios. Los equipos internos no tienen formación o capacidad. Y entonces, aparece la solución estándar: una licitación.

El problema es que la licitación no es una herramienta neutral. Es una máquina de golpear, empujar, aplastar y recortar problemas complejos hasta que entran en el molde de las comparaciones simples que permite una RFP. Y ahí empieza el problema real.

¿Estás evaluando proveedores… o estás simplificando un problema que todavía no entendés bien?

Una licitación no resuelve incertidumbre: simplemente la reordena en una tabla.

Horas, roles, entregables, experiencia mínima, precio.
Todo lo que no entra en una planilla, desaparece.

Y en UX, lo que no entra en la planilla es justamente lo que define el resultado.

• La calidad de la investigación.
• La calidad de las decisiones.
• La capacidad de leer fricción real en sistemas complejos.
• La habilidad de intervenir sin romper lo que ya funciona.

Eso no se mide en una grilla.
Pero como “se pondera”, queda la ilusión de que fue evaluado.
De forma matemática. Científica. Precisa.

El error estructural: tratar una decisión como un proceso administrativo

Las licitaciones funcionan bien cuando el problema ya está definido.

• Comprar infraestructura.
• Contratar capacidad de ejecución.
• Externalizar tareas conocidas.

Pero cuando el problema es precisamente no saber qué hay que hacer, el proceso falla por diseño. Porque asume que:

• el problema ya está claro
• los criterios de éxito están definidos
• el evaluador sabe lo suficiente para comparar alternativas complejas

En UX estratégico, eso rara vez es cierto.

El efecto colateral: optimización de proceso, no de resultado

Antes de contratar a una agencia, la organización ya tomó la decisión más importante: cómo va a decidir.

Y ahí se juega todo. Porque si el modelo de decisión es incorrecto, todo lo que venga después es consistencia en el error.

• Más workshops.
• Más entregables.
• Más horas.
• Más diagramas.

Pero el problema de fondo sigue intacto.

El problema real no es UX, o IT, o cualquier servicio profesional estratégico.
Es cómo decidís contratarlo.
Si desde una consulta clínica donde se pueda elaborar un diagnóstico profesional,
o desde la lista de soluciones que pudiste imaginar sin esa instancia.

Por qué las organizaciones siguen haciéndolo mal

No es ignorancia, sino por la necesidad de mantener la ilusión de control.
Las licitaciones dan sensación de orden:

• comparabilidad
• proceso conocido
• legitimidad interna
• protección frente al riesgo político

El problema es que esa sensación reemplaza a la calidad de la decisión.
Y cuando eso pasa, el sistema elige lo que es defendible, no lo que es correcto.

UX falla porque fallan las decisiones

UX falla en la mayoría de las organizaciones. Porque UX es tomar decisiones. Y en las organizaciones, suele fallar la forma en que se decide UX.

En 2026 cumplimos 30 años trabajando con grandes empresas y organizaciones, públicas y privadas, en más de 40 industrias.

Y hay un patrón que se mantiene constante: los proyectos no fallan por falta de ejecución, sino por decisiones iniciales sin el encuadre adecuado.

La decisión de cómo contratar la dirección de un equipo de UX (desde una consulta clínica, o desde un checklist de deseos), es una de las más críticas. Porque define todo lo que viene después.

Cuando tu única herramienta es una licitación, todo clavo se resuelve martillándolo hasta que entra en una RFP

El problema aparece cuando una organización intenta resolver con procesos administrativos lo que en realidad es un problema de decisiones.

Y UX, en su núcleo, no es ejecución. Es un sistema de decisiones aplicado a producto.

Por eso, el primer problema para resolver un problema de UX, no es “hacer UX”.
Es cómo la organización decide qué es una buena solución.
Y eso empieza mucho antes de contratar a nadie.

¿Este patrón se repite en tu organización?
Hablemos.

La entrada La ilusión del proceso: por qué las licitaciones no te están ayudando a resolver tu problema se publicó primero en Kambrica.

La adopción no “ocurre”. Se diseña. Antes del código.

Navegar a ciegas

Si estamos en el polo norte, la brújula no encuentra dirección: no hay un “ángulo” donde esté el norte. Y hacia todos lados, está el sur.

Lo mismo sucede en la industria del software con un principio que nos ha acompañado desde los inicios: la idea de que la tecnología agregaba valor por sí misma.

Ahí donde no había tecnología, la incorporábamos. Y de forma automática, creábamos valor. Eso llevaba naturalmente a su adopción y a mejores resultados.

Este principio nos ayudó a establecer dirección durante décadas: primero en los procesos de informatización, y luego en la transformación digital.

La brújula que dejó de funcionar

Hoy ocurre que ya nos encontramos en el Norte de estos procesos: ya hay una computadora en cada escritorio, una en cada bolsillo (móvil), una en cada living y habitación (smart TV), varias en cada auto… 

Entonces, este principio que fue nuestra brújula, hoy nos da lecturas erróneas.

El caso Copilot

Es así que Microsoft –nada casualmente, la empresa que tuvo por misión “una computadora en cada escritorio y en cada hogar”–, contando con un equipo de ingeniería de primer nivel, un presupuesto de marketing comparable al PBI de un país pequeño, y un canal de distribución privilegiado (las actualizaciones del sistema), lo que ha logrado es… un meme:

Copilot no es una excepción. Es la advertencia de que el principio de que “la tecnología asegura adopción” ya no aplica.

Es la punta del iceberg de miles de proyectos que veremos este año, cuyo postmortem será: “no lo hicimos porque era fácil, útil, ni rentable: lo hicimos porque el entusiasmo en la IA, nos hizo creer que lo sería“.

Desarrollo y adopción ya no van juntos.

Hoy la ecuación ya no es “más tecnología = más adopción = mejores resultados”.
Hoy la ecuación es: “Tecnología x Adopción = Resultados”.
Si adopción es cero, todo esfuerzo aplicado en Tecnología, es desperdicio.

La pregunta correcta

La pregunta ya no es: ¿Qué tecnología deberíamos agregar?
Sino: ¿Qué problema estamos tratando de resolver, y cuál es la manera más simple, rápida y económica de validar si eso es un buen negocio?

La adopción no “ocurre”: se diseña.
Y se diseña antes de escribir una línea de código.
Porque cada proyecto que arranca sin validar adopción es costo hundido.

Si tu próximo proyecto todavía empieza por tecnología, ya empezó mal. Hablemos antes.

La entrada La tecnología no asegura adopción (y eso te cuesta millones) se publicó primero en Kambrica.

A todos les conviene que el proyecto crezca.
A nadie le conviene evaluar si el proyecto tiene sentido.

Así proliferan proveedores que cumplen pedidos, no contradicen, “avanzan con eficiencia”.

Cuando finalmente el sistema no se usa, nadie lo adopta o el negocio no mejora, el costo hundido queda dentro de la organización. El resto cobró igual. Con incentivos mal alineados, no corregir a tu cliente cuando se equivoca es un buen negocio.

La mayoría de los proyectos de software fracasa.
Pero no por cuestiones técnicas.

Sino por decisiones mal planteadas, supuestos no validados y ausencia de criterio profesional en momentos críticos.

Cada fracaso se percibe como un caso aislado.
Pero no es mala suerte: es un patrón.
Y es completamente prevenible.

En industrias maduras, la autoridad técnica implica responsabilidad sobre el resultado. Ése es el sentido original de la consultoría profesional: asesoramiento experto para tomar mejores decisiones, no proveer manos para ejecutar las que ya se tomaron.

Las software factories venden fórmulas porque las fórmulas escalan. Las agencias venden horas porque las horas escalan. Las plataformas venden uso porque el uso escala. Nada de eso garantiza resultados.

La dirección estratégica, sí.

Empieza por una breve sesión de diagnóstico.

Cuando una organización necesita revisar el rumbo de un proyecto, validar supuestos o reducir riesgo antes de invertir más, esta sesión permite analizar la situación y determinar si tiene sentido avanzar.

Si tenés autoridad sobre los proyectos, contanos sobre tu situación y si creemos que te podemos ayudar de verdad, coordinaremos la reunión.

Compartir

Si este patrón resulta familiar, probablemente alguien más en la organización también debería verlo:

La entrada En software, la mayor amenaza no es técnica. Es la estructura de incentivos. se publicó primero en Kambrica.

• mencionar la Navidad podía ofender a otras religiones,
• indicar el año implicaba que nuestro calendario es superior a otros, y
• desear felicidad suponía que quien recibe la tarjeta no la tiene, asumiendo una carencia emocional previa.

Así que, tras un riguroso proceso de pensamiento crítico y revisión legal, presentamos la tarjeta políticamente correcta definitiva:

La entrada ¡Les deseamos un año! se publicó primero en Kambrica.

Cualquiera podía notar que el esquema era absurdo: cualquier gusto se siente en toda la lengua, no sólo en una región particular. Pero el sistema educativo no estaba diseñado para que nadie lo dijera. El esquema sobrevivió porque no era un problema de biología, sino de sistema.

Lo que ocurrió es que estudios tempranos sobre umbrales de detección gustativa, mal interpretados y luego simplificados, se convirtieron por repetición y autoridad en dogma escolar. Cuando la ciencia ya lo había refutado, el esquema seguía en manuales y pizarrones. No por mala intención, sino por diseño: el sistema no premiaba cuestionar, sino repetir.

El modelo educativo del siglo XX no fue diseñado para formar pensamiento crítico. Fue diseñado por una sociedad industrial para alimentar a esa misma sociedad con egresados entrenados para obedecer procesos estandarizados, destinados a trabajos cuya cultura de gestión replicaba la ya conocida y probada para manejar personas a gran escala: el modelo militar.

Ese es el modelo industrial de educación: una fábrica de empleados, no una usina de pensamiento crítico.

De la lengua al NPS

Ese mismo patrón se vive hoy en las organizaciones y se replica en la industria de las experiencias.

Porque quienes de niños fueron adoctrinados a repetir mitos escolares (como el mapa de la lengua), no sorprende que de grandes generen, repitan y apliquen mecánicamente y sin cuestionar mitos corporativos. Como el NPS, que en la práctica opera como numerología corporativa.

Después de más de dos décadas, no existe evidencia científica sólida que demuestre que el NPS sirva para medir ni para gestionar la calidad de la experiencia. No resiste análisis conceptual, ni metodológico, ni empírico. Aun así, se utiliza porque “es lo que se usa”, y porque cuestionarlo se percibe como un ataque personal a la autoridad de quien lo impuso.

La superstición mutó de aula a comité ejecutivo.

NPS no tiene un solo componente que resista un análisis serio. Jared Spool documenta cómo ni la pregunta, ni la fórmula, ni las inferencias derivadas del NPS resisten análisis. Sin embargo se aplica porque ejecutivos, formados en el mismo modelo educativo industrial, “quieren números”. Y como cualquier ficción en Excel les sirve, pues les damos una que permita argumentar que nos merecemos el bono.

¿A quién le regalamos la comodidad de no tener que pensar?

Larry Tesler formuló el principio de conservación de la complejidad:
la complejidad no se elimina, se traslada.
O la asume el sistema profesional que diseña y desarrolla, o la paga el usuario final.

XDM articula este principio con el modelo de Daniel Kahneman, desarrollando cuatro niveles decisorios:

• Nivel 0 – Ejecutivo: respuesta reactiva al estímulo, sin proceso de decisión.
• Nivel 1 – Intuitivo: juicios automáticos de bajo costo cognitivo.
• Nivel 2 – Analítico: procesamiento racional, secuencial, de alto costo cognitivo.
• Nivel 3 – Creativo: generación de nuevas opciones.

De esta articulación surge una regla profesional simple:

Los productos, servicios y sistemas no deberían exigir a los usuarios más que la activación de los niveles 0 y 1. Para que eso sea posible, quienes los diseñan y gestionan deberían operar deliberadamente en los niveles 2 y 3.

Ocurre exactamente lo contrario.

Por falta de formación y de cultura de gestión basada en evidencia y modelos racionales, quienes idean, diseñan y gestionan productos operan ellos mismos en los niveles 0 y 1: hacen “lo que les parece”, sustituyen preguntas difíciles por respuestas fáciles y repiten prácticas, métricas y frameworks sin preguntarse de dónde salieron ni qué miden realmente.

Como consecuencia, la complejidad que se niegan a procesar ellos, se traslada al usuario: los usuarios finales quedan obligados a activar los niveles 2 y 3 (los más lentos y costosos) para entender y operar productos todos los días.

Eso no es una falla de usabilidad.
Es una violación al principio profesional de responsabilidad cognitiva.

Qué propone XDM

Experience Decision Making plantea un principio de responsabilidad profesional:

El esfuerzo cognitivo pesado corresponde al equipo profesional, nunca al usuario final.

XDM integra psicología cognitiva, teoría de la decisión y principios de gestión para desterrar supersticiones organizacionales, reemplazarlas por modelos con fundamento, y darle base a la gestión del siglo XXI de la industria de las experiencias.

No se trata de “medir mejor”.
Se trata de pensar mejor antes de decidir qué medir.

Si en la industria de las experiencias todavía estás usando mapas de lengua organizacionales, el problema no es la herramienta. Es el modelo mental industrial con el que estás decidiendo.

La entrada El mapa de la lengua y la fábrica de supersticiones se publicó primero en Kambrica.

Formularios que no permiten copiar y pegar, contraseñas imposibles de recordar, flujos innecesariamente largos, confirmaciones redundantes. Medidas que incomodan al usuario, complican procesos críticos y degradan la experiencia general. Y todo sin ninguna evidencia sólida de que hagan al sistema más seguro.

El problema no es técnico.
Es epistemológico.

Seguridad vs. practicidad: una falsa dicotomía

Buena parte de las decisiones de “seguridad” que degradan la usabilidad se apoyan en una falacia formal bastante básica: la afirmación del consecuente. Como seguridad y practicidad suelen percibirse como incompatibles, se asume que cualquier cosa que vuelva un proceso más engorroso debe hacerlo más seguro.

En otras palabras, se toma una consecuencia frecuente como si fuera una causa, y un efecto colateral como si fuera un mecanismo de protección. El razonamiento es inválido, pero está tan naturalizado que rara vez se lo cuestiona.

No hay threat modeling detrás, ni análisis de vectores reales, ni mediciones de impacto. Hay incomodidad inducida, presentada como control. Esfuerzo confundido con robustez, molestia con mitigación. Y un axioma aceptado sin demostración.

Cómo se construyen las supersticiones

Las supersticiones tienen una ventaja cognitiva poderosa: no requieren prueba. Como no existe forma de afirmar causalmente por qué algo no ocurrió, cualquier acción previa puede ser postulada como la razón de su ausencia. El razonamiento es simple (y profundamente defectuoso): hice X, no pasó Y, entonces X evitó Y.

Supongamos que hoy fuimos a trabajar con los calzoncillos azules. No nos asaltaron por el camino. A partir de ahí, decidimos establecer una relación causal inexistente: los calzoncillos azules evitan asaltos. Desde ese momento, los usamos todos los días, convencidos de que nuestra seguridad depende de eso. El hecho de que jamás podamos demostrar lo contrario hace que la superstición se refuerce sola.

Este mismo mecanismo opera en muchas decisiones de seguridad informática. Se implementa una medida sin evidencia, no ocurre ningún incidente (como suele pasar la mayor parte del tiempo), y esa ausencia se usa como validación retroactiva. La superstición queda institucionalizada.

Superstición no es prevención

Cuando no hay estudios públicos, datos empíricos, estándares reconocidos ni análisis que demuestren que una práctica concreta mejora la seguridad, no estamos ante una medida preventiva: estamos ante una superstición.

Y ante una superstición, el peso de la prueba no recae en quien la cuestiona, sino en quien la introduce.

La única razón por la que estas prácticas prosperan suele ser una combinación de ignorancia del negocio respecto de procesos racionales de toma de decisiones, miedo difuso a que “algo pase” y una cultura organizacional donde nadie quiere hacerse cargo de explicar por qué no se implementó una medida, aun cuando su justificación viole reglas básicas de lógica proposicional, que forma parte del programa de estudios del secundario.

Si Seguridad Informática trae supersticiones al negocio, es función del negocio tener la madurez suficiente para rechazarlas. No gobernar por miedo. No decidir “por las dudas”. No aceptar fricción inútil solo porque alguien la rotuló como seguridad.

Casos típicos de superstición en Seguridad Informática

Las supersticiones de seguridad no aparecen de manera abstracta. Se manifiestan en patrones concretos, repetidos hasta el cansancio, defendidos con convicción pero sin evidencia. Veamos algunos de los más comunes.

1. Bloquear copiar y pegar en formularios sensibles

El caso más burdo y más frecuente es impedir copiar y pegar texto en campos “sensibles”: montos de transferencias, números de tarjeta, CBU, direcciones, tokens.

La lógica implícita es siempre la misma: si lo vuelvo más difícil, debe ser más seguro.

No hay estudios públicos, papers, estándares ni recomendaciones serias que indiquen que bloquear el portapapeles reduzca fraude o aumente la seguridad. No está en OWASP, no está en PCI-DSS, no está en ningún modelo de amenazas bien hecho. Es una decisión puramente ritual.

El resultado real es conocido: más errores de tipeo, más reintentos, más operaciones fallidas, más frustración, más tickets de soporte. Es decir: más riesgo operativo, no menos.

Si el endpoint está comprometido, bloquear “pegar” no sirve.
Si el endpoint no está comprometido, bloquear “pegar” no aporta nada.

Lo único que hace es tranquilizar a quien lo propuso.

2. Contraseñas deliberadamente inhumanas

Otra superstición clásica: políticas de contraseñas diseñadas para ser impronunciables, imposibles de recordar y renovadas con frecuencia arbitraria.

La creencia es que la complejidad forzada equivale a mayor seguridad. La realidad es que produce exactamente los comportamientos que se supone que intenta evitar: contraseñas anotadas, patrones previsibles, variaciones mínimas, reutilización.

Esto no es nuevo. Está documentado en estándares como NIST SP 800–63B, que señala que los requisitos arbitrarios de complejidad no aportan beneficios significativos y tienden a aumentar la frustración y las contramedidas de los usuarios. Aun así, sigue implementándose porque suena seguro.

De nuevo: fricción elevada, seguridad marginal o inexistente.

3. Expiración periódica sin motivo

Cambiar contraseñas cada 30, 60 o 90 días “porque sí” es otro ejemplo perfecto de superstición institucionalizada, persistente incluso después de haber sido cuestionada hace más de una década por organismos como el NCSC, que advierten explícitamente: “the more often users are forced to change passwords, the greater the overall vulnerability to attack”.

No hay compromiso detectado, no hay indicios de filtración, no hay evento que lo justifique. Se cambia porque siempre se hizo así. Y como nunca pasó nada grave después, la práctica se valida sola.

El razonamiento es circular: como nunca pasó nada, debe estar funcionando. Exactamente el mismo razonamiento que los calzoncillos azules.

4. CAPTCHAs que castigan a humanos

CAPTCHAs cada vez más intrusivos, opacos y fallidos, que afectan más a usuarios reales que a atacantes automatizados. Otro ritual de seguridad.

Los bots evolucionan. Los humanos se cansan. La fricción se desplaza hacia quien no es el problema.

Pero el CAPTCHA queda, porque “algo hay que poner”.

5. Confirmaciones redundantes sin información nueva

“¿Está seguro?” “¿Realmente está seguro?” “Confirme nuevamente.”

Sin aportar contexto adicional, sin resumen claro, sin cambio en el estado de riesgo. Pura repetición.

No es un control.
Es una liturgia.

6. Restricciones sin fundamento

Otro patrón clásico de superstición es imponer restricciones arbitrarias sobre los datos de entrada, sin ningún respaldo normativo, técnico ni de negocio, y luego justificarlas con la palabra mágica: seguridad.

• DNIs que “deben” tener exactamente ocho caracteres.
• Campos de CUIL/CUIT que no permiten más de 11 dígitos, impidiendo ingresar separadores habituales como puntos, guiones o espacios.
• Formularios que rechazan entradas perfectamente válidas porque no coinciden con el modelo mental del programador que las definió.

Estas decisiones no solo son incorrectas desde el punto de vista del dominio (como ya escribí en el caso del DNI argentino) sino que además suelen defenderse con argumentos técnicamente erróneos. He llegado a discutir con “expertos” de un banco que sostenían que estas restricciones eran “por seguridad”, y que por ese motivo había que limitar lo que el usuario podía tipear… usando JavaScript, lo cual es inherentemente inseguro.

Eliminar caracteres no numéricos de un input es trivial. Rechazar usuarios legítimos porque escriben como seres humanos no es una medida de seguridad: es una muestra de ignorancia técnica y de desprecio por la experiencia real.

7. “Por seguridad” como carta blanca para cualquier cosa

La seguridad es una carta tan poderosa que no solo la juega Seguridad Informática. La juegan soporte, producto, legal, compliance y cualquiera que necesite cerrar una conversación sin fundamentos.

Un ejemplo reciente y particularmente ilustrativo: la imposibilidad de eliminar manualmente chats en Gemini dentro de Google Workspace. Ante mi reclamo, la respuesta oficial fue que no se trata de un error ni de una limitación del producto, sino de una medida de seguridad.

No poder borrar información propia, en una cuenta paga, no tiene absolutamente nada que ver con medidas de seguridad. Es una decisión de diseño, y muy mala. O es que todavía no llegaron a ese punto del backlog.

El argumento de seguridad funciona porque es difícil de refutar en caliente. Nadie quiere quedar del lado de “quien bajó la guardia”. Entonces la frase “es por seguridad” se convierte en un comodín que justifica cualquier limitación, incluso aquellas que van en contra de principios básicos de control de datos, privacidad y experiencia de usuario.

El denominador común

Todos estos casos comparten algo fundamental: no están basados en evidencia, sino en miedo. No en modelos de amenazas reales, sino en la necesidad psicológica de sentir que “hicimos algo”.

Y lo más importante: la ausencia de incidentes se usa como prueba de eficacia, cuando en realidad no prueba absolutamente nada.

Eso es una superstición, no una estrategia de seguridad.

Un problema de UX que “no es un problema de UX”

Y acá es importante ser claros: esto no es, técnicamente, un problema de UX. Es una falla de razonamiento.

Demoler supersticiones no debería ser responsabilidad del área de UX. Pero no hacerlo impacta directamente en la experiencia de los usuarios, porque lo que los usuarios experimentan es siempre consecuencia de las decisiones de todos los involucrados. Especialmente cuando esas decisiones se toman a contramano de procesos racionales.

Desde UX no nos corresponde demostrar que estas prácticas no mejoran la seguridad. Nos corresponde mostrar el impacto negativo que tienen en la experiencia: en los procesos, en los errores, en los abandonos, en la confianza del usuario.

A Seguridad Informática le corresponde demostrar que estas prácticas no son supersticiones. Que están respaldadas por datos, estudios, estándares o evidencia empírica. La carga de la prueba es de quien introduce la fricción, no de quien la cuestiona.

Cuando estas decisiones prosperan, lo que vemos no es solo un fracaso del área de Seguridad Informática por introducir falsos positivos, sino también un fracaso del negocio por no contar con procesos racionales de toma de decisiones.

Muchas organizaciones donde esto ocurre no tienen UX. O dicen tener UX, pero no pesa en la mesa donde se decide. Y eso también es un síntoma.

Conozco mucha gente de negocio a la que le gusta decir que es “customer centric”. Pocas están dispuestas a cuestionar supersticiones cuando vienen envueltas en miedo, jerga técnica y la frase mágica: “por seguridad”.

Y así es como terminamos teniendo conversaciones en las que hay que repasar cosas que nuestras contrapartes deberían haber visto como parte de la educación básica.

Santiago Bustelo
Diciembre 2025

La entrada Seguridad Informática: cuando la fricción reemplaza a la evidencia se publicó primero en Kambrica.

El experimento de la cárcel de Stanford nos enseñó algo inquietante: si le das a una persona promedio un uniforme y una pequeña cuota de poder arbitrario, no tarda mucho en comportarse como un déspota. Cuando a eso le sumamos la tendencia natural del ser humano a la superstición, tenemos un cóctel explosivo: la mayoría de las culturas corporativas.

No hace falta ir a un laboratorio para verlo. Basta con mirar cómo suelen empezar las carreras corporativas: atravesando la puerta custodiada por reclutadores que actúan como porteros de la superstición.

Ahí es donde nacen los descartes absurdos:

• “Tiene el marco ‘Open to Work’, seguro está desesperado y va a mentir para conseguir el puesto”
• “Cambió de trabajo muchas veces, seguro que no aguanta la más mínima presión.”
• “Tardó mucho en recibirse… ah no, pará, yo también. Bueno, éste pasa.”

¿Por qué ocurre esto? Como descubrió Daniel Kahneman, nuestro pensamiento rápido (el Sistema 1) es un experto en trampas: sustituye una pregunta difícil por una más fácil sin avisarnos. Ante la complejidad de “¿Es esta persona competente?”, el cerebro perezoso responde a “¿Me gusta lo que leo?”. Y valida esa respuesta como si fuera una certeza técnica.

Desde luego, hay mucha gente de Recursos Humanos que son excelentes profesionales. Socios estratégicos que entienden el negocio, que respetan a las personas y que luchan contra estos sesgos cada día. A ellos, mis respetos.

Pero para los que operan en piloto automático, el daño es real. Y el problema es que, si logras superar a los guardias de la entrada, la cosa no mejora adentro. Ese tejido de sesgos y atajos mentales se calcifica. En muchas organizaciones, a esa acumulación de supersticiones que nadie se anima a cuestionar, le llaman “Cultura”.

Es lo tácito. Lo que se calla por vergüenza o por miedo. Y sobre esa base de barro se toman decisiones millonarias.

No es casualidad que el 91.6% de los proyectos de UX terminen en fracasos. No fallan por la tecnología ni por el diseño de las pantallas; fallan porque los cimientos de las decisiones que los sustentan están socavados por estas supersticiones invisibles.

Y así terminamos viviendo en una realidad disfuncional. Porque seamos honestos, ninguna persona dijo nunca de pequeña:

• “Cuando sea grande quiero pasarme el día escribiendo ficción en planillas de Excel para justificar un presupuesto.”
• “Quiero tener reuniones de tres horas para decidir el color de un botón que nadie va a apretar.”
• “Quiero fingir que estoy de acuerdo con el jefe para que no me echen.”

Vivimos en un mundo artificial, producto de las decisiones de otras personas. A diferencia de la ingeniería, donde si ignoras la gravedad el puente se cae, en la empresa no nos limitan las leyes de la física. Nos limita nuestra capacidad de enfrentar las arbitrariedades y las cosas que alguna vez tuvieron sentido, pero ya dejaron de tener propósito.

Todo lo que nos frustra, todo lo que hace miserables a las experiencias de los clientes y a los días de los empleados, es resultado de decisiones humanas. Algunas tomadas por gente que ya ni siquiera trabaja ahí.

Desde Experience Decision Making (XDM) proponemos un camino para el cambio: hacer consciente lo que hasta ahora era inconsciente. Analizar cómo se toman decisiones. Y desarrollar la competencia y el coraje para tener las conversaciones necesarias para desarmar la maraña de supersticiones en la que vivimos enredados.

Si queremos algo mejor, tenemos que empezar a cuestionar “la cultura”.
De a una conversación a la vez.

La entrada No nos limitan las leyes de la física: nos limitan las supersticiones corporativas se publicó primero en Kambrica.

La Neurona: La Investigación Individual

Una sola neurona no “piensa”. Su función es recibir, procesar y transmitir una señal electroquímica. Es un evento binario, un “sí” o un “no”, un pulso. De la misma manera, una sola investigación de UX (una serie de entrevistas, un test de usabilidad, un análisis de métricas) no es “el éxito del producto”.

La Investigación Individual (La Neurona): Proporciona un insight específico. Por ejemplo: “Los usuarios no entienden el ícono de ‘guardar’ en nuestra app”. Este es un dato crudo, un pulso de información. Es vital, pero por sí solo no genera ingresos ni reduce costes. Es solo una señal.

El ROI de la Neurona: ¿Cuál es el ROI de que esa neurona específica se active? Es una pregunta absurda. Su valor no es intrínseco ni aislado; depende de las miles de otras neuronas con las que se conecta.

El Pensamiento: La Experiencia de Usuario Exitosa

Un pensamiento complejo, una idea o una emoción no surgen de una neurona, sino de la interacción coordinada y masiva de millones de ellas. Es un fenómeno emergente. La red neuronal en su conjunto es lo que crea el valor.

La Experiencia de Usuario Exitosa (El Pensamiento): Es el resultado de conectar cientos de “pulsos” de investigación a lo largo del tiempo. El insight sobre el ícono de “guardar” (neurona 1) se conecta con los datos de una encuesta de satisfacción (neurona 2), que a su vez se combina con el análisis del funnel de conversión (neurona 3) y las entrevistas sobre las necesidades del cliente (neurona 4).

La Red (El Proceso de Diseño y Desarrollo): El equipo de producto, diseño e ingeniería actúa como las sinapsis. Toman estos insights dispersos y los conectan para tomar decisiones informadas:

“Cambiemos el ícono por un texto que diga ‘Guardar Proyecto’”.

“Además, simplifiquemos el flujo de guardado porque las métricas muestran que la gente abandona en ese paso”.

“Y basándonos en las entrevistas, añadamos una opción de ‘guardado automático’ para reducir la ansiedad del usuario”.

El resultado final es un producto más usable, que genera mayor satisfacción, aumenta la retención y, finalmente, impacta positivamente en los ingresos. Ese es el pensamiento completo.

El Desafío de la Atribución Directa

Ahora, volvamos a la pregunta del ROI. Un stakeholder pregunta: “¿Cuál fue el ROI de esas 5 entrevistas que hicimos el mes pasado?”.

Siguiendo la analogía, es como señalar una neurona en medio de un escáner cerebral y preguntar: “¿Cuántos dólares generó esa neurona cuando se activó mientras el sujeto pensaba en ‘comprar ahora’?”.

La atribución directa es imposible porque:

1. El Valor es Acumulativo: El conocimiento de UX se construye con el tiempo. Una investigación de hoy puede prevenir un error costoso en seis meses. Su valor no es inmediato.
2. El Valor es Colaborativo: La investigación informa una decisión, pero no es la decisión. El diseñador que crea la nueva interfaz, el desarrollador que la implementa sin bugs y el marketer que la comunica correctamente también son responsables del éxito. ¿Cómo aislar la contribución exacta del insight inicial?
3. El Valor es Preventivo: Gran parte del ROI de UX Research radica en los costes que evita. Evita construir la funcionalidad equivocada, evita rediseños costosos, evita dañar la reputación de la marca, evita llamadas a soporte técnico. Medir lo que no sucedió es extremadamente difícil.

Conclusión: Cambiando la Pregunta

En lugar de pedir el ROI de la neurona, un enfoque más inteligente es medir la salud y la eficacia del pensamiento general. No preguntes por el ROI de la investigación, pregunta cómo la investigación está impactando los indicadores clave del negocio (KPIs).

Epílogo: Numerología, ROI y Cultura de Gestión

Como vengo diciendo hace tiempo:

Cuando a una cultura de gestión basada en supersticiones le agregamos “métricas”, no obtenemos racionalidad. Obtenemos numerología.

Pedir el ROI de UX Research pertenece a la misma lógica.

No es gestión madura: es cargo culting con planillas de cálculo.

Una cultura que confunde control con comprensión, y números con decisiones. Una cultura desviada, que busca seguridad en cifras porque perdió la capacidad de pensar.

El valor de la investigación no se mide como el rendimiento de una acción en bolsa. Se demuestra en la calidad de las decisiones que hace posibles.

Y eso — precisamente eso — es gestión.

Si quieren sumar herramientas para lograr verdaderas decisiones estratégicas y de valor en la industria de las experiencias: ¡síganme los buenos!

Ah! Y también pueden reservar una sesión de consultoría personalizada para trabajar sobre su caso si ya les está cayendo el peso de métricas mal entendidas y peor aplicadas. Métricas que la gerencia de turno usa ciegamente para enfilar a toda máquina contra el iceberg de la realidad, que terminará hundiendo los proyectos y la relación con los clientes en todas aquellas dimensiones que no pueden medir.

La entrada Pretender que te muestren el ROI de UX Research… se publicó primero en Kambrica.

Relevar, escuchar, investigar… son para esa forma de pensar, señales de debilidad.

¿Contratar expertos? Antes muertos. No ellos… sino los proyectos, o la empresa. Prefieren que el negocio pierda oportunidades, desperdicie dinero o incluso fracase, antes que aceptar que lo que dijeron ayer, vale la pena revisarlo a la luz de la nueva información disponible hoy.

Previsiblemente, los únicos casos en los que avanzamos con un proyecto, es cuando hablamos con el 20% de gerentes actualizados, competentes y responsables que entienden que su función no es ser semidioses omniscientes e infalibles. Su función es ser seres humanos, cargando con enormes responsabilidades – entre ellas, la de aprender y mejorar todos los días. Porque todo es perfectible, y en el momento en el que dejamos de avanzar, nos regalamos a que la competencia nos pase por arriba.

Si sos parte de la minoría de los gerentes que entiende realmente su función en este siglo, te invito a conectarnos y conocernos.

Con casi 30 años ayudando a gente como vos a tomar mejores decisiones, superar desafíos y lograr resultados en más de 40 industrias, seguro tenemos de qué hablar.

La entrada Sos un Gerente del Siglo XXI? se publicó primero en Kambrica.

De a poco, van surgiendo propuestas. Ninguna sobrevive: no es lo que buscamos, no es innovador, no nos parece. Hasta que alguien dice: “pongamos un chat inteligente”.

La idea entusiasma. Marketing ya imagina la campaña. Compras ya identifica posibles proveedores. Sistemas considera que podrá integrar la solución. Entre todos, deciden qué nombre le pondrán al agente virtual y una fecha de lanzamiento.

Varios meses y miles de dólares más tarde, se lanza a medio hacer. Dirige a los clientes a las mismas páginas que antes ya eran viejas, feas y mostraban información desactualizada. Y para eso, primero los obliga a mantener una conversación en la que el chat inteligente no entiende el 83% de lo que le preguntan.

Después de un año de exigir ajustes al proveedor, Marketing finalmente pierde interés en el agente virtual. Sin mucha ceremonia, es retirado del sitio.

En este instante, en una sala de reuniones en algún lugar del mundo, se está iniciando una historia similar. Los actores, problemas y soluciones propuestas difieren. Pero el desenlace será el mismo: una iniciativa prometedora terminando en la agonía y el olvido.

Así empieza mi libro “XDM: Experience Decision Making en 30 minutos” que podés bajar GRATIS de xdm.com.ar, con las bases para evitar que tu equipo se siga embarcando en proyectos destinados al naufragio.

Y sobre esas bases, voy publicando regularmente artículos con más modelos y casos de aplicación.

Te invito a conocer XDM y dejar de sufrir :)

Santiago Bustelo
Octubre de 2025

La entrada ¿Te suena este escenario? se publicó primero en Kambrica.

Para el estereotipo anacrónico de ingeniero informático, si el usuario no puede usar el software, entonces el usuario es tonto.

Para ese mismo estereotipo, si el usuario está enojado por los problemas que le producen las fallas del software, “está un poquito perseguido”.

Para ese estereotipo, “diseño” es decoración. Espejitos de colores que se le pueden agregar al “software” que el estereotipo produce. La función de esos espejitos de colores sería que el software sea “lindo”, “a prueba de bobos”: porque los usuarios son esencialmente estúpidos, y como no entienden las cosas, hay que hacerles dibujitos y ponerles colorcitos.

Esa forma de ver las cosas es propia de la década del ‘70, cuando el software era algo misterioso y arcano que manejaba un puñado de gente en una sala especial en algún edificio muy importante al que muy poca gente podía entrar.

Hoy, que el software está en el bolsillo de todo el mundo, que el software es un producto o servicio que un usuario final tiene la potestad de elegir, de usar y de pagar o dejar de hacerlo, el criterio es muy distinto.

Si tu usuario no puede usar tu software, el error es tuyo: o elegiste mal a tu usuario, o construiste mal el software.

Si tu usuario está enojado por los problemas que tu software le causa, el error es tuyo: tu software no está generando soluciones, sino problemas.

Ésa es la visión de UX estratégico, entendido como la disciplina crítica, nacida en las empresas y equipos que le dieron dirección y sentido a la industria desde la década del ‘80. Y que hoy debe darle dirección a los procesos de toma de decisiones de negocio y de tecnología para lograr productos, servicios y sistemas funcionando, que sean adoptados y aceptados por los usuarios finales reales, y que cumplan con los objetivos del negocio.

Si pensás que ésta es la visión que está faltando desarrollar en tu empresa o equipo, hablemos :)

La entrada El estereotipo de ingeniero informático versus el usuario, esa cosa molesta entre el teclado y la silla se publicó primero en Kambrica.

La charla fue seleccionada para la edición presencial de Nerdear.la 2025, que este año celebró sus 10 años y se realizó de forma virtual del 23 al 24 de septiembre, y de forma presencial en el Ciudad Cultural Konex del 25 al 27 de septiembre de 2025, desde las 9:30 AM con streaming en vivo para todo el mundo.

En “De Figma a la mesa chica”, Santiago plantea un desafío cada vez más urgente para quienes trabajan en diseño: ¿cómo dejar de ejecutar lo que otros deciden y empezar a liderar las decisiones importantes?

El mercado está saturado de talento técnico. Lo que escasea y se valora cada día más, es la capacidad de pensar estratégicamente, influir y tomar decisiones. Esta charla explora el camino menos transitado de UX: cómo pasar del foco en la ejecución a una práctica más madura, donde UX research y diseño marcan la dirección. ¿Cómo se entrena esa transición? ¿Qué habilidades se necesitan? ¿Cómo mostrar ese valor en entornos donde predominan la política, el ego o la manipulación?

Una sesión diseñada para profesionales UX que ya dominan herramientas y procesos, y quieren crecer profesionalmente hacia roles con mayor autonomía, responsabilidad e impacto. Ideal para quienes sienten que les falta “algo más” para dar el salto a mayor seniority y liderazgo.

La propuesta parte de una mirada crítica sobre el lugar que muchas veces ocupan quienes diseñan: atrapados en herramientas, asignaciones técnicas y decisiones tomadas por otros. Y propone un camino posible para salir de ese lugar. No con recetas ni fórmulas mágicas, sino con claridad conceptual y dirección estratégica.

Desde su experiencia como autor del framework XDM (Experience Decision Making) y profesor de Maestría en estrategia UX, Bustelo muestra por qué la industria necesita diseñadores que no se resignen a ejecutar lo que otros deciden. Y cómo salir del sufrimiento o la resignación no pasa por victimizarse ni por culpar a los demás, sino por entender el diseño como una forma de liderazgo. La charla propone un recorrido incómodo pero necesario: desde el deseo que mueve a las personas, hasta las condiciones para influir realmente en cómo se toman las decisiones que diseñan productos, servicios y organizaciones.

Nerdear.la 2025: un clásico que celebró 10 años, ahora más grande que nunca

Santiago presentó esta charla como parte de la edición presencial de Nerdear.la 2025, que se realizó del 25 al 27 de septiembre en Ciudad Cultural Konex, en la Ciudad de Buenos Aires. Esta edición marcó el décimo aniversario de uno de los eventos tecnológicos más importantes de habla hispana, con ediciones en Buenos Aires, Madrid (13 al 15 de noviembre 2025) y Santiago de Chile (16 al 18 de abril 2026).

Este año, Nerdearla ha presentado un line-up de speakers internacionales de primer nivel tales como Vint Cerf (uno de los padres de Internet), Ken Thompson (Co-creador de UNIX), Alan Kay (Pionero de la Programación Orientada a Objetos y la Interfaz de Usuario), Martin Cooper (pionero en el desarrollo de la telefonía móvil), Radia Perlman (conocida como “la Madre de Internet”) y Tony Fadell (quien fuera vicepresidente sénior de la división iPod de Apple Inc. y fundador y exdirector ejecutivo de Nest Labs).

Nerdearla se consolida como un punto de encuentro clave para quienes están redefiniendo el futuro del software, la ingeniería, el diseño y la innovación. La grilla incluye desde investigadores de la NASA hasta líderes de producto en Meta, Google o Spotify. Y todo, como siempre, con acceso gratuito.

Desde su primera edición, Nerdearla apostó por una propuesta única: conferencias de alto nivel, sin charlas comerciales ni discursos vacíos. Con foco en el aprendizaje, la comunidad y la conversación genuina entre pares, se ha convertido en una referencia para quienes no solo quieren trabajar en tecnología, sino hacerlo bien.

La entrada De Figma a la mesa chica: cómo dejar de ser choferes de mouse se publicó primero en Kambrica.

Hace mucho tiempo, analizando cómo mejorar el e-commerce de un gran cliente, nos sorprendió encontrar muchísimas quejas en redes sociales. Los productos no llegaban, y nadie respondía.

Lo elevamos como un problema crítico, junto con propuestas como ofrecer un sistema de tracking para calmar los ánimos de los clientes.

Y la persona responsable del proyecto nos dijo: “Nah, no hace falta. En ese punto ya pusieron la tarjeta de crédito.”

Ante semejante respuesta, se me ocurrió buscar entre las declaraciones de principios de la organización –misión, visión y todo eso– a ver si había algo que pudiera apoyar nuestro criterio. Y lo peor es que no encontré nada.

O sea que esta persona no estaba castigando a los clientes por capricho. Estaba actuando con total coherencia con una cultura a la que no le importaba cómo tratar a sus clientes, y que la había ascendido a tomar las decisiones que estaba tomando.

Y ahí entendí que por bienintencionada que sea, por más resultados que proponga, no hay decisión de diseño que pueda sobrevivir a la falta de principios de las decisiones de negocio.

Santiago Bustelo
Julio 2025

La entrada UX no puede maquillar la falta de principios del negocio se publicó primero en Kambrica.

Un argentino en Helsinki

Allá por marzo de 2016, tuve la suerte de poder participar de la conferencia Interaction 16 en Helsinki, Finlandia. Ya al bajar del avión, tuve mi primer choque cultural: la organización del evento había logrado poner un stand en el aeropuerto. Algo que habíamos soñado cuando organizamos Interaction South America 2014 en Buenos Aires, pero que requería de un apoyo oficial concreto, en lugar del simbólico que recibimos. En Helsinki, en cambio, la ciudad apoyó al evento a tal punto que en el stand entregaban tarjetas precargadas para transporte público, de manera que pudiéramos recorrer y conocer la ciudad durante una semana entera.

Mi segundo choque cultural fue cuando llegué a la parada del colectivo. No había nadie. Después de esperar un par de minutos, empecé a dudar de si esa era la parada correcta. El cartel coincidía con la línea que tenía que tomar, pero la situación me resultaba sospechosa. Entonces recorrí el resto de la dársena, acostumbrado –como en Buenos Aires– a que a veces los carteles queden como resto arqueológico luego de que la línea haya mudado su parada.

No habiendo encontrado otra parada de la línea, volví a la original. Y después de un ratito llegó una persona muy abrigada, a quien le pregunté si la línea pasaba por ahí. Miró el cartel, me miró como si fuera imbécil, y me dijo: “Sí, claro. Ahí dice que pasa”.

“¿Y tarda mucho?”, pregunté. Me volvió dedicar la misma mirada, abrió en su teléfono la aplicación de Google Maps – que mostraba los horarios oficiales– y me dijo: “Pasa en cinco minutos”.

Y cuatro minutos y medio después, llegó desde el aeropuerto un enorme contingente de gente calentita, que había estado esperando a resguardo el horario del colectivo. Porque en Finlandia, los transportes siguen la grilla de horarios. Cosa que me pareció surreal: en Argentina, las tablas de horarios son meras sugerencias, y es habitual estar esperando media hora un colectivo que supuestamente pasa cada tres minutos.

El último choque cultural que tuve fue cuando, ya en el bus, otro pasajero notó mi ansiedad tratando de ver las paradas por las que pasábamos y contrastarlas con las instrucciones que llevaba anotadas. Me preguntó si me podía ayudar, y después de un par de veces accedí. Le conté adónde iba y me dijo que iba para el mismo lado, y que me iba a acompañar.

“Cuando nos bajamos, el gordo me asalta”, pensé. Pero no. Resultó que era una excelente persona que quería que yo tuviera una muy buena primera experiencia en su ciudad.

Me contó que se llamaba Toti, y que era docente de atención al cliente en el secundario. Porque el sistema educativo finlandés tiene que preparar a la gente para la vida real, y entiende que hay gente que no va a seguir la universidad después del secundario. Por ejemplo, va a trabajar en una peluquería. Y un peluquero tiene que saber atender a la gente.

Yo empecé mi carrera como diseñador de interacción en 1996, diseñando simuladores de negocios para formación gerencial. Atención al cliente era un tema recurrente, y teníamos cursos para gente que ya estaba trabajando (en ocasiones hacía años) sin formación alguna. En Finlandia me vine a enterar de que era parte del programa educativo oficial. Mientras que en estas pampas, todavía seguimos discutiendo sobre programas educativos que ya cuando éramos chicos olían a naftalina.

Toti me contó la razón por la que se dedica a hacer este esfuerzo para cuidar la experiencia que tienen los turistas recién llegados a Helsinki. Según él, hay dos tipos de países: los países donde todo funciona, pero nada se puede cambiar; y los países donde nada funciona, pero todo se puede conversar. Me explicó que Finlandia pertenece a la primera categoría: si sabés cómo entrar en el sistema, el sistema te lleva solo. Pero si no conocés el sistema, quedás afuera. Entonces, cuando ve a un turista perdido subirse al bus en el que él viaja, se toma con alegría la oportunidad de ayudarlo a entrar en el sistema.

El Modelo de Lewis

La muy acertada observación de Toti, tiene su reflejo académico en el Modelo de Lewis de Comunicación Intercultural, que clasifica las culturas del mundo en tres grandes estilos de comportamiento:

• Lineal‑activo: personas que planifican paso a paso, hacen una sola tarea a la vez, siguen cronogramas, valoran la puntualidad y la lógica. Es el estilo típico de países nórdicos y aquellos que impulsaron la industria informática.
• Multi‑activo: culturas más emocionales, relacionales, improvisadoras. Realizan varias tareas simultáneamente; priorizan las personas por sobre los procesos formales. Promueven la sociabilidad, la flexibilidad, la persuasión, y una gestión del tiempo policrónica. Alrededor de este polo encontramos a los países latinoamericanos, así como a los que más peso han tenido en definir nuestra cultura: España, Portugal e Italia.
• Reactivo: personas que primero escuchan y luego responden; evitan confrontaciones, valoran la armonía y el respeto. Predomina en Asia oriental.

Esta distinción entre culturas nos puede ayudar a entender por qué las construcciones que funcionan en una cultura lineal, pueden estar destinadas a fallar en una cultura multi‑activa. Como es el caso de las recetas que se suelen aplicar para la transformación digital.

Cuando nada funciona y nada se puede cambiar

En Finlandia, los colectivos cumplen el horario. Todo funciona como un reloj, pero nada se puede acomodar. En cambio, en nuestros países iberoamericanos, los transportes no cumplen el horario, nada funciona del todo… pero todo se puede charlar.

Excepto las cosas que tuvieron la desgracia de ser automatizadas.

Porque los procesos son producto de la cultura que los parió. Y en culturas donde nada funciona pero todo se conversa, informatizar un proceso “formal” cristaliza la parte menos funcional del sistema, justo esa que nunca se seguía. El resultado: sistemas que no funcionan… y que tampoco se pueden cambiar.

Es la peor parte de nuestra cultura, traducida a procesos y codificada con rigidez, la peor parte de la cultura que inventó la informática.

El mundo según la informática

La informática nació en culturas lineales. Culturas en donde el tiempo se entiende como una secuencia ordenada de eventos. En donde entre lo que tengo y lo que quiero, hay pasos que se recorren en orden.

Para nosotros, eso no es evidente. En nuestra forma de ver las cosas:

• las prioridades cambian según la ansiedad del momento,
• entre hoy y mañana puede pasar cualquier cosa,
• el horizonte máximo de planificación es hasta las próximas elecciones,
• y el trámite depende de la persona con quien hablaste.

En nuestro mundo, los procesos no existen realmente hasta que alguien los necesita. Y cuando surge la necesidad, el verdadero proceso se activa: con una llamada, un contacto, un favor, un atajo.

Es algo muy común en nuestros países: el proceso documentado suele ser una abstracción que no describe toda la complejidad del proceso real. Lo que realmente funciona está en la cabeza de cada empleado, que fue armando su parte a fuerza de prueba, error y supervivencia laboral. Los empleados no ejecutan los procesos del sistema: ellos son el sistema.

Cuando el procedimiento es ficción

El problema es que los sistemas informáticos que se proyectan en este contexto, suelen tomar el procedimiento formal como todos los “requerimientos” que hay que considerar para el desarrollo.

Pero el procedimiento que ha documentado el Negocio, muchas veces es más bien un mandato aspiracional: un “deber ser” que no contempla atajos, decisiones informales ni las negociaciones constantes que hacen que el proceso realmente funcione.

El verdadero proceso nace en las personas que tienen que ejecutarlo. Cada una, a su manera, va aprendiendo qué se puede hacer, qué no y cómo compensar los huecos. Lo ajustan con la práctica, con llamadas, con anotaciones en papeles, con “hablá con Marta que ella sabe”.

Aunque una organización tenga una “cabeza”, en nuestras culturas, la verdadera inteligencia que mantiene todo funcionando está distribuida e invisible. Es un poco como el sistema nervioso del pulpo, donde los tentáculos poseen su propia inteligencia: la mayoría de las neuronas (aproximadamente el 60 %) está en los brazos, no en el cerebro central, lo que les permite actuar con autonomía y tomar decisiones locales.

El mayor desafío de la transformación digital, es que las máquinas no pueden improvisar

La mayoría de las organizaciones latinoamericanas no se gestionan con objetivos, sino con declaraciones nebulosas: “hay que terminar esto para mañana”, sin sujeto, sin responsables, sin consecuencias claras.

Nosotros, los humanos, podemos navegar ese mundo. Las máquinas no. Las máquinas necesitan precisión, claridad, estructura. Por eso, los intentos de transformación digital en culturas que viven de la improvisación terminan en sistemas que no sirven, y en personas que buscan cómo rodearlos.

El primer paso de una transformación digital real no es técnico, es cultural. Y requiere sinceramiento: relevar cómo funcionan realmente las cosas, no cómo nos gustaría que funcionaran. Reconocer el proceso real, no el ideal. Entender la red informal de inteligencia que permite que algo tan disfuncional… funcione.

La UX interna y la transformación cultural

Las gerencias construyen en su visión un mundo coherente, que por necesidad no es el que existe hoy: es la visión del futuro. Declaran objetivos, empujan iniciativas, y cuando llegan resultados, consideran que son producto de su visión.

Pero los resultados no vienen de lo que se declara. Vienen del esfuerzo de la organización por hacer algo con eso. Viene de las experiencias, vivencias y decisiones de las personas que trabajan en la organización. Vienen de la UX interna: de lo que los usuarios internos experimentan.

Y ahí entra nuestro rol como consultores de Experiencia de Usuario estratégica. No solo diseñamos sistemas: diseñamos comprensión, y como dice Jorge Arango, somos generadores de coherencia. Construimos puentes entre lo que la gerencia quiere que pase, lo que cree que pasa, y lo que realmente pasa. Ayudamos a ver la inteligencia que fluye por debajo del organigrama. A ver el valor humano y de negocio en la improvisación, en la flexibilidad, en la capacidad de adaptación.

El primer paso de la transformación digital no es “pasar el proceso a la app”. Es conocer y entender los procesos reales. Es mapear cómo realmente funcionan las cosas. Es reconocer que las máquinas necesitan instrucciones claras, y las personas necesitan ser escuchadas.

La transformación digital sólo es posible si se encara como parte de una transformación cultural. Y nosotros, desde la experiencia de usuario estratégica, estamos en una posición única para ayudar a iniciarla.

Santiago Bustelo
Julio 2025

La entrada Transformación digital en Iberoamérica: por qué fallan los modelos del norte se publicó primero en Kambrica.

Sara Beckman, profesora de la Haas School of Business, lo resume en su entrevista para el podcast Finding Our Way de Peter Merholz (cofundador de la mítica Adaptive Path):

“[NPS] no tiene nada que ver con la satisfacción del cliente. No hay correlación entre el Net Promoter Score y la satisfacción del cliente o el aumento de beneficios.

Está mal construido desde el punto de vista estadístico. Elimina dos de las medidas. Ni siquiera es un promedio real.

No es un proxy adecuado para entender si nuestros clientes ahora pueden lograr un resultado mejor que antes. Lo que yo quiero es saber si realmente ayudé a mi cliente a ejecutar los ‘jobs to be done’ que quería que ejecutara.”

Y sin embargo, muchas organizaciones siguen exigiendo a sus equipos de UX que “mejoren el NPS”, como si ese número mágico pudiera guiar el diseño de experiencias. No solo es ingenuo. Es contraproducente.

El problema no es solo el NPS. El problema es pensar que un simple número puede reemplazar la comprensión profunda del cliente, sus decisiones y sus limitaciones. En vez de preguntarnos si el cliente nos recomendaría, ¿por qué no preguntarnos si le hicimos la vida más fácil? ¿Si evitamos fricciones? ¿Si le ahorramos tiempo, pasos, frustraciones?

Lo dije antes en Cargo Culting Management, y lo repito:

Cuando a una cultura de gestión basada en supersticiones le agregamos “métricas”, no obtenemos racionalidad. Obtenemos numerología.

Si lo que medimos no se relaciona directamente con decisiones accionables y cambios concretos en la experiencia, entonces no estamos midiendo: estamos jugando con números.

El diseño estratégico no puede depender de una encuesta de una sola pregunta. Tiene que partir de la comprensión sistémica del valor que generamos –o no– en la vida real de las personas.

NPS suena a gestión. Pero no lo es. Es numerología.

Stop Trying to Make NPS Happen.

La entrada NPS es numerología se publicó primero en Kambrica.

Te muestran pantallas, diagramas, post-its, roadmaps… y en el momento parece que todo va bien – o tal vez sea el carisma del PM lo que te calma. Pero la verdad es que, por dentro, te queda una sensación de inseguridad. No terminás de ver claro, no podés tomar el control, y lo peor: no sabés cómo intervenir con eficacia.

Hay gente capaz, hay esfuerzo, pero falta “algo” en la dirección: algo que te de claridad. Las reuniones parecen interminables, igual que el proyecto. Y cuando el proyecto por fin termina, el resultado… “tiene todo”, pero al mismo tiempo, “le falta algo”. Todo se hizo según el plan. No hay nada puntual que objetar… pero sabés que algo no está bien. Y no podés decir qué.

¿Por qué sigo con la sensación de estar perdido, si estamos haciendo todo “de manual”?

Porque sobran metodologías, pero todas comparten la misma limitación: organizan el trabajo, pero no cómo ni por qué se decide lo que se hace.

Y cuando falta ese criterio, todo se define por intuición, simpatía o costumbre. Porque no se atiende la cuestión de fondo: que las decisiones se tomen de forma estratégica, fundamentada y con visión.

Si experimentaste o estás experimentando estas situaciones, no estás solo. Esto es lo habitual cuando se encara un proyecto de software sin un marco claro para tomar decisiones.

Porque el problema no es la tecnología, ni el diseño, ni el equipo. El problema es no tener un marco para enfrentar de manera estratégica el tejido de decisiones interdependientes que forman un proyecto de software. Entonces, esas decisiones se siguen tomando “como se puede”, según la urgencia o la intuición del momento.

Presentando Experience Decision Making

Experience Decision Making (XDM) es un sistema para tomar decisiones de calidad en proyectos de software y diseño estratégico.

Basado en teoría de la decisión, psicología cognitiva, principios modernos de gestión y experiencia práctica, XDM te da método donde otros improvisan.

Es un sistema probado en proyectos reales, con resultados medibles, diseñado para gente como vos: decisores de negocio que quieren recuperar el mando, y dejar de delegar a ciegas.

Solicitá tu consultoría gratuita y tomá el control de tus proyectos

Si estás al frente de la contratación o el rumbo estratégico de un proyecto, te invitamos a solicitar una consultoría gratuita. En tan sólo 30 minutos, podemos analizar tu situación y ayudarte a evitar los mismos errores.

Esta consultoría está dirigida a:

• Ejecutivos y mandos medios con experiencia en proyectos de software o UX.
• Responsables de negocio que ya han vivido en carne propia cómo no funciona.
• Decisores que están por encarar un próximo proyecto, y quieren hacerlo con más claridad y menos improvisación.

Completá el siguiente formulario para solicitar tu consultoría. Analizaremos tu caso y, si consideramos que podemos ayudarte de verdad, te compartiremos nuestra agenda para coordinar.

La entrada ¿Otra vez en un proyecto a la deriva? Es momento de tomar el control. se publicó primero en Kambrica.

Mi punto es simple: la Dirección UX es al software lo que la Dirección es al cine. Y en la era de la IA, la Dirección UX es un encuadre que nos empodera desde una posición de toma de decisiones, frente a la de “Diseño”, que inevitablemente siempre queda relegada a la ejecución – lo que la tercera ola del diseño digital probablemente se termine llevando de nuestras manos.

Como en el cine, el director UX no necesita ser quien escribe el guion, actúa, opera la cámara o edita. Pero sí tiene que ser quién de forma, sentido y dirección a todo ese proceso para que se convierta en una obra coherente y efectiva, que cumpla con una visión y con objetivos de negocio.

Para lograr nuestra función como Directores UX, tenemos que conocer sobre todas las disciplinas que intervienen – empezando por research, diseño de interacción, diseño de interfaces, lenguaje audiovisual, arquitectura de información, estrategia de contenidos, así como aspectos de marketing, negocio y desarrollo. No necesitamos dominarlas todas operativamente, pero sí entenderlas lo suficiente como para delegar de manera efectiva. Es decir: lograr acuerdos claros, tomar decisiones informadas y construir una visión compartida incluso antes de tener claro cómo será el producto final.

Ese es, para mí, el corazón de la Dirección UX: mantener la visión, despejar el camino, delegar bien y decidir mejor – para lo cual hace falta dominio de metodologías, y ayuda nuestro sistema Experience Decision Making.

No se trata de “saber más” que el equipo, como equivocadamente se plantean muchos jefes. No se trata de mostrar que tenemos más técnica, más herramientas o más experiencia que cada miembro. Se trata de ayudar a que cada uno pueda hacer su mejor trabajo.

Cada persona del equipo sabe que seguramente tiene más dominio técnico que yo. Porque incluso en disciplinas donde alguna vez fui especialista, ya no estoy al día como lo están ellos. Y esa así como debe ser. No es mi rol competir con ellos, es ayudarlos a brillar.

De la misma forma en que un director de orquesta no compite contra el resto de los miembros: su rol es hacer que todos suenen mejor.

Y entonces llegó la IA.

En nuestro equipo, tratamos a la inteligencia artificial como un “ultra júnior”: un asistente que puede hacer algunas tareas útiles, pero que necesita instrucciones muy claras, supervisión intensiva y revisión constante. Porque la IA tiende a desviarse, a inventar, a justificar errores con tono convincente. No es confiable, pero sí útil si se la encuadra bien.

Nos ofrece algo valioso: la línea de base. Lo mínimo esperable. Lo que cualquier persona va a pedirle como primera versión. Y por eso no nos resuelve el trabajo: nos marca la expectativa mínima. A partir de ahí, tenemos que lograr diferenciar y construir valor.

Esto genera un cambio profundo: los roles de menor seniority, ya no son el último eslabón de la ejecución. Ahora tienen que aprender a delegar.

Tienen que aprender a pedirle cosas a la IA. A distinguir entre “que lo haga” y “que esté bien hecho”. Tienen que asumir responsabilidad, no sólo por lo que producen, sino también por lo que hacen otros —aunque ese otro sea una máquina.

Y ese es el motivo por el cual creo que la Dirección UX, como disciplina, es nuestra respuesta al desafío de la IA.

Porque pensar la UX como ejecución ya no alcanza. Necesitamos formar profesionales capaces de dirigir: de pensar en términos estratégicos, de gestionar procesos complejos, de coordinar múltiples especialidades, y ahora también, de integrar inteligencias artificiales en su flujo de trabajo con sentido crítico.

La Dirección UX no es una jerarquía. Es una mirada. Es una responsabilidad. Y es el encuadre que necesitamos para liderar el Diseño en la era de la inteligencia artificial.

Santiago Bustelo
Mayo 2025

La entrada Dirección UX: el encuadre para la era de la IA se publicó primero en Kambrica.

Y hay otros que sólo quieren a alguien que ejecute las decisiones de diseño que ya tomaron.

Para estos últimos, hay un montón de agencias dispuestas a satisfacerlos. Que dicen que sí a todo, que prometen que todo va a salir “lindo y con impacto”, y que están encantadas de ponerse a producir pantallas sin hacer preguntas.

Quienes realmente buscan soluciones entienden, tarde o temprano, que no necesitan a alguien obediente y obsecuente, sino a un socio estratégico.

Una sola reunión suele bastar para saber si somos el equipo correcto.

En Kambrica, partimos de un supuesto simple: si nos están llamando, es porque hay un problema que resolver – aunque no necesariamente esté bien diagnosticado.

En nuestra primer reunión hacemos un análisis preliminar, planteamos con claridad los problemas que podemos resolver, cuál podría ser el impacto, y los procesos, herramientas y recursos necesarios.

Si necesitan competencia y experiencia para resolver un problema real, seguimos hablando.

Si en cambio, buscan a alguien que ejecute ciegamente lo que ya decidieron —y que después se lleve la culpa para cuando no funciona—, para cuando llegan a nosotros ya hablaron con dos o tres agencias dispuestas a sacarse los ojos por agarrar el proyecto. Nosotros no competimos por ese lugar.

Si estás buscando un socio estratégico —si necesitás resultados en lugar de promesas y excusas—, con 30 minutos alcanza para saber si podemos trabajar juntos.

¡Escribinos y coordinemos agenda!

La entrada Diseñamos para cambiar comportamientos. se publicó primero en Kambrica.

Últimamente, muchas personas vienen están descubriendo —con cierto pánico– que la Ley Europea de Accesibilidad ya está por entrar en vigencia. Y de repente, se ven corriendo detrás de deadlines, tratando de “incorporar” accesibilidad a sus productos antes del 28 de junio.

Tal vez también lo hayan visto. Gente preocupada porque “ahora los sitios van a quedar todos iguales”, o porque “va a ser más difícil mantener la identidad de marca”. Como si la accesibilidad recién llegara – y nada menos que para arruinarles el diseño, que tan lindo les había quedado.

Es una reacción más común de lo que debería. Y es ahí donde se hace evidente: muchas de esas personas nunca estuvieron haciendo diseño UX.

Diseñaban pantallas. Interfaces. Look & feel. Cosas que su cliente aprobaba y pagaba. Pero no UX.

Porque no hay experiencia de usuario sin usuarios. Y eso siempre incluyó a todas las personas.

La deuda no es nueva. Es antigua. Y técnica.

El primer borrador de las WCAG (las pautas de accesibilidad para contenido web) es de 1999. Para la norma ISO 9241–210, que define formalmente la experiencia de usuario, un diseño que ignora la accesibilidad no puede considerarse que brinde una experiencia de usuario de calidad.

Esto no es una novedad. No es una moda. No es un nuevo desafío del diseño digital. Es una deuda profesional que muchas personas están descubriendo… ahora.

¿Cómo llegamos a esto?

Es buena parte, es el resultado de al menos 10 años de devaluación de la disciplina. Cuya última estación han sido los “cursos de UX” que omiten por completo la accesibilidad. Porque es “aburrida”. O sea que esos “cursos” no buscaban formar: buscaban entretener.

Escuelas piramidales en donde dan clase personas egresadas la semana anterior, sin haber tenido contacto con prácticas reales, proyectos complejos ni contextos diversos, sin poder transmitir lo que no conocen: experiencia, estándares, normas, historia, ni contexto.

Así, mucha gente fue llevada a creer que hacía UX… cuando en realidad hacía otra cosa. Y no es culpa de quienes quieren aprender. Es culpa de quienes se aprovecharon de su entusiasmo.

Mentoría para profesionales despiertos

Por suerte, cada vez más profesionales están despertando. Quieren hacer UX de verdad. Quieren entender qué significa diseñar para todos. Quieren mirar más allá de la pantalla.

Y eso es algo para celebrar.

Porque no se trata de cumplir con una norma, sino de diseñar con respeto, con criterio y con impacto real.

Muchos profesionales con experiencia estamos disponibles para ayudar, acompañar, enseñar, darles mentoría y ayudarles a resolver lo que sea que tengan entre manos. 

Y si están leyendo esto, es porque probablemente también estén entre quienes quieren hacer UX en serio. Entre quienes no están buscando atajos, sino profundidad.

Contar con el apoyo de más de 20 años de experiencia en accesibilidad, está a un clic de distancia.

La entrada Si alguien recién está descubriendo la accesibilidad, no estaba haciendo UX. se publicó primero en Kambrica.