Creare prodotti di successo grazie alle idee, dall'ideazione del progetto alla consegna
In Jira Product Discovery, l'oggetto principale con cui si lavora nel backlog di prodotti sono le "Idee". Per supportare un processo continuo di convalida e di apprendimento, utilizziamo le idee come oggetti di lunga durata: un'idea lascia il backlog quando inizia a essere sviluppata, ma sopravvive durante le iterazioni di esplorazione e consegna, fino a quando non produce l'impatto richiesto.
I team di prodotto di successo adottano una mentalità sperimentale: continuano a iterare l'idea nel tempo aggiungendo più contesto, il feedback degli utenti, specifiche e design. In ogni fase del ciclo di vita dell'idea, valutano cosa ha funzionato e cosa no, rispondendo alle domande chiave e confermando le loro ipotesi per assicurarsi che gli investimenti corrispondano al feedback e ai risultati che ricevono.
Trasformare piccole idee in grandi idee
Sebbene il nome dell'oggetto usato in Jira Product Discovery sia "Idee", queste possono rappresentare idee di prodotto, opportunità, problemi, soluzioni e altro ancora. Un backlog di prodotto può essere progettato per contenere idee di diversi tipi e livelli di granularità.
È importante definire queste categorie e far sì che tutti i partecipanti al processo siano d'accordo su di esse. In questo modo è possibile evitare che il backlog di prodotto diventi un miscuglio di elementi, da elementi eccessivamente grandi a elementi eccessivamente piccoli, senza un framework per classificarli e confrontarli.
Macigni, sassi e ciottoli: un modo per classificare le idee
Nel team di Jira Product Discovery, organizziamo le idee in tre livelli: macigni, sassi e ciottoli.
Macigni: un grande investimento con profitti potenzialmente elevati ma anche con molte incertezze
Esempio: una nuova grande scommessa, un nuovo pilastro del prodotto, un grande progetto ingegneristico.
Sassi: investimenti di medie dimensioni con minori rischi
Esempio: nuove funzioni, nuovi esperimenti di onboarding, riprogettazioni basate sul feedback
Ciottoli: piccolo investimento, in genere semplice
Esempio: piccoli miglioramenti dell'interfaccia utente, correzioni "paper cut"
Il nostro team utilizza viste separate per discutere queste diverse categorie di idee:
Attributi di un'idea
In Jira Product Discovery, ogni idea è completa di un riepilogo di una riga, una descrizione dettagliata, approfondimenti, come il feedback dei clienti, e link ai ticket Jira per la consegna dell'idea.
Per essere il più utile e attuabile possibile, ogni idea del backlog di prodotto deve essere completa dei seguenti attributi:
Attributo | Che cos'è? |
|---|---|
Riepilogo | Una riga che descrive l'idea. |
Descrizione | Una descrizione più dettagliata dell'opportunità, del problema, della soluzione. |
Campi | Le diverse sfaccettature dell'idea: a quale obiettivo contribuisce, la sua fase, su quale parte del prodotto incide, informazioni per assegnarle la priorità, come impatto o impegno, link a specifiche o progettazioni. |
Approfondimenti | Informazioni acquisite su tutti i canali man mano che arrivano: apprendimenti chiave dal feedback degli utenti, frammenti di conversazioni con i clienti e report di ricerca o analisi dei prodotti che spiegano chiaramente perché questa idea è importante. |
Consegna | Link ai ticket di consegna in Jira (epic o iniziative) per il lavoro di consegna per spedire effettivamente l'idea del prodotto. |
Può essere necessario del tempo per raccogliere tutte queste informazioni per ogni idea. Inizialmente, l'idea può entrare nel backlog con un riepilogo di una riga, ad esempio un approfondimento raccolto durante una conversazione con un cliente. Col tempo, raccoglierai ulteriori informazioni in base alle interviste con gli utenti, al feedback delle vendite o dell'assistenza o alle modifiche nella strategia aziendale.
Esistono due modi per descrivere le idee: direttamente in Jira Product Discovery o collegando Confluence al progetto Jira Product Discovery del tuo team.
In Jira Product Discovery, scrivi un riepilogo o una definizione nel campo della descrizione dell'idea. Usa uno dei modelli disponibili, o creane uno tuo, per fornire una formula coerente che descriva problemi, soluzioni, ipotesi e altro ancora relativamente all'idea.
Se anche il tuo team utilizza Confluence, puoi collegare l'idea alle pagine di Confluence: nella descrizione dell'idea o utilizzando campi di collegamento ipertestuale personalizzati. Il vantaggio di questo approccio è che puoi sfruttare tutte le funzioni di collaborazione di Confluence, come i commenti in linea.
Il contenuto della descrizione stessa dipenderà dal tipo di idea e dalla sua fase.
Il ciclo di vita dell'idea
Altrettanto importante per il contenuto di un'idea è il modo in cui si evolve nel tempo. Ecco perché è importante definire fasi chiare che ogni idea deve attraversare durante il suo ciclo di vita. Avere un vocabolario comune per descrivere le fasi del ciclo di vita dell'idea rende ogni conversazione più produttiva, sia all'interno del team che con gli stakeholder.
In Atlassian utilizziamo quattro fasi: Incertezza, Esplorazione, Creazione e Impatto. In Atlassian, tutti sanno cosa significa ognuna di queste fasi. Per ogni fase, sappiamo quale tipo di lavoro sta svolgendo il team, il tipo di domande da porre e il tipo di aiuto di cui potrebbe aver bisogno il team. Questa coerenza vale per le discussioni all'interno del team, con altri team o con i dirigenti senior.
Durante la creazione di Jira Product Discovery, il nostro team ha utilizzato questo approccio per sviluppare, convalidare e realizzare le nostre idee. Per ogni fase del ciclo di vita, spiegheremo come è stata messa in pratica dal nostro team.
Incertezza, esplorazione, creazione, impatto
Prima di entrare in questo ciclo di vita, ogni idea inizia nel parcheggio. In questa fase, di solito sono solo riepiloghi di una riga, con l'intuizione che ha portato alla loro creazione. Queste informazioni possono provenire da un workshop, da un report di ricerca, da una discussione con un cliente o essere condivise da un addetto alle vendite o all'assistenza.
Una volta iniziato il lavoro attivo sull'idea, seguono le quattro fasi:
Incertezza: discuti dei problemi che l'idea potrebbe risolvere o delle opportunità che potrebbe realizzare, su chi avrà impatto e la sua importanza.
Esplorazione: definisci potenziali soluzioni fino a trovarne una convalidata dal feedback dei clienti.
Creazione: crea la soluzione e verificala finché non soddisfa le esigenze di un numero sufficiente di clienti.
Impatto: lancia la soluzione, valuta i risultati e continua a migliorare fino a ottenere il risultato desiderato.
Non si tratta di un modello a cascata: le fasi non sono necessariamente lineari. Ad esempio, è molto comune che un'idea nella fase Esplorazione ritorni alla fase Incertezza, poiché testare le soluzioni ci insegna di più sul problema. È anche previsto che alcune idee vengano abbandonate, se non trovi una soluzione adatta dopo qualche tentativo.
Nelle sezioni seguenti, illustreremo ogni fase mostrando come il nostro team le ha seguite durante la creazione di Jira Product Discovery.
Se ti interessa questo processo, guarda questa conversazione per ulteriori dettagli:
Incertezza
La fase Incertezza consiste nel convalidare un problema o un'opportunità.
In questa fase, di solito ti affidi a interviste qualitative con i clienti. Da questa ricerca, il tuo team chiarirà i vantaggi e i risultati che l'idea mira a fornire, misurati in termini di valore per i clienti e l'azienda. Elaboreranno anche un'ipotesi su come misurare il successo.
Per le idee in questa fase, puoi utilizzare il modello "Definizione del problema" di Jira Product Discovery o crearne uno tuo.
Durante le fasi Incertezza, Esplorazione, Creazione e Impatto, raccogli gli apprendimenti tratti dalla ricerca e dalle conversazioni con i clienti nella sezione Approfondimenti dell'idea:
Incertezza in azione
Ecco come si è svolta la fase Incertezza durante la costruzione di Jira Product Discovery. L'idea originale per questo prodotto è nata:
Da interviste con i product manager che utilizzano Jira per la distribuzione del software
Analizzando le ricerche del team Research & Insights di Atlassian e di società di analisi come Gartner e Forrester
Da esempi di best practice per lo sviluppo di prodotti, come i blog di Marty Cagan e il libro di Teresa Torres.
La raccolta di questi approfondimenti ci ha dato la certezza che:
I PM erano alle prese con molte cose, dalla definizione efficace delle priorità al convincere tutti delle loro roadmap
I PM si rivolgevano a Jira per risolvere questi punti critici, ma con poco successo perché Jira non è stata progettata per questo scopo
I PM erano bloccati alla fase di consegna, concentrati su output come le funzioni di spedizione quando avrebbero potuto adottare una mentalità orientata all'esplorazione e alla realizzazione di risultati
La gestione dei prodotti stava diventando una funzione chiave, anche al di là delle aziende tecnologiche. Abbiamo quindi ritenuto che questa fosse una grande opportunità e che ci sarebbe stata la forte richiesta di una soluzione.
Ci siamo concentrati in particolare sulla convalida della nostra ipotesi in merito alla domanda, poiché questa era quella più rischiosa. Se ci fossimo sbagliati, avremmo creato un prodotto che solo poche aziende avrebbero acquistato.
Quindi, prima di scrivere anche una sola riga di codice, abbiamo creato una pagina web che pubblicizzava il prodotto.
I risultati hanno confermato la nostra ipotesi: 3.000 persone in lista d'attesa nel giro di due settimane.
Esplora
Nella fase Esplorazione, concettualizziamo, testiamo e convalidiamo soluzioni per i problemi o le opportunità identificati in Incertezza.
Sappiamo che molte idee di prodotto falliranno: questa è solo una parte del processo! Per identificare prima queste idee meno promettenti e far posto a quelle buone, Marty Cagan propone che i product manager affrontino quattro rischi principali. Usali per valutare le possibili soluzioni ai problemi e alle opportunità che hai identificato.
La soluzione è utile per i clienti? In caso contrario, supponendo che abbiano già accesso ad alternative migliori, c'è il rischio che le persone non utilizzino la soluzione che hai creato.
La soluzione è utilizzabile e intuitiva? Affinché gli utenti possano ricevere una soluzione di valore, è necessario che essa sia facilmente accessibile e utilizzabile. Se per poter sfruttare la soluzione sono presenti troppi ostacoli, il rischio è quello di lanciare una funzione che verrà utilizzata poco.
Questa soluzione è tecnicamente fattibile? Non importa quanto sia promettente un'idea, gli ingegneri devono avere le competenze e la tecnologia necessarie per farla funzionare, altrimenti rischi di sprecare risorse inutilmente.
La soluzione è fattibile con le risorse e i vincoli aziendali? Probabilmente saranno necessarie alcune iterazioni diverse per ottenere la soluzione giusta. Devi assicurarti che l'azienda sia pronta a investire, altrimenti rischi di dedicare tempo a un'idea che verrà abbandonata.
L'obiettivo del tuo team è ridurre al minimo i rischi nel modo più efficiente possibile, evitando di investire eccessivamente sulla base dell'entusiasmo per la soluzione e di una sensazione istintiva. Questo avviene comunemente con il rilascio di una funzione, poi con l'utilizzo o lo studio delle sue prestazioni. Usa invece tecniche lower-lift, come creare prototipi in Figma, per poi presentarli ai clienti per ottenere un feedback immediato prima di iniziare a scrivere il codice.
Se decidi di rilasciare una funzione, prova a creare un prototipo live con molte limitazioni, testalo con un piccolo gruppo di primi utenti e distribuisci velocemente le iterazioni. In questo modo non devi pensare a tutti i casi ricorrenti. Se l'idea non funziona per loro, scoprirai il perché molto più velocemente e continuerai a implementare iterazioni finché non funzionerà oppure scarterai l'idea.
Se ci sono ampie aree di incertezza, esegui un picco tecnico nell'ambito della fase di esplorazione. Questo tipo di implementazione ha lo scopo di aiutarti a capire i vincoli del tuo team, ciò che è tecnicamente fattibile e dove si trovano le aree di complessità tecnica.
Per le idee in questa fase, puoi utilizzare il modello di definizione della soluzione di Jira Product Discovery o crearne uno tuo.
All'interno del tuo backlog di prodotto, collega tutti i documenti, le specifiche e le progettazioni relativi a ciascuna idea, in modo da averli a portata di mano per parlare dell'idea con il tuo team e gli stakeholder. Ti consigliamo di creare campi di collegamento ipertestuale per ogni idea per monitorare ciascuna risorsa (one-pager, progettazione).
Ecco una demo su come fare:
Fase di esplorazione in azione
Durante la creazione di Jira Product Discovery, abbiamo utilizzato le seguenti tecniche per convalidare le nostre soluzioni con i clienti:
Per prima cosa, abbiamo mostrato ai PM diapositive con diverse soluzioni possibili, per capire quale fosse la più adatta. Grazie a queste conversazioni, abbiamo imparato molto sulle difficoltà dei nostri clienti e su ciò che apprezzavano. Ed è così che la "definizione delle priorità" è diventata il primo pilastro di Jira Product Discovery.
💡 Le diapositive sono ottime per questa fase di convalida: sono facili da creare, testare e modificare.
Successivamente, abbiamo creato prototipi in Figma, li abbiamo mostrati agli utenti e abbiamo chiesto in che modo le soluzioni li avrebbero aiutati. Il primo prototipo con cui l'abbiamo provato era una soluzione pensata per aiutare i PM a utilizzare il feedback degli stakeholder per definire le priorità.
Sebbene ci fosse sicuramente interesse, i PM hanno ritenuto che fosse necessario un impegno eccessivo per configurarlo prima di poter ottenere valore. Quindi, abbiamo scartato l'idea.
Dopo aver raccolto diversi feedback di questo tipo, abbiamo esplorato la soluzione che sarebbe diventata ciò che è oggi Jira Product Discovery: uno spazio collaborativo per parlare di idee di prodotto.
In questa fase le conversazioni con gli utenti sono cambiate drasticamente. Molti si chiedevano quando avrebbero potuto accedervi, visto che lo strumento li avrebbe aiutati moltissimo. In quel momento abbiamo capito di essere sulla strada giusta.
Dopo aver raccolto diversi feedback di questo tipo, abbiamo esplorato la soluzione che sarebbe diventata ciò che è oggi Jira Product Discovery: uno spazio collaborativo per parlare di idee di prodotto.
In questa fase le conversazioni con gli utenti sono cambiate drasticamente. Molti si chiedevano quando avrebbero potuto accedervi, visto che lo strumento li avrebbe aiutati moltissimo. In quel momento abbiamo capito di essere sulla strada giusta.
Creazione
Nella fase di costruzione, i team creano e convalidano le soluzioni che hanno definito durante l'esplorazione. È qui che avviene la maggior parte del lavoro di sviluppo.
Il risultato di questa fase è un software funzionante, un nuovo prodotto o una nuova funzione o un miglioramento di un'esperienza esistente, che ha dimostrato di essere in grado di fornire i risultati previsti, è stato adottato da un numero sufficiente di clienti per dimostrarne il valore ed è pronto per l'uso da parte di tutti i clienti.
Quando inizia la consegna, in questa fase o durante la fase di esplorazione, dovrai collegare l'idea ai ticket di consegna in Jira (consigliamo il livello epic o superiore). Monitora l'avanzamento delle consegne da Jira Product Discovery e ottieni una panoramica dell'avanzamento in tutte le iniziative e i team di prodotto.
Se più team sono coinvolti nella realizzazione di un'idea e lavorano su diversi progetti Jira, puoi collegare tutti i loro ticket di consegna all'idea presente nel tuo backlog di prodotto.
Puoi quindi monitorare l'avanzamento della consegna dall'interno di Jira Product Discovery e avere una panoramica dell'avanzamento di tutte le iniziative e i team di prodotto.
Per ulteriori informazioni, puoi dare un'occhiata al nostro webinar su come collegare la fase esplorazione e la fase di consegna in Jira nella sezione Risorse.
Ricorda, è molto improbabile che la soluzione produca immediatamente i risultati attesi. Invece, rilascia presto e spesso ai clienti e continua a iterare finché non è sufficiente. Continua ad aggiungere all'idea le informazioni sulle conversazioni con i clienti in base a ciò che apprendi. Il modo in cui misurerai il successo sarà diverso in base al tipo di idea: nuova funzione, iniziativa di crescita, ecc. Assicurati che tutti ne siano a conoscenza e che i tuoi piani consentano iterazioni.
Fase di creazione in azione
Durante la creazione di Jira Product Discovery e l'aggiunta di nuove importanti funzioni al prodotto, abbiamo testato e convalidato tutte le funzioni con gruppi di clienti sempre più ampi. In alcuni casi, questo processo ha richiesto alcune settimane, in altri alcuni mesi.
Da 0 a 10 clienti Dimostrazione del valore | Durante la fase di esplorazione, abbiamo lavorato in modo iterativo con una piccola quantità di clienti preselezionati. Abbiamo lavorato a stretto contatto con questi clienti per definire insieme la soluzione. Abbiamo proseguito in modo iterativo finché non abbiamo ricevuto la conferma da parte loro che la soluzione risolveva il problema riscontrato. In questa fase la soluzione ha dimostrato il suo valore. Ma è tutt'altro che completa e non prende in considerazione i casi ricorrenti. |
Da 10 a 100 clienti Completamento delle funzionalità | Abbiamo quindi progressivamente dato accesso a un numero maggiore di clienti. Questo ci ha aiutato a identificare diversi scenari che potremmo non aver preso in considerazione inizialmente. Abbiamo continuato a implementare iterazioni fino a quando non abbiamo raggiunto 100 clienti attivi che utilizzavano la soluzione. In questa fase, la soluzione è in genere completa di funzioni. Ma potrebbe non essere facilmente individuabile e non è self-service. Ad esempio, l'utente potrebbe aver bisogno di un video tutorial per capire come usarla. |
Da 100 a 1.000 clienti Rendere la soluzione self-service | Abbiamo quindi dato accesso a più clienti, fino a raggiungerne 1.000. A questo punto abbiamo esaminato i numeri di utilizzo derivanti dall'analisi dei prodotti, dai ticket di assistenza e dai feedback in entrata. In base ai nostri risultati, abbiamo migliorato l'interfaccia utente o risolto i bug. Se i numeri di utilizzo fossero stati troppo bassi per essere utili, avremmo esaminato l'individuabilità della funzione. In questa fase, la funzione dovrebbe essere self-service: è individuabile, l'interfaccia utente è soddisfacente, la documentazione è pronta, ecc. |
Disponibilità generale Preparazione dal punto di vista operativo | Infine, abbiamo finalizzato l'abilitazione all'assistenza, l'abilitazione alle vendite, le dashboard operative, i miglioramenti delle prestazioni e della scalabilità In questa fase, la soluzione dovrebbe essere pronta per il debutto. |
Quando lavoriamo su soluzioni come questa, di solito le formiamo in una pagina di Confluence separata che chiamiamo "Documento dinamico sulle funzioni". Questa è una pagina molto leggera che apriamo ogni qual volta che ci riuniamo come team, per discutere dell'ambito dell'iterazione attuale. Aggiorniamo questo documento frequentemente, man mano che apprendiamo di più su ciò che è facile o difficile da rilasciare. Non si concentra sulle singole attività, ma sull'esperienza del prodotto, che è ciò su cui vogliamo che tutti siano allineati, dal prodotto alla progettazione all'ingegneria.
Impatto
Nel modello di prodotto, tutto inizia e finisce con i risultati. I team assegnano la priorità alle idee in modo da poter ottenere un risultato e, dopo la realizzazione, continuano a monitorare l'avanzamento verso tali risultati. Questo fornisce informazioni per gli aggiornamenti sui tuoi obiettivi e strategie e su come assegni la priorità alle tue prossime mosse.
Anche dopo il rilascio di una soluzione, non è mai veramente "finita": ogni nuova funzione introdotta va a fare parte del tuo prodotto. Devi continuare a migliorarla per assicurarti che abbia valore per gli utenti e che le persone non lo trovino poco intuitiva o difficile da usare. Assicurati di monitorare ciò che i clienti chiedono, cosa pensano delle nuove funzioni e con che frequenza vengono segnalate nei ticket di assistenza.
Impatto in azione
Nel team di Jira Product Discovery organizziamo revisioni mensili e trimestrali in cui confrontiamo l'impatto che abbiamo ottenuto con quello che ci eravamo prefissati di raggiungere. A volte i risultati sono soddisfacenti e cambiamo molto poco, altre volte cancelliamo la tabella di marcia per provare qualcosa di diverso.
Ecco una tecnica che utilizziamo: dopo aver consegnato una soluzione, creiamo un'idea di miglioramento corrispondente in cui raccogliamo informazioni dettagliate, tra cui:
feedback in entrata da parte degli utenti
segnali che dimostrano che la funzionalità sta risolvendo o meno i problemi per cui è stata creata attraverso feedback, sondaggi e interviste
dati di utilizzo derivanti dall'analisi dei prodotti per capire se la soluzione viene effettivamente utilizzata In caso contrario, potrebbero esserci problemi di esplorazione o semplicemente meno entusiasmo per la funzionalità di quanto avevamo previsto.
Esaminiamo questi dati regolarmente e ogni team assegna il budget per i miglioramenti delle funzionalità. Sia le nuove idee che i miglioramenti a quelle esistenti sono indicati nella roadmap di ogni team:
L'avanzamento di un'idea
Jira Product Discovery fornisce una serie di campi per mostrare lo stato di avanzamento dei ticket di consegna di un'idea. Ma non crediamo che questo sia necessariamente il modo migliore per comunicare i progressi agli stakeholder. Il fatto che i task di un epic siano completati al 60% o all'80% non rivela quanti progressi stia realmente facendo il team.
Ecco un modo più efficace per comunicare i progressi agli stakeholder: contrassegna ogni idea come "in linea", "a rischio" o "non in linea" (tramite un campo) e aggiungi un commento (nella descrizione dell'idea). Questa è una forma primitiva di collaborazione molto semplice, ma molto efficace nel far sapere agli stakeholder dove hai bisogno di aiuto.
Se sei un cliente Atlas, conosci già questo approccio. Guarda il video su come collegare le idee di Jira Product Discovery con i progetti Atlas nella sezione Risorse. Nel video troverai informazioni più precise e accurate rispetto alle visualizzazioni seguenti, che misurano l'avanzamento in percentuale dei ticket di Jira consegnati.
E poi?
Utilizzando le idee come veicolo per portare le soluzioni attraverso l'ideazione, la convalida e la consegna, i team di prodotto possono mantenere il personale organizzato e concentrato sui risultati finali.
Nelle ultime due sezioni di questo manuale, spiegheremo nel dettaglio come utilizzare un backlog di prodotto per:
configurare canali di feedback e raccogliere informazioni per convalidare le idee;
dare maggiore priorità alle idee più importanti;
- creare tabelle di marcia sulle quali i team e gli stakeholder possano allinearsi;
Forniremo esempi di come facciamo tutto ciò nel team di Jira Product Discovery, utilizzando Jira Product Discovery e altri prodotti.