Idea principale

Il Product Manager risponde della scelta di prodotto: perché questo argomento, per quale target, con quale impatto atteso, in quale ordine. Gli sviluppatori rispondono della qualità tecnica di ciò che consegnano: il codice, la codebase, ciò che va in produzione. Se la scelta di prodotto è sbagliata, se ne fa carico il primo; se il codice è fragile, poco testato, mal compreso o difficile da mantenere, se ne fanno carico i secondi.

Queste due zone dialogano di continuo — un buon prodotto si costruisce nello scambio fra scelte, fattibilità, uso e vincoli tecnici —, ed è lì che si insinua la confusione. Poiché la decisione è stata discussa, ciascuno può sentirsi in parte vincolato da quella dell'altro, e quindi pienamente responsabile di nessuna.

Il dialogo serve a preparare la decisione, non a metterla in comune. Trattare gli sviluppatori come esecutori e diluire la loro responsabilità in una decisione collettiva sono due modi opposti di togliere loro la stessa cosa: la proprietà di ciò che consegnano.

Perché è importante

Offre un test praticabile in caso di disaccordo: chiedere non chi ha partecipato alla decisione, ma chi avrebbe potuto bloccarla da solo. La zona si riconosce da questo diritto di veto, non dalla presenza in riunione.

Evita anche la lettura opposta, altrettanto costosa: zone stagne in cui il prodotto non discute mai la fattibilità e la tecnica mai l'uso.

Sfumature e limiti

Il confine non è sempre netto. Una scelta di progettazione tecnica può determinare un comportamento visibile all'utente, e una scelta di prodotto può imporre un debito. Ciò che conta allora è sapere quale delle due zone decide, non far sparire la questione.

E la ripartizione presuppone che gli sviluppatori abbiano davvero il margine per decidere della propria qualità — senza questo margine, la responsabilità viene loro attribuita senza che sia stata data.

Domande aperte

• Chi decide quando una scelta di prodotto si può mantenere solo al prezzo di un debito tecnico che il team rifiuta?