Medir el muro
Artículo invitado por Santiago del Castillo
Santiago del Castillo trabaja conmigo; es product manager y tiene la habilidad de hacer que las cosas sucedan. Quien haya comenzado a trabajar sabe que, aunque esa habilidad suene básica, es realmente escasa en el mundo organizacional.
Hoy, en su artículo invitado, nos comparte el porqué.
Dos personas paradas frente a una pared. Su misión es saber qué tan alta es.
La primera dice: “Yo creo que mide 1.89 metros”. Y saca un argumento detrás de otro: que la altura promedio de las paredes en la región, que un benchmark con casas similares, que una correlación con la sombra que proyecta a las 3:30 p.m. durante los meses impares. Incluso llega a explicar la relación causal entre la altura del marco de la puerta y la edad de construcción de la pared. Todo hace sentido, la lógica es fuerte detrás de cada argumento y supuesto.
La segunda persona, a su vez, no se queda atrás. Cuestiona las suposiciones, pide ver las fuentes, señala los sesgos del método, se va por la tangente con posibles edge cases: ¿y si la base de la pared está un poco enterrada? ¿Y si la pared no es perfectamente vertical? ¿Y si medimos mal porque no definimos desde dónde empieza y termina la pared?
Ambos están siendo brillantes. Rigurosos. Exhaustivos.
Hasta que alguien llega, pone un metro contra la pared y dice:
—Mide dos metros
Esa escena, aunque hiperbólica y exagerada, me ha estado rondando la cabeza últimamente. Y no porque crea que el trabajo de producto debe hacerse sin reflexión —todo lo contrario—, pero a veces me pregunto: ¿cuántas veces nos quedamos atrapados en ese ciclo infinito de querer tener todas las respuestas antes de actuar? ¿Cuánto valor agrega la siguiente iteración del documento, del análisis, del diseño? ¿Y cuándo ya cruzamos la línea hacia los rendimientos marginales decrecientes?
Nadie quiere lanzar algo mal hecho. La ingeniería es costosa, el tiempo del equipo es limitado, y la confianza de los usuarios cuesta construirla. Y mucho. Pero la parálisis también tiene un costo, y alto: la posibilidad de aprender con velocidad.
La verdad incómoda es que la mayoría de las ideas no van a funcionar, por más que haya un proceso riguroso detrás. En Airbnb, más del 90% de los A/B tests no generan impacto positivo. No porque la gente no sea buena, sino porque así es la naturaleza del producto digital: incierta, compleja y difícil de predecir. Por eso, a veces es mejor salir a validar en el mundo real que seguir perfeccionando modelos mentales en una sala de reuniones.
“Mmm... o sea, lo que estás diciendo es que no hagamos análisis, ni estrategia, ni validación con usuarios, ¿sino que simplemente lancemos algo y miremos qué pasa, con fe?”
Absolutamente no.
No estoy diciendo que hay que lanzar la primera idea que se nos ocurra. Si ni siquiera tenemos claro qué queremos resolver, o para qué siquiera queremos saber cuánto mide la pared, entonces sí: cualquier intento de “sacar el metro y medir la pared” va a ser inútil y costoso. No se trata de hacer por hacer, ni de ignorar el UX, ni de perder el norte estratégico.
La reflexión es otra: ¿cuándo es suficiente? ¿Dónde termina el análisis que informa y empieza el análisis que paraliza? ¿Cuándo es oportuno darse cuenta de que el siguiente debate no es un paso hacia la claridad, sino un círculo que solo retrasa lo inevitable: lanzar, ver qué pasa, aprender y ajustar?
Recientemente escuché una entrevista al CPO de Uber en el podcast de Lenny Rachitsky, en la que dijo:
“You don't ship documents. You don't ship brainstorming meetings. You don't even ship designs in Figma. What you ship is code in your product. That is the only thing that actually ultimately has impact on your end user. You have to get them a solution as soon as possible. My biggest enemy is the cycle time from 'we know it is a good thing' to our user seeing it — you have to minimize that time.”
Y creo que tiene razón. Nadie allá afuera va a interactuar con nuestro Notion, ni con nuestros forecasts, ni con ese slide que explica con precisión quirúrgica por qué esta hipótesis tiene más sentido que la otra. Lo único que toca el mundo real es el código. La experiencia. El producto o feature que vamos a lanzar.
Y no, esto no significa que debamos dejar de hacer documentos, forecasts o diseños. Eso es clave para reducir la incertidumbre y tomar mejores decisiones. Pero sí es una invitación a preguntarnos con honestidad, ¿cambiar thereby por therefore en un documento va a transformar radicalmente la experiencia que vamos a lanzar al usuario? ó ¿incluir un escenario edge case adicional al google sheets nos va a llevar más cerca a la certidumbre financiera de algo que nunca hemos lanzado y tenemos que probar de todas formas?
No tengo la respuesta. Y creo que nadie la tiene, porque esto es y siempre será un ejercicio sin respuesta definitiva. Pero sí creo que vale la pena hacerse la pregunta:
¿Cuándo es hora de sacar el metro y medir?
PD: Gracias a Santiago otra vez por compartir sus ideas en Focus Time. Yo por mi lado sigo descansando por lo que la próxima semana no haré publicación. Espero escribir algo sobre el descanso al volver.
OOO || Recomendaciones y otros
Les recomiendo seguir a Santiago en LinkedIn es un gran product manager y hablar sobre producto y estrategia siempre me ayuda.
linkedin.com/in/santiago-del-castillo-suescun