Cajas negras
En la primera sesión de la sexta edición del programa de dirección de producto del Instituto Tramontana nos enfrentamos a algo que suele pasarse por alto: la naturaleza del software como información. Es un terreno incómodo. Obliga a moverse con incertidumbre, a aceptar que siempre hay cosas que no vemos, y a desarrollar formas de pensar que nos ayuden a fallar menos.
Sin entender correctamente el papel determinante del software es fácil caer en errores comunes que lastran toda nuestra actividad. He escrito antes sobre por qué son tan difíciles los productos basados en software: la información no es conocimiento, siempre hay información invisible, la información no es plana, y está relacionada con contextos que cambian constantemente.
Lo que no podemos ver
Los productos basados en software tienen muchas similitudes con eso que en otros ámbitos se conoce como "cajas negras". En psicología, la caja negra es una metáfora para designar aquello que está entre la entrada y la salida, entre el estímulo y la respuesta. Es todo lo que no es observable, o que al menos no lo es de forma habitual o poco costosa.
Podemos llevarnos la idea a nuestro terreno. También nosotros construimos productos que son, en cierto sentido, conjuntos de estímulos y respuestas. De ellos podríamos tener noticia a través de las señales que emiten. Pero hay mucho que permanece oculto.
El pensamiento de producto digital, al apoyarse sobre este terreno, debe favorecer las conexiones sistémicas. Tanto a nivel operativo —diagramas, flujos, representaciones gráficas— como a nivel expositivo: argumentos donde se intentan relacionar las partes para explicar el conjunto.
La irrupción de los LLMs y la inteligencia artificial generativa no hace sino reforzar esta perspectiva. Estamos ante la caja negra llevada al extremo: ni siquiera quienes construyen estos sistemas pueden explicar con precisión qué ocurre entre la entrada y la salida. El modelo aprende patrones que escapan a la inspección directa. La opacidad ya no es una limitación práctica —no tenemos tiempo o recursos para observar—, sino constitutiva. No hay forma de abrir esa caja.
Esto nos obliga a repensar muchas cosas. Cómo evaluamos lo que funciona. Cómo establecemos confianza. Cómo convivimos con sistemas que producen resultados útiles sin que podamos trazar el camino que los genera. Las habilidades que desarrollamos para trabajar con información precaria —representar problemas, explicitar asunciones, resistir la tentación de certezas prematuras— se vuelven más necesarias que nunca.
Dos esquemas para pensar
Hay dos esquemas sistémicos que son dominantes en las decisiones sobre producto digital.
Por un lado, el esquema entrada → salida. Conviene tenerlo siempre interiorizado, para aplicarlo a cualquier situación en la que estás tomando una decisión. En el software es especialmente rico porque la entrada suele ser donde está tu actividad y la salida es un terreno que abarca la experiencia en su sentido más amplio. Pensar en términos de tipos de datos se convierte en un factor decisivo.
Es muy recomendable acudir a todo lo que rodea a la filosofía Unix para entender la potencia de este esquema. Hacer una cosa y hacerla bien. Componer piezas pequeñas. Preferir el texto plano.
Por otro lado, el esquema cliente ↔ servidor. Sus implicaciones se propagan por toda la red, y la naturaleza de las distintas piezas que participan en cada extremo determina muchas de nuestras decisiones. Es recomendable tener en cuenta los movimientos alrededor de las APIs para entender la potencia de las conexiones. Entender piezas protagonistas, como el navegador, se convierte en determinante.
Las cosas en digital se ponen interesantes cuando los extremos de ambos esquemas se confunden y en la conexión de unas cosas con otras se intercambian los papeles.
No engañarse demasiado
Siempre con la prudencia de no aplicarlas ciegamente, hay algunas reglas que resultan útiles cuando nos enfrentamos a problemas de información:
- Regla de la optimización: primero prototipa y luego pule; no optimices nada antes de tenerlo funcionando.
- Regla de claridad: la claridad siempre es preferible a su ausencia.
- Regla de simplicidad: empieza con lo simple, añade complejidad solo cuando sea necesario.
- Regla del silencio: si no tienes nada que decir, cállate.
El primer paso para fallar menos es mirar los problemas como un conjunto de posibles alternativas. Nunca como un conjunto de un solo elemento. Representar el espacio del problema, explicitar nuestras asunciones, resistir la tentación de tener ya el problema resuelto antes de empezar.
Las limitaciones con las que trabajamos nos obligan a trabajar siempre con compromisos y sacrificios. Asumirlos, listarlos, acordarlos con el equipo. Y formar equipos cuyo tamaño se corresponda con la participación, con autonomía suficiente para hacer avanzar las soluciones, y con comunicación constante para reducir los deltas de información cambiante.
El hábito es no engañarnos demasiado. Vivir con información precaria.
Práctica de la sesión
Caso: AWS y nuestro conocimiento de los sistemas. Analizamos en parejas el incidente de DynamoDB en la región US-EAST-1 de octubre de 2025. El ejercicio consistía en navegar fuentes (comunicados de AWS, noticias, foros técnicos), identificar las capas del problema, y redactar una explicación plana del fallo junto con un diagrama del circuito de piezas involucradas. Un ejercicio de articular opiniones a partir de información precaria.
Ejercicio en sesión: Señales en atención al cliente. A partir de tickets reales sobre problemas con descargas, clasificar los componentes del problema en una matriz de opuestos: visible vs. no visible, información vs. conocimiento, dinámico vs. estático, plano vs. multicapa.
Para casa: Dos ejercicios. Caza anécdotas: capturar situaciones cotidianas que ilustren los temas de la sesión. ¿Cómo funciona?: escoger una pieza de un producto digital y documentar sus internals —cómo te imaginas que funciona, analizado desde los modelos entrada → salida y cliente ↔ servidor.