Soft skills per developer: che cos’è il “product mindset”

Il Product Mindset: la vera differenza

Se le competenze viste sopra sono le fondamenta, il product mindset è ciò che viene costruito sopra. È il cambiamento più significativo nel profilo di uno sviluppatore oggi. Non si tratta solo di “scrivere codice”, ma di capire perché si sviluppa una certa feature e che impatto avrà sull’azienda e sugli utenti.

Uno sviluppatore con questa mentalità si interessa al prodotto. Vuole capire le decisioni, come la gente usa le varie funzioni e vuole dire la sua sulle strategie.
Sherif Mansour di Atlassian dice che sono:

“un ingrediente fondamentale per aiutarti a costruire un prodotto di successo, a scalare e a diventare un product manager migliore.”

Jean-Michel Lemieux (ex Shopify) li descrive così:

“Una volta poste le fondamenta del prodotto, hai bisogno di sviluppatori che si interroghino attivamente sul ‘perché’, che abbiano sete di usare le tecnologie per superare i problemi umani o degli utenti. Coloro che hanno l’empatia necessaria per puntare a esperienze magiche.

Il “Product Thinking” è il processo mentale che c’è dietro. Di solito si compone di tre fasi:

1. Problema: capire il problema guardandolo da più lati. Si usano strumenti come le “User Personas” o i “Jobs To Be Done” (cosa l’utente deve fare).
2. Opportunità: valutare come risolvere il problema e che cosa ci guadagna l’azienda (ROI, fette di mercato). In questa fase si realizzano i primi prototipi.
3. Soluzione: analizzare i test e decidere la soluzione migliore, tenendo conto dei limiti tecnici ed economici e della strategia generale.

9 caratteristiche per riconoscere uno sviluppatore con mentalità di prodotto

Per un team leader o per un HR, non è immediato capire se la persona che hanno di fronte possiede la mentalità di prodotto. Come si vede in un colloquio o in un collega? Gergely Orosz, ex engineering manager di Uber, ha stilato una lista di 9 comportamenti tipici di questi sviluppatori.

1. Propongono idee (e non eseguono e basta). Non si accontentano di eseguire il compito. Pensano a soluzioni diverse, mettono in discussione le specifiche e propongono modi migliori per fare le cose. Non aspettano che qualcuno gli dica cosa fare.
2. Si interessano all’azienda e ai dati. Cercano di capire come funziona il modello di business e come il prodotto fa soldi. Si chiedono come si sentono gli utenti, che cosa cercano e che cosa ci guadagnano. Guardano i dati sull’uso del prodotto e parlano con PM o data scientist per capirci di più.
3. Chiedono spesso “Perché?”. Vogliono sapere il motivo delle scelte. Perché questa funzione e non un’altra? Perché ora? Come misuriamo se funziona? Eventualmente cercano anche le risposte in autonomia.
4. Parlano con chi non è tecnico. Gli piace parlare con persone fuori dal team di sviluppo per capire cosa fanno. Sanno comunicare e sono curiosi. È facile trovarli a prendere un caffè o a pranzo con i colleghi del marketing, del design o delle vendite.
5. Propongono Trade-off tecnici e di prodotto. Capendo sia la tecnica, sia il “perché”, fanno proposte intelligenti. Ad esempio, se lo sviluppo di una funzione richiesta troppo lavoro, non cercano solo di diminuire il tempo di sviluppo. Magari tornano dal PM e dicono: “E se facessimo quest’altra cosa? L’impatto sull’utente è simile, ma ci mettiamo un decimo del tempo”.
6. Sono pragmatici sui casi limite (edge case). Capiscono subito quali sono i casi limite e cercano soluzioni per non perderci troppo tempo. Si concentrano su un prodotto minimo, ma che sia utile e funzionale e ne valutano lo sforzo: se un bug colpisce un utente su mille, può essere ignorato?
7. Cercano feedback subito. Trovano modi intelligenti per avere riscontri prima del rilascio. Fanno provare la funzione a un collega, mostrano il lavoro a metà al PM, organizzano “cacce al bug” col team. Si chiedono sempre: “Come facciamo a essere sicuri che la gente userà questa funzione come pensiamo?”.
8. Si sentono responsabili dall’inizio alla fine (e oltre). Si prendono la responsabilità di una funzione, dalla specifica al rilascio. Ma poi vanno oltre. Per loro, il lavoro è finito solo quando vedono i risultati sui dati. Dopo il rilascio, restano in contatto con PM, data scientist e assistenza clienti per capire come la gente usa davvero la loro funzione.
9. Sviluppano “istinto” per il prodotto. Progetto dopo progetto, il loro schema è: chiedere “perché”, proporre scambi, costruire velocemente, cercare feedback e controllare i dati dopo il rilascio. Con l’esperienza di questo modello ciclico, la loro comprensione del prodotto migliora e iniziano a sviluppare un vero “istinto”.

Problemi pratici e sfide

Introdurre questa mentalità in azienda non è facile. Ci sono alcuni problemi concreti che manager e HR devono conoscere.

• Velocità contro qualità. Per capire il contesto e gli utenti serve tempo. Questo sembra andare contro la fretta della delivery tipica dell’Agile. Il punto è che il tempo speso all’inizio per capire cosa fare, evita di dover rifare il lavoro dopo: si tratta di trovare un equilibrio tra “fare la cosa giusta” e “farla in fretta”.
• Non è per tutti. Non tutti gli sviluppatori vogliono (o devono) avere questa mentalità. Alcuni preferiscono concentrarsi solo sulla pura eccellenza tecnica, ed è un bene che sia così. Il 36% dei dev non è interessato a ruoli manageriali, e molti la pensano uguale riguardo alle responsabilità di prodotto. Le aziende dovrebbero offrire più percorsi di carriera, senza forzare tutti.
• Rompere i “silos”. Spesso, in azienda, c’è chi non vuole che i programmatori partecipino alle decisioni sul prodotto. I problemi più comuni sono i reparti che non si parlano, vecchi metodi “a cascata” dove le specifiche arrivano dall’alto e non si discutono  e l’idea obsoleta che lo sviluppatore debba scrivere codice senza fare domande.

Avere un product mindset non è più un extra per uno sviluppatore, ma una capacità chiave che fa la differenza. Le aziende che puntano su queste figure ottengono prodotti migliori e clienti più soddisfatti. Il futuro dello sviluppo software è di chi sa muoversi tra il codice e il contesto, tra la tecnica e l’impatto sulle persone. Avere questa mentalità, insieme a buone doti di comunicazione ed empatia, è quello che trasforma un bravo sviluppatore in qualcuno che guida davvero l’innovazione.