Business Model Canvas per modellare progetti e organizzazioni

Cos’è e a cosa serve

Che cos’è un canvas? Letteralmente è una tela, un canovaccio, un template potremmo dire per rendere l’idea.
Il business model canvas è uno schema che consente sia di mostrare il funzionamento di organizzazioni esistenti sia di progettare nuovi modelli di business da zero.
Il business model canvas descrive come un’azienda crea, produce e acquisisce valore.
Il suo valore intrinseco sta nel fatto di essere uno strumento visuale, semplice, sintetico e duttile che si rivela un mezzo molto efficace di condivisione e comunicazione delle idee.
Dimenticate quindi le presentazioni power point, i documenti di requisiti e le risme di allegati; basta uno schema su un foglio A4 per promuovere il vostro prossimo progetto.

Business Model Canvas: il concetto di valore

Prima di iniziare ad utilizzare il canvas e tutte le sue potenzialità è necessario dedicare del tempo a queste domande:

Chi è il nostro cliente? O chi sono i nostri clienti…
Di cosa ha necessità? Qual è il risultato che ha bisogno di ottenere?

Le risposte a queste domande sono le fondamenta del nostro modello di business, quindi non abbiate fretta e dedicate tutto il tempo che vi serve per sviscerare gli aspetti da tenere in considerazione.

Un concetto-chiave che sta alla base del business model è infatti la necessità di definire il valore dal punto di vista del cliente, non con gli occhi dell’azienda che eroga il prodotto/servizio.

Business Model Canvas: i 9 blocchi

Una volta individuato il nostro cliente-tipo o i nostri clienti-tipo ed i relativi bisogni siamo pronti per approfondire i 9 blocchi costitutivi dello schema, ovvero:

Clienti

Sono la ragion d’essere stessa dell’organizzazione e possono corrispondere ad uno o più profili.

Valore offerto

Il valore che il cliente percepisce nello scegliere un’azienda piuttosto che un’altra (ad es.: comodità, prezzo, design, brand/status, minori costi, minori rischi, personalizzazione, performance, accessibilità, usabilità, ecc.).

Canali

I canali di comunicazione, distribuzione e canali di vendita sono il punto di contatto principale con i clienti.

Relazioni con i clienti

Possono essere di vario tipo (e convivere tra loro): personali, automatizzate, self-service, mediante community o di co-creazione con l’utente finale.

Ricavi

Derivano600 da vendita di beni, affitto/noleggio, canoni di servizio o di abbonamento, licenze, diritti di intermediazione o advertising.

Risorse chiave

Distinte in risorse umane, materiali, intellettuali e finanziarie.

Attività chiave

Ovvero ciò che l’azienda deve fare per far funzionare il proprio business; attività di produzione, vendita, consulenza/soluzione di problemi, supporto, ecc.

Partner chiave

Soggetti terzi che permettono di rendere efficace un business model (attraverso economie di scala, risparmio costi, ecc.).

Costi

Tutte le voci di spesa necessarie per portare avanti l’attività.

Business Model: come utilizzarlo

Uno degli aspetti più interessanti del canvas è come dicevo la sua duttilità. Si può utilizzare in situazioni disparate.
Vi faccio qualche esempio:

descrivere il funzionamento della propria azienda, di organizzazioni esistenti, competitor, ecc.
studiare modelli di business alternativi
progettare un nuovo prodotto/servizio
riprogettare il proprio modello di business
introdurre dei cambiamenti nell’organizzazione esistente

Il successo di questo strumento ha fatto sì che il suo impiego si sia esteso anche in ambiti non strettamente business.
Lo stesso creatore del canvas – Alex Osterwalder – racconta in “Business Model You” come utilizzare questo semplice schema per cambiare lavoro o cambiare vita.

Come il canvas può essere utile al Product Owner

Anche in un caso così specifico gli impieghi possono essere svariati.
Vi do giusto qualche spunto a riguardo.
Dal mio punto di vista è un ottimo strumento di comunicazione con il management.
E’ sintetico, veloce, permette di farsi un’idea a colpo d’occhio dei punti di forza di un prodotto/servizio e può essere agevolmente modificato per esplorare alternative.

Ma la sua forza non è limitata ad essere un semplice strumento di condivisione aziendale, può essere impiegato con successo anche nella gestione delle aspettative degli stakeholder di progetto.

Nei confronti del team di sviluppo è uno strumento utilissimo di allineamento perché consente di esplorare gli obiettivi e l’ambito di progetto, favorisce la comprensione della big picture, ma allo stesso tempo invita alla discussione, all’esercizio critico e alla condivisione di idee innovative.

E’ difficile trasmettere in un post quali benefici possa portare il canvas.
Si corre il rischio di sembrare un po’ invasati (tool-addicted)… ma posso dire che vale la pena fare qualche tentativo in prima persona per sperimentarne i vantaggi.
Per iniziare potete sempre ispirarvi ai tanti esempi disponibili in rete.

23 Marzo 201518 Novembre 2020

Il Product Owner in un’immagine

Girovagando in rete ho trovato uno schema che riassume a colpo d’occhio il ruolo del PO, per riprendere un argomento che mi sta a cuore…

Ha il pregio di sintetizzare le responsabilità del Product Owner all’interno dello Scrum Team.
Ripercorriamo gli eventi e gli artefatti Scrum con un focus su questa figura.

Con chi interagisce in PO

Il Product Owner è un focal point per tutti gli stakeholder di progetto.
E’ fondamentale che le richieste di clienti esterni ed interni all’azienda (ad esempio il management, i Product Manager, i Software Architect, ecc.) siano indirizzate al PO che funziona da collettore unico di richieste verso il team Scrum.

Responsabilità del Product Owner

Questo argomento richiederebbe un post dedicato data la vastità dell’argomento…
Lo schema descrive le principali responsabilità operative del PO:

gestione e aggiornamento continuo del backlog
prioritizzazione delle user stories
chiarimento dei requisiti
accettazione o rifiuto dell’incremento di prodotto sulla base dei criteri condivisi.

Non approfondisce invece le attività di tipo più strategico quali – ad esempio – l’analisi dei bisogni degli utenti, lo studio degli scenari di mercato, la definizione della vision di prodotto, ecc.

Release planning

In questa fase il compito fondamentale del Product Owner è definire gli obiettivi della release e spiegare le principali funzionalità da rilasciare.
Un aspetto interessante – e spesso sottovalutato – presente nello schema è l’analisi dei rischi che deve essere compiuta dal PO e dal team in questa fase, attività che può migliorare sensibilmente la pianificazione.

Sprint Planning

In fase di Sprint planning il Product Owner descrive al team cosa deve essere fatto seguendo le priorità elencate nel backlog. Definisce l’obiettivo dello sprint e ripercorre le singole user stories con l’intento di rendere chiaro il tipo di utente che ne trae vantaggio, la funzionalità richiesta ed il beneficio atteso.

Daily Scrum

E’ opportuno che il Product Owner sia presente al Daily Scrum, ma è il team ad essere protagonista di questo momento. Organizza la propria giornata e fa il punto sullo stato dell’arte.
Per questo motivo è utile che il PO ci sia (se non sempre spesso), che ascolti gli aggiornamenti e le esigenze del team senza far pesare la propria presenza.
E’ tendenzialmente un osservatore silenzioso nel Daily Scrum.

Sprint

Durante l’iterazione il Product Owner tiene d’occhio l’andamento dei lavori, verifica in corso d’opera quanto il team sta realizzando ed è disponibile per chiarimenti ed approfondimenti.

Sprint Review

Al termine dell’iterazione il Product Owner ha il compito principale di accettare o rifiutare quanto sviluppato dal team. Solo lui può decidere cosa considerare realmente “done”.
Nel corso della demo presenta agli stakeholder l’obiettivo dello sprint e contestualizza quanto realizzato all’interno della più ampia pianificazione di release.

Retrospective

Questo evento è presidiato dallo Scrum Master con l’obiettivo del miglioramento continuo. Mediante l’analisi di cosa ha funzionato e cosa non ha funzionato nel corso dello sprint vengono individuate una o più azioni per ottimizzare il processo.
Il Product Owner partecipa attivamente alla retrospective insieme a tutti gli altri membri del team Scrum, portando le proprie osservazioni e proposte.

Al termine della release

Così come per i singoli sprint il PO accetta o rifiuta le storie, al termine della release è colui che tira le fila dell’intero progetto, verifica i deliverable, decide il go/no-go finale e lo comunica a tutti gli stakeholder.

15 Marzo 201512 Dicembre 2022

Cosa mi ha insegnato il mio team

“Cosa mi ha insegnato il mio team”?

E’ il tema di un talk corale che si è tenuto durante la giornata “Agile for innovation” al Politecnico di Milano il 3 marzo.
Il tema e l’idea dello speech collettivo è opera di Fabio Armani.
Io ho partecipato al lavoro insieme ad altri 3 compagni d’avventura perché quando è stata lanciata l’idea mi è sembrato un argomento interessante da sviscerare.
Ed ecco qui di seguito qualche suggestione sul tema dal punto di vista di un Product Owner, che è una figura borderline (in tutti i sensi!) tra prodotto e IT.

Facile dire siamo Agili, difficile esserlo davvero…

Mi è capitato di vedere spesso transizioni più formali che sostanziali.
E’ un passaggio faticoso per tutti (management, product manager, sviluppatori) perché le abitudini sono dure a morire.
Anche se siete entusiasti di questo cambiamento potreste scoprire di adottare comportanti di micro-management “nascosti” sotto nuove spoglie.
Qualche esempio? Se il vostro backlog è una costellazione di storie di dettaglio o le vostre user stories hanno criteri di accettazione che sono infinite liste di dettagli e minuzie… sono segni che qualcosa non funziona come dovrebbe!

Con queste riflessioni in testa mi sono chiesta cosa posso fare io per agevolare questo cambiamento?
La domanda più importante da farsi è questa:

Come Product Owner qual è il mio valore aggiunto nel team?

Nel caso degli sviluppatori è facile rispondere: loro realizzano incrementi di prodotto, software funzionante.
Io come PO sono di aiuto se entro nei dettagli? Direi proprio di no…
Ciò che posso offrire io è il contesto, gli scenari di mercato, la visione d’insieme.
Inquadrare il singolo incremento di prodotto – ed anche il task – in una prospettiva più ampia, comunicare il tema, l’epica, l’obiettivo e il bisogno a cui cerchiamo di rispondere.
Cercare di legare il particolare al generale e viceversa può essere un’attività molto utile per la consapevolezza del team e la percezione del valore del proprio lavoro.

Prima abbiamo parlato di “smells”, ovvero i segni di qualcosa che non sta funzionando a dovere, ma…

Come ci accorgiamo che le cose vanno nel verso giusto?

Nel corso degli anni ho imparato a riconoscere 2 segnali che per me sono molto indicativi.
Uno è di tipo organizzativo e riguarda l’equilibrio tra business e tecnologia.
Nel momento in cui si raggiunge una posizione dialettica, le esigenze di entrambe le funzioni trovano ascolto e vengono integrate nel prodotto stiamo già assistendo agli effetti positivi del cambiamento di mentalità.

Tutto questo si riflette anche nel prodotto… quando ci rendiamo conto che non è costituito solo da nuove funzionalità.
Se c’è un push eccessivo sulla delivery rischiamo di dimenticare che esiste anche altro.
Il debito tecnico non scompare da solo!
Aspetti come il refactoring, le performance e la scalabilità – su cui i team di sviluppo insistono particolarmente – sono parte essenziale della qualità del prodotto e della sua sostenibilità nel tempo.
Troppo spesso il business dimentica questo aspetto… sino a quando viene messo davanti all’evidenza che anche il rilascio di una funzionalità banale richiede mesi.

Co-creazione

Quando siamo sulla strada giusta condividiamo i medesimi obiettivi ed è su questi – come azienda – che dobbiamo rimanere focalizzati.
Non ci interessa fare la spunta su un elenco di funzionalità determinate a priori; vogliamo indurre cambiamenti nel nostro utente finale e vogliamo seguire passo passo queste modificazioni tenendo conto dei feedback.
Sentiamoci liberi di esplorare delle alternative con il team.
Se abbiamo lavorato bene come product owner e siamo riusciti a trasmettere i reali bisogni dei nostri utenti accogliamo le proposte dei nostri sviluppatori perché ci possono fornire ottimi spunti e aiutare a trovare soluzioni brillanti.

In sintesi una delle lezioni più importanti che ho imparato in questi anni è che come Product Owner una volta che sono riuscita a comunicare in maniera efficace qual è l’obiettivo finale da raggiungere è opportuno che io faccia un passo indietro per lasciare al team lo spazio di crescere, diventare grande e autonomo nell’utilizzo delle pratiche agili.