Ideia principal

Uma tela de consulta, uma exportação, um painel, um construtor de consultas montado por um time de produto ficam ao lado do produto: eles consomem APIs, agregam informação e produzem uma interface útil para quem a fez ou para o time dessa pessoa. O que eles quebram, ao quebrar, são eles mesmos.

Um módulo, uma jornada ou uma variação funcional construídos sobre a codebase da empresa ficam no prolongamento dele. Eles reutilizam os blocos existentes, a linguagem de negócio do código, os componentes da casa — e entram no mesmo repositório, com as mesmas dependências e os mesmos clientes na ponta. O que eles quebram, ao quebrar, é o produto.

A distinção não é uma diferença de tamanho nem de ambição: é uma diferença de superfície de impacto, e é ela que deveria decidir o regime de exigência, não o fato de um perfil de produto ou um desenvolvedor estar no teclado.

Por que isso importa

Isso dá um critério operacional onde a discussão costuma ficar no nível da pessoa. "Ao lado" ou "no prolongamento" se constata olhando onde o código aterrissa e quem depende dele; "competente o suficiente" não se constata.

Também desenha duas trajetórias distintas e não equivalentes: aliviar os desenvolvedores das pequenas ferramentas internas é um objetivo modesto e alcançável; permitir que perfis de produto contribuam para o produto em si é outro assunto, com outras condições.

Nuances e limites

A fronteira não é estanque. Uma ferramenta construída ao lado que escreve no banco de produção tem a superfície de impacto de um objeto do prolongamento, qualquer que seja a localização dela no repositório.

E a diferença de risco não diz nada sobre a diferença de valor: o objeto mais útil nem sempre é o que toca o produto.

Questões em aberto

• Até onde uma organização pode deixar perfis de produto construírem no prolongamento do produto sem perder o domínio técnico, a coerência e a segurança do conjunto?