Ideia principal

O desenvolvimento já resolveu, sob o nome de Domain-Driven Design, a questão de como isolar um perímetro, o que ele contém, e como uma informação entra nele vinda de outro perímetro. Organizar o estudo de uma oportunidade de produto retomando essa mesma divisão — um espaço delimitado, suas regras, sua verdade local — não é uma analogia decorativa: é empregar o mesmo conceito dos dois lados.

O que isso elimina é uma camada de abstração intermediária. Quando o produto divide por temática e a engenharia por domínio, cada passagem de um lado para o outro exige uma conversão, e cada conversão torce um pouco os conceitos: o que o product manager chama de funcionalidade cobre três domínios, o que o time chama de domínio atravessa duas oportunidades. Ninguém comete o erro de propósito; ele nasce do desalinhamento das divisões.

Compartilhar a divisão torna essas conversões desnecessárias. A discussão passa a ser sobre o conteúdo, e não sobre a correspondência entre duas maneiras de arrumar o mesmo produto.

Por que isso importa

Isso dá um critério de escolha para os métodos de produto que não depende da qualidade intrínseca deles: a valor comparável, o método que compartilha seu vocabulário com a engenharia custa menos no uso, porque não tem despesa de tradução.

Isso também desloca um debate recorrente sobre o nível técnico esperado de um product manager: o que está em jogo não é saber programar, é dividir o trabalho da mesma maneira.

Nuances e limites

Nem todos os conceitos de desenvolvimento se transpõem. O produto trabalha com apostas e hipóteses, que o código não conhece: pegar emprestada uma divisão não quer dizer pegar emprestado um método inteiro.

E o alinhamento das divisões tem um custo próprio: a divisão técnica não é neutra, adotá-la do lado do produto equivale a herdar suas escolhas de arquitetura.

Questões em aberto

• Quais conceitos de produto não têm nenhum equivalente do lado do desenvolvimento, e como fazê-los viver numa divisão emprestada?