Idea principal

El desarrollo ya ha resuelto, bajo el nombre de Domain-Driven Design, la cuestión de cómo aislar un perímetro, qué contiene y cómo entra en él una información procedente de otro perímetro. Organizar el estudio de una oportunidad de producto retomando ese mismo troceado — un espacio acotado, sus reglas, su verdad local — no es una analogía decorativa: es emplear el mismo concepto a ambos lados.

Lo que eso elimina es una capa de abstracción intermedia. Cuando el producto trocea por temática y la ingeniería por ámbito, cada paso de un lado a otro exige una conversión, y cada conversión tuerce un poco los conceptos: lo que el Product Manager llama funcionalidad abarca tres ámbitos, lo que el equipo llama ámbito atraviesa dos oportunidades. Nadie comete el error a propósito; nace del desalineamiento de los troceados.

Compartir el troceado hace inútiles esas conversiones. La discusión pasa entonces a versar sobre el contenido en vez de sobre la correspondencia entre dos maneras de ordenar el mismo producto.

Por qué es importante

Esto da un criterio de elección para los métodos de producto que no depende de su calidad intrínseca: a igual valor, el método que comparte su vocabulario con la ingeniería sale más barato en el uso, porque no tiene gastos de traducción.

Desplaza también un debate recurrente sobre el nivel técnico que se espera de un Product Manager: lo que está en juego no es saber programar, es trocear el trabajo de la misma manera.

Matices y límites

No todos los conceptos del desarrollo se transponen. El producto trabaja sobre apuestas e hipótesis, que el código desconoce: tomar prestado un troceado no significa tomar prestado un método entero.

Y alinear los troceados tiene un coste propio: el troceado técnico no es neutro, y adoptarlo del lado del producto equivale a heredar sus decisiones de arquitectura.

Preguntas abiertas

• ¿Qué conceptos de producto no tienen equivalente alguno del lado del desarrollo, y cómo hacerlos vivir dentro de un troceado prestado?