Idea principale

Una schermata di consultazione, un export, una dashboard, uno strumento di interrogazione montato da un team di prodotto stanno accanto al prodotto: consumano API, aggregano informazioni e producono un'interfaccia utile a chi l'ha fatta o al suo team. Quando si rompono, danneggiano solo se stessi.

Un modulo, un percorso o una variante funzionale costruiti sulla codebase dell'azienda stanno nel suo prolungamento. Riusano i blocchi esistenti, il linguaggio di business del codice, i componenti interni — e finiscono nello stesso repository, con le stesse dipendenze e gli stessi clienti in fondo alla catena. Quando si rompono, rompono il prodotto.

La distinzione non è una differenza di dimensioni né di ambizione: è una differenza di superficie d'impatto, ed è questa che dovrebbe decidere il regime di esigenza, non il fatto che alla tastiera ci sia un profilo di prodotto o uno sviluppatore.

Perché è importante

Dà un criterio operativo là dove la discussione di solito resta sul livello della persona. «Accanto» o «nel prolungamento» si constata guardando dove finisce il codice e chi ne dipende; «abbastanza competente» non si constata.

Delinea anche due traiettorie distinte e non equivalenti: alleggerire gli sviluppatori dei piccoli strumenti interni è un obiettivo modesto e raggiungibile; permettere a profili di prodotto di contribuire al prodotto stesso è un altro discorso, con altre condizioni.

Sfumature e limiti

Il confine non è netto. Uno strumento costruito accanto che scrive nel database di produzione ha la superficie d'impatto di un oggetto del prolungamento, ovunque si trovi nel repository.

E lo scarto di rischio non dice nulla dello scarto di valore: l'oggetto più utile non è sempre quello che tocca il prodotto.

Domande aperte

• Fin dove un'organizzazione può lasciare che profili di prodotto costruiscano nel prolungamento del prodotto senza perdere il controllo tecnico, la coerenza e la sicurezza dell'insieme?