←
Más deprisa que nunca: los fundamentos científicos del agile en la era de la IA

4 · Construir lo correcto15 min read

Teoría — Construir lo correcto: el producto como ciencia experimental

La estantería de trofeos de Aurelia — cuarenta y una pantallas muertas, un cuadro de mando con cuatro usuarios — no es una anomalía de empresa mal llevada. Es el estado normal del software construido sin contrastar hipótesis, y está medido. Esta sección presenta la evidencia central (una cifra que debería estar tatuada en cada sala de roadmap), el método que se deriva de ella, y las trampas — psicológicas y comerciales — que hay en el camino. Es, en cierto modo, la sección más «de negocio» del curso, y por eso mismo de las más importantes para un developer: construir rápido lo incorrecto es la forma más cara de perder el tiempo que existe.

1. El dato: dos de cada tres ideas no funcionan

Ronny Kohavi dirigió durante años la plataforma de experimentación de Microsoft (antes trabajó en Amazon; después en Airbnb), donde las ideas de producto se evaluaban con experimentos controlados online — la versión industrial del RCT: a una parte de los usuarios se les muestra el cambio, a otra no, y se mide la diferencia en las métricas que el cambio pretendía mover. Su informe "Online Experimentation at Microsoft" (2009, público en PDF) contiene el párrafo que Nadia encontró citado en el Cuaderno:

"The literature is filled with reports that success rates of ideas in the software industry, when scientifically evaluated through controlled experiments, are below 50%. Our experience at Microsoft is no different: only about 1/3 of ideas improve the metrics they were designed to improve." [traducción propia] «La literatura está llena de informes de que las tasas de éxito de las ideas en la industria del software, cuando se evalúan científicamente mediante experimentos controlados, están por debajo del 50%. Nuestra experiencia en Microsoft no es distinta: solo en torno a 1/3 de las ideas mejoran las métricas que estaban diseñadas para mejorar.»

Y la regla de reparto que el propio Kohavi divulga: un tercio mejora, un tercio no hace nada, un tercio empeora. En dominios ya optimizados (el buscador Bing), los ganadores caen al 10-20%. Cifras del mismo orden se han reportado en Booking.com, Netflix y Airbnb (donde ~92% de 250 ideas testadas no movieron las métricas).

Detengámonos en lo que esto significa, porque es fácil leerlo por encima. Estas no eran ideas de becario: eran ideas de profesionales de élite, filtradas por comités, priorizadas en roadmaps, defendidas por gente cuyo trabajo es saber qué quieren los usuarios. Y aun así, la opinión experta acierta una de cada tres veces. La conclusión no es «la gente de producto es mala»: es que en dominios complejos (sección 2) nadie puede saber a priori qué funcionará, porque la información necesaria no existe hasta que la realidad responde. La estimación honesta del valor de una feature no verificada no es «lo que dice el business case»: es una lotería con dos boletos perdedores de cada tres.

Estado de la evidencia: dato industrial, no académico en sentido estricto — pero sobre decenas de miles de experimentos, replicado entre compañías, y publicado con detalle metodológico. De lo más sólido que citarás en una reunión.

2. La respuesta: hipótesis que pueden fallar

Si no se puede saber a priori, la única estrategia racional es la del científico: formular la creencia como hipótesis falsable, diseñar la prueba más barata capaz de refutarla, y decidir con el resultado. Esto suena a eslogan de Lean Startup — enseguida vamos ahí — pero tiene algo mejor que un eslogan: un ensayo controlado aleatorizado que lo valida.

Camuffo, Cordova, Gambardella y Spina (2020, Management Science, 66(2)) hicieron algo infrecuente en management: un RCT de verdad. Ciento dieciséis startups italianas, asignadas al azar a dos formaciones idénticas en contenido (lean startup, customer development) con una diferencia: al grupo de tratamiento se le enseñó a operar como científicos — formular hipótesis explícitas, definir antes el criterio de éxito, testar con rigor, decidir según la evidencia. Resultados tras un año: los emprendedores «científicos» ingresaron más, pivotaron más a menudo hacia ideas distintas, y abandonaron antes las malas ideas — menos falsos positivos (perseverar en lo muerto) y menos falsos negativos (abandonar lo prometedor). Y en 2024 llegó lo que casi nunca llega: la réplica preregistrada a gran escala (Camuffo et al., Strategic Management Journal, 4 RCTs, 759 empresas), que confirmó el efecto sobre la terminación de malas ideas y afinó el de los pivotes: los tratados hacen pocos pivotes — ni cero (aferrarse) ni muchos (bandazos improductivos).

Fíjate en qué valida exactamente el experimento, porque es sutil: no valida «iterar» ni «sacar un MVP». El grupo de control también iteraba. Lo que marca la diferencia es la disciplina epistémica: hipótesis formulada antes, criterio de éxito definido antes, y — la navaja de Popper de la sección 0.2 — la posibilidad real de que el resultado te diga que no. Una hipótesis útil tiene esta forma:

Creemos que [hacer X] para [estas personas] producirá [este cambio de comportamiento medible]. Sabremos que es falsa si [métrica] no alcanza [umbral] en [plazo].

La última frase es la que separa el método de la superstición. El experimento de los resúmenes semanales de Aurelia funcionó porque la condición de fallo estaba escrita antes de recoger el primer dato: si Marga y el equipo hubieran mirado primero los resultados y decidido después qué significaban, habrían encontrado — la mente humana es generosísima para esto — una lectura en la que la feature «en el fondo validaba».

3. Lean Startup: lo que aporta y lo que la crítica académica corrige

Eric Ries (The Lean Startup, 2011) y Steve Blank (customer development: «get out of the building») popularizaron el vocabulario que casi todo el mundo usa hoy: MVP (producto mínimo viable: la versión más pequeña capaz de producir aprendizaje validado), build-measure-learn, pivotar (cambiar de estrategia conservando lo aprendido). El mérito divulgativo es enorme; la letra pequeña es que los libros no aportan evidencia experimental propia — son síntesis de práctica — y que la crítica académica seria les ha encontrado un fallo estructural.

Felin, Gambardella, Stern y Zenger (2020, Long Range Planning, "Lean startup and the business model: Experimentation revisited") argumentan: la experimentación sin teoría produce optimización local. Si solo testas lo fácilmente testable — variantes pequeñas, feedback inmediato — convergerás hacia mejoras incrementales y te perderás las apuestas que requieren componer una teoría nueva del negocio (su ejemplo conceptual: ningún test de pasillo de 2007 «validaba» el iPhone; hacía falta una teoría sobre lo que la gente aún no sabía querer). El propio RCT de Camuffo es coherente con esto: lo que funcionó no fue «experimentar mucho», sino experimentar desde hipótesis pensadas — teoría y prueba, no prueba sola.

La síntesis para practicantes: el experimento no sustituye al pensamiento; lo disciplina. Primero una tesis de producto con sustancia (¿qué creemos sobre estas personas y su problema que otros no ven?); después, la batería de pruebas más barata que pueda derribarla.

4. Lo que la gente dice y lo que la gente hace

El experimento de Renata evitó la trampa más vieja de la investigación de usuarios, y la ciencia detrás merece contarse porque es a la vez sólida y contraintuitiva.

El clásico fundacional es LaPiere (1934, Social Forces): viajó dos años por Estados Unidos con un matrimonio chino, en plena época de discriminación abierta; de 251 hoteles y restaurantes visitados, solo uno les negó el servicio. Seis meses después escribió a los mismos establecimientos preguntando si aceptarían clientes chinos: ~92% de los que respondieron dijo que no. La conducta real y la actitud declarada, en contradicción frontal. El estudio tiene defectos serios (respondió la mitad, quizá otra persona que la que atendió), y la lectura moderna es más fina que «las encuestas no sirven»: el meta-análisis de Kraus (1995) sitúa la correlación actitud-conducta en r≈0,38, y el principio de compatibilidad (Ajzen y Fishbein) precisa la condición: las actitudes predicen conducta cuando se miden con la misma especificidad que la conducta. «¿Le gustaría un resumen semanal?» (general, hipotético, gratis de responder) no predice casi nada; «¿qué hizo usted el martes cuando quiso saber de su padre?» (específico, conductual, pasado) predice mucho.

Y cuando hay dinero por medio, el sesgo tiene nombre y meta-análisis: hypothetical bias. Lo que la gente dice que pagaría excede sistemáticamente lo que paga: factor mediano ≈3 en List y Gallet (2001, 29 estudios); ≈1,35 en Murphy et al. (2005, con protocolos más cuidados); ~21% de inflación media en consumo (Schmidt y Bijmolt, 2019). Que tres meta-análisis den magnitudes tan distintas es en sí una lección — el sesgo depende fuertemente del protocolo — pero el signo jamás cambia. Regla de ingeniería: toda declaración de intención de pago se divide, como mínimo, entre 1,5; la única validación fuerte es el compromiso real (preventa, piloto con contrato, tarjeta introducida).

De aquí salen las reglas de las entrevistas modernas que Renata aplicó: preguntar por comportamiento pasado específico, no por intenciones; observar antes que preguntar; y cuando se pueda, medir conducta real con el artefacto más barato posible — la puerta pintada (el botón de lo que no existe) es el ejemplo canónico, con su servidumbre ética: usarse con moderación, revelando pronto y compensando la curiosidad del usuario con algo («apúntate y te avisamos»).

5. La fábrica de features, con nombre y síntomas

El estado organizativo del que Aurelia está saliendo tiene diagnóstico publicado. Melissa Perri lo llamó build trap ("The Build Trap", 2014, y el libro Escaping the Build Trap): la organización que mide su éxito por outputs (features entregadas) en lugar de outcomes (cambios de comportamiento del usuario que mueven el negocio). Su frase seca: «Construir es la parte fácil del proceso de desarrollo de producto. Averiguar qué construir es la difícil». John Cutler («12 Signs You're Working in a Feature Factory», 2016) publicó la lista de síntomas que medio sector se descubrió recitando: no se mide el impacto de lo entregado; teatro del éxito alrededor del «shipping»; casi nunca se descarta trabajo (señal de que no hay experimentos de verdad: recuerda el tercio-tercio-tercio — si nada «sale que no», nada se está poniendo a prueba); los roadmaps listan features, no problemas u outcomes; equipos barajados constantemente; cultura de hand-offs.

Ambos son divulgación experta — practicantes serios, sin datos sistemáticos propios, y así se citan — pero encajan con precisión sobre la evidencia de esta sección: una fábrica de features es una organización que compra billetes de lotería (⅓-⅓-⅓) a precio de apuesta segura y jamás comprueba los números.

La corrección conceptual es el vocabulario output → outcome → impact (la formulación más citada es la de Josh Seiden: un outcome es «un cambio en el comportamiento humano que produce resultados de negocio»): la feature (output) solo es valiosa si cambia lo que alguien hace (outcome: las auxiliares registran las incidencias en el momento; las familias entran dos veces por semana y se quedan tranquilas), y ese cambio solo importa si mueve algo que el negocio necesita (impact: renovación, menos churn). Nótese que esto corrige incluso al Manifiesto Ágil: «software funcionando como medida principal de progreso» fue un avance enorme contra el teatro de documentos de 2001 — y hoy es insuficiente, porque software funcionando que nadie usa es desperdicio con tests en verde. La medida de progreso madura es el outcome.

Sobre roadmaps: el formato Now / Next / Later (Janna Bastow, 2012 — divulgación con producto que vender, dicho queda) sustituye la línea temporal de promesas por tres horizontes de confianza decreciente: lo que está en curso y validado; los problemas en validación; las apuestas estratégicas. Su base real es todo lo anterior más la sección 2: un roadmap de features con fechas a doce meses es un catálogo encuadernado de falacias de planificación multiplicadas por dos tercios de tasa de fallo. Y hay un hallazgo serio que le da profundidad: Gartenberg, Prat y Serafeim (2019, Organization Science), con ~500.000 encuestas de empleados, encontraron que el «propósito» corporativo agregado no se asocia con el rendimiento financiero — solo lo hace la combinación propósito + claridad, y conducida por las percepciones de los mandos intermedios. Traducido: los pósters no predicen nada; que la capa que prioriza a diario tenga claro el porqué, sí. Un roadmap por outcomes es, exactamente, un artefacto de claridad para esa capa.

6. El mito del 64%: una lección de higiene dentro del propio bando

Y ahora, la vacuna prometida en la sección 0.2, aplicada a nuestro propio argumento. Durante veinte años, la comunidad agile ha citado que «el 64% de las features nunca o casi nunca se usan», con origen en una keynote de Jim Johnson (Standish Group) en la conferencia XP2002. Mike Cohn rastreó el dato: procedía de cuatro aplicaciones — internas, ninguna comercial — y la metodología jamás se publicó. Su veredicto textual: «si estás citando este dato para implicar que todo producto contiene un 64% de features que rara vez se usan, por favor, para». El informe moderno que se cita como sustituto (Pendo, 2019: «el 80% de las features rara vez o nunca se usan») es marketing de un vendor de analytics — muestra sesgada, definiciones propias, incentivo comercial — utilizable como indicio de orden de magnitud, no como dato.

¿Significa esto que el desperdicio de features es un mito? No: significa que no existe un porcentaje universal establecido — y que no hace falta. La telemetría de tu producto (el script de Nadia costó una tarde) responde la pregunta para el único caso que te importa, y el ⅓-⅓-⅓ de Kohavi, que sí está bien fundado, basta para justificar todo el método. Usar el 64% como pregunta («¿cuánto de lo nuestro se usa? midámoslo») es sano; usarlo como dato es exactamente el vicio que este curso combate — también cuando el dato favorece nuestra tesis. Especialmente cuando favorece nuestra tesis.

7. Discovery continuo: la práctica que el agile presuponía y nunca especificó

El Manifiesto habla de «colaboración con el cliente», pero no dice cómo. El hueco lo ha llenado la disciplina moderna de product discovery — el trabajo continuo y paralelo a la entrega para averiguar qué merece construirse. Sus articulaciones más difundidas son divulgación experta, y así las presentamos: Teresa Torres (Continuous Discovery Habits; el opportunity solution tree: outcome deseado → oportunidades detectadas en la investigación → soluciones candidatas → tests de supuestos; entrevistas semanales del trío producto-diseño-ingeniería) y Marty Cagan (SVPG: la distinción entre feature teams, que reciben listas de features y se miden por output, y empowered product teams, que reciben problemas y se miden por outcomes; su test de fuego: «el equipo puede decidir la mejor manera de resolver los problemas que se le han asignado»).

Ninguno de los dos publica datos; lo que les da peso es que cada pieza de su andamiaje se apoya en evidencia que este curso cubre: el contacto directo del equipo con usuarios reales tiene detrás los experimentos de Grant (sección 4: conocer al beneficiario multiplicó el rendimiento); la autonomía sobre el «cómo» tiene detrás la autodeterminación (sección 4) y la sociotécnica (sección 1); trabajar por outcomes claros conecta con la teoría de metas (sección 8) y con Gartenberg. Divulgación bien anclada es la mejor divulgación posible — y el criterio para distinguirla de la charlatanería es precisamente ese anclaje.

Para llevar

  • Solo ~⅓ de las ideas mejora las métricas que pretendía mejorar; ⅓ no hace nada; ⅓ empeora (Kohavi, decenas de miles de experimentos). La opinión experta no escapa a la cifra: un roadmap sin experimentos es una cartera de lotería.
  • Operar como científico funciona y está validado con RCT + réplica en 875 empresas (Camuffo et al.): hipótesis explícitas y criterio de éxito definido antes → más ingresos, mejores pivotes, abandono más rápido de las malas ideas.
  • La experimentación necesita teoría (Felin et al.): sin una tesis de producto con sustancia, los tests solo optimizan lo local. Primero pensar, luego derribar lo pensado con la prueba más barata.
  • Lo declarado no predice lo hecho salvo compatibilidad de especificidad (LaPiere → Kraus): pregunta por comportamiento pasado concreto, observa, y trata toda intención de pago como inflada (×1,35-3). El compromiso real es la única validación fuerte.
  • Outputs no son outcomes: la feature solo vale si cambia un comportamiento que mueve el negocio. «Software funcionando» fue la medida de 2001; la de hoy es el outcome. Y la claridad que predice resultados es la de los mandos intermedios que priorizan (Gartenberg), no la del póster.
  • El 64% es una cifra zombi (4 apps internas, metodología jamás publicada) y se deja de citar — la telemetría propia y el ⅓ de Kohavi bastan. El rigor se aplica también a los datos que dan la razón.

Para profundizar