Bruce Mau y el producto: aprender antes de tener razón

Conocí el trabajo de Bruce Mau cuando estudiaba, hacia el año 2000. No fue una lectura de paso: hice un estudio bastante extenso de su obra y un análisis de An Incomplete Manifesto for Growth, que por entonces circulaba en su primera versión. Lo que más me atrapó fue su idea central: el crecimiento y la innovación no son algo que le pasa a uno, sino un proceso activo que exige explorar y experimentar de forma constante.

Encajaba con mi curiosidad. Era muy fan de Redes, el programa de Eduard Punset, y ese tipo de procesos era una inspiración para mí.

Después empecé a trabajar y choqué con la realidad. Mis primeros trabajos fueron en entornos muy industriales: una cartotécnica, publicidad muy centrada en el mundo del vino, agencias que dependían del dinero institucional. Había muy poco margen para explorar. El refugio estaba fuera: en proyectos personales, en trabajos como freelance e incluso en un juego indie que sacamos entre unos amigos. Ahí sí podía probar, equivocarme y volver a empezar.

Esa forma de trabajar fue la que, en un momento dado, me empujó hacia el entorno digital, con el que encajaba mucho más. Por entonces Lean y Agile empezaban a extenderse, y pude aplicarlos de verdad cuando entré a trabajar en 89bits, un estudio independiente de videojuegos. En un videojuego es difícil no dejar que los acontecimientos te cambien: juegas a lo que construyes casi cada día y lo que no funciona se nota enseguida.

Por eso el manifiesto sigue siendo uno de mis textos de cabecera. No habla del diseñador como decorador de soluciones ni de la creatividad como un rasgo místico. Habla de trabajo: de cómo moverse cuando todavía no se sabe exactamente qué se está haciendo.

Y eso lo conecta de forma bastante directa con mi manera de entender el producto. Notas, prototipos, ideas: no son pasos menores antes de que empiece el trabajo serio. Son el trabajo serio cuando el problema aún no está suficientemente comprendido.

«Allow events to change you.»

La frase abre el manifiesto y resume una disposición difícil: no basta con observar lo que ocurre; hay que permitir que lo observado altere el plan.

El manifiesto se publicó en 1998 y reúne 43 principios breves: dejar que los acontecimientos te cambien, olvidar lo «bueno», atender al proceso, amar los experimentos, capturar accidentes, estudiar, derivar, empezar en cualquier lugar, preguntar tonterías, colaborar. Mau lo planteó como una reflexión deliberadamente incompleta sobre cómo sostener una vida creativa. No es un manual de gestión ni una teoría de software. Pero leído desde producto describe, con otras palabras, algo que en esos mismos años se estaba convirtiendo en métodos, tableros, sprints, MVPs y bucles de aprendizaje.

Conviene no hacer de Mau el precursor de Lean o Agile: sería una genealogía bonita y falsa. Esa conversación llevaba tiempo en marcha en varios sitios a la vez. Toyota había construido su sistema de producción durante décadas y en 1988 John Krafcik le puso el nombre de lean. Scrum se presentó en 1995 y Extreme Programming se formalizó a finales de esa misma década. El Manifiesto Ágil llegó en 2001, Mary y Tom Poppendieck trasladaron lean al software en 2003 y Eric Ries popularizó el bucle construir-medir-aprender a partir de 2008.

En el diseño, la raíz más directa es anterior a todos ellos. En 1983 Donald Schön describió el trabajo del profesional como una «conversación reflexiva con la situación»: actúa, observa cómo responde el material y vuelve a actuar. Es la misma idea que Gabriela Goldschmidt aplicaría después al boceto. Mau escribe desde esa tradición, en paralelo a la ingeniería de software. Lo que comparten es más profundo que una secuencia de prácticas: la convicción de que la realidad no es un trámite posterior a la idea. Es el material con el que se piensa.

Un manifiesto para antes del backlog

En bastantes empresas, el proceso de producto empieza demasiado tarde. Se llama «descubrimiento» a validar una solución que ya llega decidida; se llama «estrategia» a una lista de funcionalidades; se llama «roadmap» a un compromiso con una hipótesis que todavía no ha tenido contacto suficiente con usuarios, tecnología o negocio.

Mau introduce una incomodidad básica: un proyecto no tiene por qué saber lo que va a ser para empezar a trabajarse. Lo que necesita es una dirección, una pregunta y un modo de dejarse corregir.

Una visión, en ese sentido, se parece menos a una imagen nítida del futuro que el equipo debe ejecutar obedientemente y más a una hipótesis fuerte sobre un cambio deseable. Puede incluir una ambición, un usuario, un problema y unos límites que no estamos dispuestos a cruzar. Pero la forma concreta de llegar ahí debe ganar detalle frente a la realidad.

En producto esto significa que antes del backlog deberían existir, al menos, tres cosas: una tensión que merece resolver, una apuesta sobre cómo crear valor y una incógnita real que necesitamos despejar. Si solo hay una lista de requisitos, no hay un problema: hay producción pendiente.

El manifiesto de Mau no permite refugiarse en la falsa seguridad de ese inventario. Nos devuelve a una pregunta menos cómoda: ¿qué tenemos que aprender para que esta decisión deje de ser una preferencia interna?

Mau, Lean y Agile: la misma conversación en idiomas distintos

Lean y Agile aportaron algo decisivo al desarrollo de producto: hicieron operativa la idea de aprender pronto. Entregas pequeñas, contacto frecuente con quien usa el producto, ciclos cortos, software funcionando y revisión continua. Frente a los planes que pretendían anticiparlo todo, propusieron reducir el tamaño de la apuesta y aumentar la frecuencia de la evidencia.

El bucle construir-medir-aprender formula esa misma intuición en lenguaje empresarial. No construyas durante un año para descubrir al final que la premisa era equivocada; crea el mínimo artefacto que te permita aprender algo relevante, mide una señal que tenga relación con el valor y decide si conviene persistir o corregir la dirección.

Mau lo dice de forma menos gerencial y, por eso, quizá más radical:

«Process is more important than outcome.»

No porque el resultado sea irrelevante (un producto tiene que servir a alguien, sostener un negocio y funcionar), sino porque cuando el resultado se decide del todo antes de empezar, el proceso se limita a fabricar una confirmación.

Bruce Mau	En Lean y Agile	En producto bien practicado
Dejar que los acontecimientos te cambien	Responder al cambio	Revisar una hipótesis cuando la evidencia contradice al equipo
El proceso importa más que el resultado	Construir-medir-aprender	Diseñar aprendizaje, no solo entregables
Amar los experimentos	MVP y ciclos cortos	Prototipar para reducir una incertidumbre concreta
Capturar accidentes	Observación y feedback	Tratar una anomalía como posible señal, no como simple ruido
Hacer preguntas estúpidas	Colaboración y transparencia	Desarmar supuestos que nadie ya sabe justificar
Estudiar e ir profundo	Comprensión del problema	No confundir datos disponibles con entendimiento

La tabla es útil si se lee con una precaución: ninguna metodología garantiza pensamiento. Se puede hacer Scrum de forma burocrática, hablar de MVP cuando en realidad se está recortando calidad o usar investigación de usuarios para legitimar una decisión que ya estaba tomada. Un tablero lleno de tickets no convierte a un equipo en adaptable. Igual que una pared con las frases de Mau no lo convierte en creativo.

La parte difícil está antes y después del método. Antes: tener una pregunta de verdad. Después: aceptar que la respuesta pueda obligarnos a cambiar algo importante.

«Olvida lo bueno» y no confundas exploración con descuido

«Forget about good» es la provocación más conocida de Mau y también la más fácil de malinterpretar. No quiere decir que haya que rebajar el estándar o celebrar el trabajo mediocre. Quiere decir que «lo bueno» suele ser aquello sobre lo que ya hay acuerdo: el patrón seguro, la interfaz que todos han visto, la respuesta que una reunión puede aprobar sin tensión.

En producto hay cosas que no deben quedar abiertas a la exploración: accesibilidad, seguridad, privacidad, estabilidad, claridad en una decisión clínica o financiera. No experimentas con el daño posible. Diseñas barreras, haces pruebas controladas y exiges rigor.

Pero hay otras preguntas que no se resuelven desde una sala de reuniones: qué hace que alguien entienda una métrica, qué parte de un flujo genera abandono, cuál es la unidad de valor por la que un cliente pagaría o qué comportamiento realmente ha cambiado. Ahí, mantenernos en lo que ya parece «bueno» puede ser una forma de no descubrir nada.

La práctica madura separa ambos terrenos. Protege lo que tiene que ser fiable y crea espacio para ensayar lo que todavía no se sabe.

Lo veo a diario en el producto en el que trabajo ahora, un software clínico que se rige por la normativa de producto sanitario. Cuando desarrollamos una prueba de evaluación cognitiva, el documento funcional es solo un punto de partida: el desarrollo lo corrige de forma iterativa, y la primera ronda de testeo interno sirve precisamente para que la experiencia funcione antes de que los evaluadores empiecen a recoger datos. Pero llega un momento en que ese documento deja de actualizarse. A partir de la recogida de datos y la normalización, lo que cambia ya no se explora: se documenta en el manual y en los archivos de datos, porque un resultado clínico tiene que poder reconstruirse. La exploración no desaparece; tiene una fase y una frontera, y saber dónde está esa frontera es parte del trabajo.

El prototipo no es una maqueta: es una pregunta hecha visible

Esta es la razón por la que me interesan tanto los prototipos. Para mí, un prototipo es un instrumento para hacer visible una pregunta, mucho más que una versión pequeña del producto final o una interfaz bonita para impresionar a alguien.

Un boceto puede preguntar si el modelo mental tiene sentido. Un flujo clicable puede preguntar si una persona encuentra la siguiente acción. Una prueba con datos falsos puede preguntar si la información se entiende. Una implementación limitada puede preguntar si una propuesta modifica un comportamiento real. Cada artefacto es válido si reduce una incertidumbre que importa.

Mau habla de empezar en cualquier lugar, de derivar y de capturar accidentes. Eso choca con la fantasía de que un proceso correcto siempre avanza en línea recta: investigación, definición, diseño, desarrollo, lanzamiento. La realidad se parece más a una conversación. A veces un detalle de interfaz revela que el problema estaba mal formulado. A veces una limitación técnica obliga a encontrar una solución más simple. A veces un usuario usa una funcionalidad de una forma no prevista y descubre una necesidad que nadie había nombrado.

El trabajo consiste en construir un equipo capaz de reconocerlo cuando ocurre, en lugar de intentar evitar que ocurra.

La IA cambia la velocidad, no la responsabilidad

La inteligencia artificial acelera de forma muy tangible esta filosofía de trabajo. Ahora podemos convertir una hipótesis en un flujo, una interfaz, una simulación, un texto o incluso una primera implementación en una fracción del tiempo que antes costaba. Se puede explorar más de una dirección, poner alternativas frente a usuarios antes, crear datos sintéticos para discutir un modelo o desmontar una idea sin haber invertido semanas de desarrollo.

Esto encaja especialmente bien con Mau. Si el camino aparece al trabajar sobre el material, la IA multiplica la cantidad de material sobre el que podemos trabajar. Hace mucho más barato empezar, comparar, desechar, corregir y volver a intentar. Reduce el coste de la primera versión de una idea.

Pero conviene no confundir cantidad de iteraciones con aprendizaje. Una IA puede generar diez variantes de una pantalla, cien copys o un prototipo funcional en una tarde. No puede determinar por sí sola si el problema era importante, si la señal observada tiene valor, si el usuario está entendiendo lo que hace o si la solución encaja con la responsabilidad de la empresa.

El riesgo contemporáneo es otro: producir simulacros de aprendizaje a una velocidad industrial. Muchas opciones, mucho movimiento y ninguna pregunta clara. Si antes el cuello de botella era construir, ahora cada vez lo será más decidir qué merece construirse y cómo interpretar lo que sucede después.

Usar IA para ir rápido estará al alcance de todos. La diferencia estará en las hipótesis, en los criterios y en cómo se lee lo que pasa después. La velocidad amplifica tanto un buen sistema de aprendizaje como uno lleno de ruido.

El profesional, el equipo y la organización que aprende

Mau no plantea una creatividad individualista. Insiste en colaborar, en estudiar, en compartir ideas y en asumir que cualquiera puede liderar en el momento en que tiene algo relevante que aportar. Eso también conversa mejor con la práctica de producto que con la caricatura del «visionario» que baja requisitos desde arriba.

Un buen producto rara vez es el resultado de una función aislada. Diseño detecta una incoherencia que cambia la pregunta. Desarrollo hace visible una restricción que obliga a simplificar. Atención al cliente escucha un patrón que no aparecía en los datos. Negocio recuerda que una solución brillante puede ser inviable. Datos diferencia entre una anécdota ruidosa y una señal persistente.

Tampoco hace falta democratizar cada decisión hasta hacerla imposible. Basta con que el proceso sea lo bastante poroso para que la realidad llegue al sitio donde se decide. Ahí está la diferencia entre colaboración y consenso vacío.

El propósito del proceso no es demostrar que teníamos razón desde el principio. Es aumentar la probabilidad de tenerla antes de que sea demasiado tarde.

---

Para seguir

• Bruce Mau Studio, An Incomplete Manifesto for Growth. Texto original y contexto de publicación.
• Koolhaas, R. y Mau, B. (1995). S,M,L,XL. The Monacelli Press.
• Mau, B. (2000). Life Style. Phaidon.
• Mau, B. y Institute without Boundaries (2004). Massive Change. Phaidon.
• Schön, D. A. (1983). The Reflective Practitioner: How Professionals Think in Action. Basic Books.
• Goldschmidt, G. (1991). The Dialectics of Sketching. Creativity Research Journal, 4(2), 123-143.
• Krafcik, J. F. (1988). Triumph of the Lean Production System. Sloan Management Review, 30(1), 41-52.
• Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
• Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley.
• Manifesto for Agile Software Development (2001).
• Poppendieck, M. y Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley.
• Ries, E. (2011). The Lean Startup. Crown Business. Resumen de principios en theleanstartup.com.