
En un momento donde se habla tanto de modelos de IA, de prompts y de LLMs, se habla poco del trabajo silencioso que hay detrás. El etiquetado, el análisis cualitativo, la validación cruzada. Esa parte, la menos glamurosa, es la que realmente marca la diferencia entre un sistema que parece listo y uno que lo está. Este post va de eso: de cómo llegar a las causas raíz de los errores puede transformar el rumbo de un producto, y de por qué vale la pena invertir horas en entender, no solo en medir.
El otro día me bajé de PostHog un listado de más de 3.000 eventos. Todos tenían algo en común: eran casos en los que nuestro producto no había acertado. Para dar contexto: estamos desarrollando un sistema que autorrellena automáticamente cientos de campos. Nuestro éxito se mide en aciertos. Si acertamos, genial. Pero si no, tenemos que entender por qué. Así que me senté con un té delante del ordenador y, uno a uno, fui pacientemente categorizando manualmente la causa raíz de cada error.
Podría haberme conformado con un análisis superficial: agrupar por campo, hacer una tabla y lanzar hipótesis. Pero ese enfoque se queda corto. Solo cuando te ensucias las manos con los datos, cuando los recorres línea a línea y empiezas a identificar patrones causales, aparece la verdad. Entender los errores exige ir más allá del dato bruto: requiere interpretación, criterio, paciencia. Y sí, muchas horas. Pero de ese trabajo manual, salió una visión profunda y estructurada de dónde teníamos cuellos de botella, errores de diseño, problemas de datos o casos de uso no contemplados.
Este tipo de análisis no debería recaer en una sola persona o rol. Los errores tienen múltiples dimensiones, y entenderlos y solucionarlos bien requiere colaboración entre perfiles distintos: producto, ingeniería, diseño, datos, negocio, atención al cliente. Porque lo que para una persona puede parecer irrelevante, para otra es un síntoma claro de un problema más profundo. Ir a la causa raíz también es una forma de democratizar el entendimiento de lo que pasa con un producto.
Así que sí, fueron muchas horas frente a una hoja de cálculo. Pero fue un tiempo bien invertido. Mirar los datos es importante. Entenderlos, aún más. Y llegar hasta la raíz, aunque sea costoso, es lo que marca la diferencia entre iterar a ciegas o construir con propósito.
También puede interesarte

40 clics para pagar dos horas de aparcamiento
Un parquímetro me ha recordado por qué contar los clics y los segundos que le cuesta a tu usuario completar una tarea es clave al diseñar un producto.

5 comportamientos que definen a un Product Engineer
La IA hace que programar sea rápido. El reto que queda es entender el problema, plantear una buena arquitectura y fasear con criterio.
