Ideia principal

O product manager responde pela escolha de produto: por que este assunto, para qual público, com qual impacto esperado, em qual ordem. Os desenvolvedores respondem pela qualidade técnica do que entregam: o código, a base de código, o que vai para produção. Se a arbitragem de produto for ruim, o primeiro assume; se o código for frágil, pouco testado, mal compreendido ou difícil de manter, os segundos assumem.

Essas duas zonas conversam o tempo todo — um bom produto se constrói na troca entre escolha, viabilidade, uso e restrições técnicas —, e é aí que a confusão se instala. Como a decisão foi discutida, cada um pode se considerar parcialmente comprometido com a decisão do outro, e portanto inteiramente responsável por nenhuma.

O diálogo serve para instruir a decisão, não para dividi-la entre todos. Tratar os desenvolvedores como executantes e diluir a responsabilidade deles numa decisão coletiva são duas maneiras opostas de tirar deles a mesma coisa: a propriedade do que entregam.

Por que isso importa

Isso dá um teste aplicável diante de uma divergência: perguntar não quem participou da decisão, mas quem poderia tê-la bloqueado sozinho. A zona se lê nesse direito de veto, não na presença na reunião.

Isso também evita a leitura inversa, igualmente cara: zonas estanques em que o produto nunca discute a viabilidade e a técnica nunca discute o uso.

Nuances e limites

A fronteira nem sempre é nítida. Uma escolha de concepção técnica pode determinar um comportamento visível para o usuário, e uma arbitragem de produto pode impor uma dívida. O que conta então é saber qual das duas zonas decide, não fazer o assunto desaparecer.

E a divisão supõe que os desenvolvedores tenham de fato margem para arbitrar a própria qualidade — sem essa margem, a responsabilidade é atribuída a eles sem ter sido dada.

Questões em aberto

• Quem decide quando uma arbitragem de produto só pode ser cumprida ao preço de uma dívida técnica que o time recusa?