Idea principale

Tra l'intento e la produzione esiste una scala di gradini riconoscibili: restare al livello del mockup, produrre un prototipo manipolabile, costruire uno strumento interno o una dashboard usati davvero, aprire una pull request delimitata e supervisionata, portare un deliverable fino in produzione, capire abbastanza i rischi da far validare correttamente ciò che si produce. Ognuno di questi gradini chiede qualcosa in più del precedente.

Un Product Manager con gli strumenti giusti può salirne diversi; uno sviluppatore che sale verso il prodotto sale gli stessi nell'altro senso. Al ruolo di Product Engineer, in particolare, si arriva per due traiettorie opposte — uno sviluppatore che risale verso il problema, o un profilo di prodotto abbastanza tecnico che scende verso la produzione — e nulla nel risultato dice da quale strada sia passata la persona.

Il mestiere di partenza smette quindi di essere un buon indicatore. A collocare qualcuno è il gradino che raggiunge, e la domanda «fin dove arrivi?» prende il posto della domanda «che cosa sei?».

Perché è importante

Offre una scala comune per discutere di ciò di cui una persona può farsi carico, indipendentemente dal titolo che porta e dal reparto a cui appartiene.

Ed evita due errori simmetrici di selezione: rifiutare un contributo perché viene dal mestiere sbagliato, e accettarlo perché viene da quello giusto.

Sfumature e limiti

La scala non è lineare: qualcuno può portare un deliverable in produzione su un ambito semplice e restare incapace di produrre un mockup utilizzabile su un percorso complesso. Il gradino raggiunto dipende tanto dalla zona quanto dalla persona.

E un continuum non dice nulla sul diritto di avanzarvi: saper aprire una pull request non autorizza a farlo su qualunque ambito.

Domande aperte

• Come constata un team il gradino effettivamente raggiunto da qualcuno, se non affidandogli un ambito e guardando che cosa succede?