Idea principal

El Product Manager responde de la elección de producto: por qué este tema, para qué objetivo, con qué impacto esperado, en qué orden. Los desarrolladores responden de la calidad técnica de lo que entregan: el código, la base de código, lo que sale a producción. Si el arbitraje de producto es malo, el primero lo asume; si el código es frágil, poco probado, mal entendido o difícil de mantener, lo asumen los segundos.

Estas dos zonas se hablan permanentemente —un buen producto se construye en el intercambio entre elección, viabilidad, uso y restricciones técnicas—, y es ahí donde se instala la confusión. Porque la decisión se ha discutido, cada uno puede considerarse parcialmente comprometido por la del otro, y por tanto enteramente responsable de ninguna.

El diálogo sirve para instruir la decisión, no para mutualizarla. Tratar a los desarrolladores como ejecutores y diluir su responsabilidad en una decisión colectiva son dos maneras opuestas de quitarles lo mismo: la propiedad de lo que entregan.

Por qué es importante

Esto da una prueba practicable ante una discrepancia: preguntar no quién participó en la decisión, sino quién podría haberla bloqueado por sí solo. La zona se lee en ese derecho de veto, no en la presencia en la reunión.

Evita también la lectura inversa, igual de costosa: zonas estancas donde producto nunca discute la viabilidad y técnica nunca el uso.

Matices y límites

La frontera no siempre es nítida. Una elección de diseño técnico puede determinar un comportamiento visible para el usuario, y un arbitraje de producto puede imponer una deuda. Lo que importa entonces es saber cuál de las dos zonas decide, no hacer desaparecer el tema.

Y el reparto supone que los desarrolladores dispongan realmente del margen para arbitrar su propia calidad: sin ese margen, la responsabilidad se les atribuye sin habérsela dado.

Preguntas abiertas

• ¿Quién decide cuando un arbitraje de producto solo puede cumplirse al precio de una deuda técnica que el equipo rechaza?