Prima di salutarci per il periodo delle vacanze estive e tornare belli carichi a settembre, per le sfide dell’autunno e per parlare dei temi a noi cari, diamo un’occhiata al concetto di Evolutionary Model Archetypes di cui abbiamo accennato nel post precedente.

Una volta identificato il nostro Jobs to be Done, dobbiamo impostare il tipo di impianto operativo per perseguirlo: non per forza dobbiamo creare o far evolvere un prodotto e, non per forza, sarà un solo prodotto a permetterci di raggiungere il risultato.

In questo discorso è fondamentale riprendere la differenza tra “qualità propria” e “qualità percepita”: la prima è la qualità del prodotto o del servizio da un punto di vista delle sue caratteristiche tecniche/tecnologiche, la seconda è quella che il cliente associa al prodotto. Possiamo avere un prodotto di ottima qualità tecnica, ma di pessima qualità percepita.. il contrario è un po’ più difficile ad onor del vero.

Ad esempio, se il nostro Jobs to be Done è quello di permettere all’utente di semplificare l’acquisto di un capo di abbigliamento per far si che perda il minor tempo possibile, potremmo anche decidere di migliorare il nostro help desk per intervenire nei momenti di difficoltà e affiancare l’utente nelle attività relative: questo è un esempio in cui non si interviene sul prodotto, ma sul servizio offerto. 

Se si è, invece, nel caso in cui si interviene sul prodotto, è necessario avere ben chiaro il relativo evolutionary model di riferimento. È possibile, come elementi estremi, identificare due Archetipi che qui definiremo come segue:

• Singularity, caratterizzanti i prodotti one-shot, ovvero rispetto ai quali, dopo la consegna, non siamo più accountable e non sono più significativi per il nostro business
• Continuum, sono i prodotti che supportano direttamente il nostro business e che evolvono costantemente con esso e con la nostra organizzazione

Ma perché è così importante identificare l’archetipo caratterizzate?

In relazione ad esso possiamo decidere il modello operativo a supporto del prodotto, evitando di cadere in dogmi o convinzioni (bias) di sorta.

In particolare, l’archetipo Singularity, è adatto quando un'azienda crea un prodotto e “sposta” la relativa responsabilità di supporto ed evoluzione sul committente, senza più avere nessuna (o quasi) relazione con esso. In pratica ogni prodotto è un “esemplare unico”, realizzato per terzi che poi lo useranno per il proprio business senza aver più alcuna relazione con esso. È il classico caso dei prodotti del mondo dell’ingegneria civile, ma anche di quelli del mondo digital dove sussiste un forte ricorso ad outsourcing di progetto e/o gare.

Nel caso dell’archetipo Continuum, siamo nella condizione opposta: il prodotto è un “prodotto live” che è funzionale all’organizzazione che lo realizza ed evolve continuamente per supportarne il business. In tal caso l’azienda che lo realizza ne mantiene l’accountability e implementa la giusta strategia per supportarne l'evoluzione. In alcuni casi (si pensi alle startup) sia ha addirittura: azienda=prodotto.

Nel caso Singularity si può tranquillamente optare per un approccio di sviluppo a Progetto, mentre nel caso Continuum la scelta ricade in modo più naturale sul Value Stream.

Ricordo per l’ennesima volta che Progetto non vuol dire waterfall, ma è sinonimo di una iniziativa limitata nel tempo, realizzabile con diversi lifecycle (Agile compreso), mentre il Value Stream non vuol dire Agile, ma è un impianto perpetuo a supporto dello sviluppo di uno specifico business aziendale atto a soddisfare un cohort di utenti.

Ovviamente tra il Singularity ed il Continuum si assiste a tante condizioni di compromesso, che richiedono l’opportuno ingaggio dei team e degli esperti per settare l’approccio contingente più adatto: “context count”, senza presunzione di giusto o sbagliato. 

Buone vacanze a tutti J