10 motivi per uno sviluppo prodotto di successo
Esattamente un anno fa sono stato invitato alla Craft Conference di Budapest, dove ho parlato dei 10 principali motivi per cui i team di prodotto falliscono. Ho parlato principalmente del perché molti team sono così inefficaci e, nonostante le affermazioni contrarie, la maggior parte delle organizzazioni non è ancora veramente "agile", poiché lavora ancora secondo il principio a cascata. Così sono stato invitato di nuovo alla conferenza quest'anno per parlare di come lavorano i migliori team che conosco. Questo articolo è un riassunto del mio intervento.
Dopo il mio primo intervento, alcune persone mi hanno contattato chiedendomi maggiori informazioni. A parte consigliare loro di leggere il mio libro o di partecipare a un workshop, non ho avuto la sensazione di poter dare loro una risposta soddisfacente. Questo mi ha ispirato a riflettere più in dettaglio sulle principali caratteristiche dei team di prodotto estremamente forti. Così ho elaborato la mia personale Top 10.
Continuous Discovery e Delivery
Così come ho descritto i dieci maggiori problemi del modello a cascata, ho anche descritto le dieci caratteristiche dei team di successo in relazione a Continuous Discovery e Delivery (chiamato anche Dual Track Agile, Discovery Sprint o Delivery Sprint). Quali sono quindi i fattori di successo per uno sviluppo prodotto di successo?
1. Team di prodotto empowered
Il fattore più importante è il concetto assolutamente fondamentale di team di prodotto forti. Ma cosa significa esattamente?
Innanzitutto, è importante che il team esista a lungo termine in questa composizione e che i membri del team non vengano spostati come pedine degli scacchi. Se i team devono essere innovativi, hanno bisogno di tempo per imparare di più su se stessi, sulla tecnologia, sui clienti e sul contesto aziendale.
In secondo luogo, la chimica tra i membri del team è decisiva. Ciò significa che dovrebbero conoscersi e rispettarsi abbastanza bene da far sentire ogni membro del team sufficientemente a proprio agio per proporre idee e motivare continuamente se stessi e gli altri a dare il meglio.
In terzo luogo, un team dovrebbe avere una certa varietà di competenze, che normalmente consiste in product management, user experience design e sviluppo. Spesso ne fanno parte anche l'analisi dei dati e la ricerca utenti.
Infine, è vantaggioso se tutti i membri del team lavorano insieme nello stesso luogo, anche se per molte aziende questo non è un tema semplice. Product manager, product designer e gli sviluppatori (o almeno il responsabile del team di sviluppo) dovrebbero avere le loro scrivanie vicine. Purtroppo questo non è sempre realizzabile, ma si può almeno provare. E per chiarire: non sono i singoli team in luoghi diversi a rappresentare un problema. È la separazione geografica dei membri dello stesso team ad avere un impatto negativo sulla Velocity e soprattutto sull'innovazione.
2. Vision e strategia di prodotto
Per avere team di prodotto veramente empowered e autonomi, i membri del team devono avere una buona comprensione del contesto aziendale. Questo inizia con una product vision chiara e convincente e con il percorso per raggiungerla: la strategia di prodotto.
La product vision descrive il mondo che vogliamo creare nei prossimi due-cinque anni (per l'hardware di solito un po' di più).
La product vision deve essere ispiratrice. Una buona product vision è uno dei nostri strumenti di recruiting più efficaci e motiva le persone a venire al lavoro ogni giorno. Una vision ispiratrice attrae buoni professionisti, perché vogliono far parte di qualcosa di significativo.
La strategia di prodotto è la sequenza dei prodotti che vogliamo consegnare lungo il percorso verso la realizzazione della vision. Sarebbe una cattiva strategia voler soddisfare tutti gli Stakeholder con un unico rilascio. Invece, abbiamo una lista prioritizzata di mercati, geografie o personas e ci concentriamo sull'adattamento tra prodotto e mercato.
Più team di prodotto si hanno, più importanti diventano una vision e una strategia unificate, affinché ogni singolo team possa prendere le decisioni giuste.
La cosa più importante, però, è che la product vision sia ispiratrice e che la strategia di prodotto sia scelta consapevolmente.
3. Business Outcome
La seconda parte del contesto aziendale di cui un team empowered e autonomo ha bisogno per prendere buone decisioni è un insieme di obiettivi aziendali prioritizzati. Il sistema OKR (Objectives and Key Results) è pensato esattamente per questo.
Gli OKR riflettono una lista di problemi aziendali specifici che il team deve risolvere. Questi non sono però feature. Le feature sono solo soluzioni potenziali ai problemi. Completare una feature non rende un team di successo; piuttosto è la soluzione del problema reale a farlo.
I due principi alla base di questi metodi di gestione delle performance sono:
1) I team danno il meglio quando ricevono problemi da risolvere autonomamente, invece di ricevere soluzioni prestabilite.
2) Il team viene misurato in base ai risultati, non all'output. Consegnare feature su una roadmap è output; risolvere un problema aziendale è un risultato.
4. Un product manager competente
Purtroppo, la maggior parte degli sviluppatori non ha mai avuto l'opportunità di lavorare con un product manager capace. Quelli che l'hanno avuta sono anche quelli che insistono per avere sempre una persona del genere nel team. E ancora peggio è il fatto che molti sviluppatori non sanno nemmeno esattamente cosa il product manager dovrebbe contribuire al team.
Immagina la cosa in questo modo: affinché un team di prodotto possa risolvere veri problemi aziendali, non basta che una soluzione funzioni tecnicamente o che il cliente la trovi fantastica. La soluzione deve funzionare anche per il tuo business, e spesso questa è la parte più difficile.
Pensa a cosa significa. Immagina di lavorare per Uber o AirBnB e di doverti occupare di leggi complesse, gruppi di datori di lavoro e sindacati. Oppure prendi eBay, dove si è dovuto lottare con notevoli restrizioni per essere classificati come marketplace piuttosto che come sito di e-commerce. O Tesla, dove c'erano questioni di responsabilità riguardo all'Autopilot da chiarire. Ogni azienda ha la propria lista di ostacoli da superare:
Ostacoli legali, finanziari, legati alle vendite e ai prezzi, al marchio e al marketing, alla privacy, alla sicurezza, alle condizioni di partnership, ecc.
Purtroppo, l'unica persona che capisce tutto questo è l'amministratore delegato, e in questo caso si può capire perché fa fatica ad autorizzare il team a prendere le decisioni giuste autonomamente.
Ci sono tre modi in cui un team può lavorare. Uno è che l'amministratore delegato o un altro superiore decida tutto. Il secondo è che un product manager convochi una grande riunione e discuta tutto con l'intera dirigenza ("Design By Committee"), che di solito produce risultati scadenti. Il terzo è che il product manager faccia il suo lavoro, si confronti con gli ostacoli e li trasmetta ai membri del team affinché possano elaborare autonomamente la soluzione al problema.
Combina questo con una buona comprensione della tecnologia e una solida conoscenza degli utenti e dei clienti, e potrai sperabilmente capire perché questo è un lavoro difficile ma anche assolutamente essenziale per un team di prodotto, specialmente se il team deve godere di un livello ragionevole di autonomia.
5. Soluzioni attraverso la collaborazione
"Collaborazione" non vuole essere qui uno slogan. Intendo solo che le tre aree prodotto, design e sviluppo dovrebbero lavorare insieme per risolvere un problema, invece che il product manager passi i "requisiti", il designer li renda attraenti e gli sviluppatori scrivano il codice che viene loro richiesto. Il motivo è che nelle buone soluzioni, tecnologia e funzionalità si alimentano reciprocamente. La tecnologia rende possibili determinate opzioni di design, così come il design influenza la scelta della tecnologia. E le decisioni di design influenzano la funzionalità, e viceversa.
Tecnologia, user experience design e funzionalità sono intrecciati tra loro. Le buone soluzioni nascono da un costante andirivieni, un dare e avere permanente tra le tre aree.
Questo è anche il motivo principale per cui i team che lavorano nello stesso luogo sono fondamentalmente sempre migliori dei team in cui questo non avviene.
6. Product Discovery: apprendimento rapido
I grandi prodotti hanno molto a che fare con la capacità di un team di provare rapidamente molte idee. Vogliamo separare il più velocemente possibile le buone idee da quelle cattive. La Product Discovery comprende tutta una serie di tecniche che ci aiutano a scoprire rapidamente quali idee sono fantastiche e quali no. Alcune idee sono davvero grandiose e altre meno. Alcune sono rischiose e alcune costose. A volte abbiamo bisogno di prove, altre volte bastano indizi.
Le persone descrivono questo nei modi più diversi. Alcuni si attengono al detto "fake it before you make it", che significa "fai finta finché non funziona". Altre persone sottolineano che si dovrebbero costruire cose che non sono scalabili. L'importante è imparare velocemente e minimizzare lo spreco.
Far costruire e lanciare un vero prodotto da un team di sviluppo per testare un'idea è praticamente il metodo più lento e costoso per imparare qualcosa.
7. Concentrarsi sui rischi principali
Nella Product Discovery ci sono alcuni punti importanti da tenere a mente.
Prima di tutto, dobbiamo concentrarci sui quattro rischi principali:
Valore – qualcuno comprerebbe questo prodotto o vorrebbe usarlo?
Usabilità – i clienti capirebbero come usarlo?
Fattibilità – i nostri sviluppatori possono costruire il prodotto con la tecnologia, il tempo e le competenze a loro disposizione?
Stakeholder – tutti gli interessati nell'azienda sono d'accordo con la soluzione proposta?
La Product Discovery è la ricerca di buone risposte a queste quattro domande. Una volta trovate, abbiamo le prove necessarie e siamo fiduciosi che il team di sviluppo possa implementare e consegnare una soluzione qualitativa e scalabile.
8. Il ruolo dell'MVP
Il concetto di Minimum Viable Product è uno dei concetti più importanti nello sviluppo prodotto e, allo stesso tempo, uno dei concetti più spesso usati in modo errato e fraintesi.
Generalizzare è sempre pericoloso, ma mi sbilancio e affermo che un MVP non dovrebbe mai essere un prodotto. Ogni volta che ho incontrato un team che aveva costruito un MVP con molto tempo e denaro, ho potuto mostrargli come avrebbe potuto ottenere lo stesso effetto di apprendimento con costi molto inferiori e molto meno spreco.
Un MVP è quindi un esperimento, un test. Normalmente è un tipo di prototipo. Spesso è un prototipo per l'utente, a volte un prototipo con dati live o viene usato per studi di fattibilità. E a volte è un mix di queste cose. In ogni caso, è sempre solo una piccola parte dello sviluppo di un prodotto reale.
9. Product Delivery: nessun compromesso sul rilascio
Qui non mi interessa dire agli sviluppatori come sviluppare e rilasciare software. Al contrario. Un problema che sorge quando un team di sviluppo deve costruire l'MVP è che spesso si sente costretto a rilasciare software di cui non è convinto. Non ci sta davvero al 100%. Forse ci sono problemi di affidabilità, scalabilità o performance, ma il product manager continua a dire: "È solo un MVP, rilassatevi!"
Dico semplicemente che non si dovrebbero fare compromessi quando si tratta di software da cui i clienti dipendono per mantenere il loro business. Esistono molte buone tecniche di Product Discovery per testare gli MVP, attraverso le quali vengono protetti i nostri clienti, il nostro fatturato, la nostra reputazione e i nostri collaboratori.
Usa quindi le tue best practice e rilascia solo prodotti quando hai piena fiducia in quel rilascio.
10. Essere ossessionati dal cliente
Quest'ultimo punto va in una direzione un po' diversa. In quasi ogni azienda in cui vado, mi dicono quanto amano i clienti. Questo è di solito parte dei valori o della mission aziendale. Dirlo è facile, ma agire davvero in questo modo è decisamente più difficile.
Lo noto abbastanza rapidamente quando parlo con un team. Come gestisce il team un problema con il cliente? Quanto è urgente? Il team entra in contatto con il cliente per comprenderlo meglio, se necessario? I membri del team conoscono i clienti per nome? Che relazione hanno con i clienti? I clienti li infastidiscono o sono piuttosto come colleghi per i membri del team?
Il modo migliore per risvegliare vera empatia e dedizione per il cliente è che i membri del team (soprattutto gli sviluppatori) si mettano direttamente in contatto con il cliente.
Spero che questo ti aiuti a sviluppare una migliore percezione di ciò che rende grandi i team di prodotto.
Questo testo proviene dal blog di Marty Cagan ed è stato tradotto in italiano.
Outcome vs. Output
=> Comprendere il Minimum Viable Product (MVP)
