Diseñar un Proceso a Prueba de un Product Owner que No Podía Sostenerlo

En un producto en el que trabajé, el puesto de product owner del cliente quedó vacante en medio de un roadmap activo. Alguien que ya era parte del equipo del cliente tuvo que tomar las riendas mientras buscaban un reemplazo adecuado, aunque no tenía el perfil que el rol necesitaba — y ese roadmap seguía siendo algo que teníamos que entregar.

Estábamos construyendo una feature de internacionalización donde los flujos, las validaciones y los campos de los formularios cambiaban según el país desde el que se registraba un usuario. Ese tipo de feature depende por completo de qué tan estructurada llega la información, y estructura era justo lo que no estábamos recibiendo. Teníamos un canal establecido para trackear requerimientos y vincularlos al roadmap en Notion, pero esta persona nunca lo adoptó. Lo que recibíamos en cambio era un flujo constante de documentos sueltos, y muchas veces esos documentos se completaban sobre la marcha, en la misma weekly donde necesitábamos la información. Pedíamos algo y nos llegaba incompleto, así que cada pedazo de scope venía con su propia ronda de perseguir respuestas.

Después de algunas semanas insistiendo con Notion sin lograr adopción real, dejamos de intentar cambiar su comportamiento y cambiamos nuestro proceso. Esa persona iba a seguir mandándonos documentos por Drive sin importar lo que pidiéramos, así que movimos nuestro propio tracking ahí. Esa decisión sola no arregló la calidad de la información, pero sacó una capa de fricción del medio. Dejamos de pelear por la herramienta. Pudimos concentrarnos en el problema real, que era lo desorganizado e incompleto que llegaba el contenido en sí.

Decidí que la solución real no era un mejor documento de proceso ni otra ronda de expectativas. Era sacarle la mayor cantidad de decisiones posible de encima. Armé un framework en Google Sheets brutalmente estructurado, con cada columna, fila, agrupación y hoja predefinida para los campos exactos que necesitaba la feature de internacionalización, país por país. En vez de pedirle que juntara y organizara información, le pedía que llenara un formulario que ya venía organizado. Su trabajo se redujo a marcar sí o no en ítems puntuales, señalar si existía o no una pieza de copy, y perseguir internamente a quien tuviera lo que todavía faltaba.

Entregamos la feature de internacionalización en tiempo y forma, bajo los mismos términos de contrato que habíamos comprometido antes de que empezara todo esto. La solución no fue capacitar a la persona, ni una conversación incómoda sobre performance. Fue rediseñar la interfaz entre esa persona y nosotros hasta dejar muy poco margen para equivocarse. Esa persona siguió siendo la responsable de la información. Nosotros dejamos de pedirle que también fuera responsable de la estructura.

No siempre puedes arreglar a la persona del otro lado de un contrato, y tampoco es tu trabajo hacerlo. Lo que sí puedes controlar es el margen de error del proceso que compartes con esa persona. Cuando alguien genuinamente no puede manejar una tarea de la forma en que fue diseñada originalmente, la respuesta no es explicar mejor el proceso. Es cambiar el proceso hasta que deje de depender de la habilidad que esa persona no tiene. Ese framework no fue ingeniería glamorosa, pero fue la pieza de trabajo que realmente permitió que la feature saliera.