Tra progetti e prodotti digitali

Capita spesso: un’azienda decide di rifare un qualcosa di digitale e parte la ricerca di un’agenzia o un brief al team interno.

Al primo incontro iniziano le incomprensioni: da un lato ci si aspetta che l’agenzia/team possa fare qualunque cosa dall’altro iniziano le sopracciglia alzate.

Questa criticità nasce da una generica confusione su cosa serve e cosa chiedere. Vogliamo un progetto? Un prodotto? Capire la differenza è il primo passo per non sprecare tempo, budget (soprattutto per le PMI) e capire anche quali competenze è meglio avere in casa.

Tre elementi di base

Iniziamo con tre distinzioni terminologiche che ci porteranno alle nostre considerazioni e a lavorare meglio.

• Progetto: un’iniziativa temporanea intrapresa per creare un prodotto, servizio o risultato unico.
• Prodotto: il risultato di un processo produttivo, progettato per soddisfare esigenze specifiche.
• Operations: attività continuative e ripetitive che svolte per mantenere e gestire le funzioni quotidiane.

Queste tre definizioni iniziali ci aiutano a capire meglio cosa possiamo chiedere soprattutto se le associamo a dei ruoli con obiettivi specifici:

• Progetto –> Project Manager Consegnare quanto concordato rispettando dei vincoli.
• Prodotto –> Product Manager Creare elementi che soddisfino le esigenze.
• Operations –> Operation Manager Garantire continutà ed efficenza nelle attività in corso.

Procediamo scegliendo un esempio, la creazione di un sito web: qualcosa di semplice e frequente e che si presta a varie casistiche (anche intricate).

Siamo davanti a un prodotto o un progetto? Dipende (chi l’avrebbe mai detto? Alla fine però darò una risposta netta).

Il sito come progetto (+ operations)

L’azienda vuole un sito e chiede a un’agenzia di realizzarlo: si parla di cosa è incluso (lo Scope of Work), cosa è escluso nella realizzazione (Out of Scope) e di tutto quello che porterà alla messa online.

Una volta che il sito è “finito” ecco iniziare la parte di Operations, l’insieme di tutte quelle attività ripetitive che fanno in modo che quanto fatto “stia in piedi” (il famigerato “canone di manutenzione”).

Qui possiamo trovare sia gli aggiornamenti tecnici (es. plugin) che di contenuto (quello che abbiamo scritto sei mesi fa può richiedere aggiornamenti dato che la tecnologia è in continua evoluzione) che di varia natura. Non riguardano elementi nuovi, ma l’esistente ¹.

Per cui facciamo un esempio molto rapido con un’azienda che commissiona un sito:

• Progetto Sito
• Scope of Work: realizzazione del sito in un certo modo inclusi i contenuti testuali entro data x a budget y.
• Out of Work: realizzazione immagini e manutenzione post go-live.

Attenzione perché qui si gioca una parte importantissima: l’Agenzia che riceve “il progetto” non si fa domande sul valore effettivo della richiesta ², il/la PM ha il compito di portare a casa quanto definito rispettando i vincoli assumendo che quanto richiesto sia stato valutato con attenzione dalla committenza.

Perché dico importantissima? Banalmente perché qui nascono i problemi:

• “Eh, ma il sito non mi sta portando clienti / risultati” “Eh, ma noi il sito l’abbiamo fatto bene come ci hai detto”
• “Eh, ma il sito è lento e non è più in prima posizione” “Eh, ma il sito consegnato era in linea con quanto concordato”.

Il motivo per cui fare un sito, gli obiettivi, il business case sono di competenza dell’azienda che deve avere in casa delle competenze strategiche. Se queste competenze non sono presenti è il caso di evitare di affrettarsi sul progetto sito, ma fare prima delle considerazioni su cosa serve (ovvero dobbiamo fare un altro progetto prima di iniziare il progetto del sito).

Il sito come prodotto

Cambiamo a questo punto il paradigma e vediamo cosa succede a concepire un sito come un prodotto (digitale): da un’iniziativa temporanea ci spostiamo verso un arco temporale molto più lungo (potenzialmente infinito) dove si susseguono una serie di progetti.

Oltre a una differenza di lunghezza del ciclo vitale, per sua stessa natura il prodotto prevede aggiornamenti, miglioramenti, sviluppi e supporto per rimanere competitivo e rispondere alle esigenze degli utenti (o del mercato). Con questo scenario stiamo abbracciando l’idea che non sia possibile prevedere tutto e che alcuni elementi nasceranno dalle interazioni tra i soggetti coinvolti tra realizzazione e fruizione.

In questo scenario, l’agenzia o il team non è solo “chi fa il sito”, ma chi inizia a chiedersi se ha senso farlo, cosa dicono i clienti/utenti, chi contribuisce a farlo evolvere, le persone che mettono costantemente in discussione le attività fatte e pensano alle evoluzioni: insomma una gestione che accetta l’incertezza e cerca di ridurla con la consapevolezza che le attività cambieranno sulla base dei feedback ³

Questa impostazione è decisamente diversa dal caso precedente: nel progetto rispondiamo a un cliente, nel prodotto pensiamo all’utente.

Partendo dalla definizione iniziale, un/una Product Manager si concentra sui bisogni e modifica le attività sulla base dei feedback mentre, rimanendo aderentu alle definizioni, chi gestisce i progetti cerca di proteggere i piani ed evitare i cambiamenti ⁴.

Ma quindi? Progetto o prodotto?

Per cambiare vado diretto e senza compromessi: un’azienda DEVE pensare il sito, e tutte le altre iniziative digitali, come un prodotto.

Perché pensarle come prodotto? Un ricco elenco di motivi:

• Uniamo quello che vuole l’azienda con quello che interessa agli utenti
• Accettiamo che scopriremo cose durante le attività
• Partiamo dal presupposto che il contesto cambia e forse dovremo rifarlo appena concluso
• Facciamo pace con il fatto che le priorità cambieranno con i feedback
• Posso vare una prima versione senza che ci sia tutto
• Posso pensare a una serie di evoluzioni in maniera iterativa
• Lo sviluppo iniziale è una fase e con il prodotto devo pensare anche al post
• Mi pongo problemi sull’utilizzo e non solo la realizzazione
• Faccio delle considerazioni sulle metriche e gli impatti di business
• Penso al valore e non al piano

Questi sono solo i primi 10 motivi, ma ce ne sono molti altri (ma spero che siano sufficienti per convincere alcune persone a iniziare a pensare alle proprie attività digitali in maniera diversa).

Dopodiché, qualora siano presenti competenze interne di Prodotto, Digital, Business, potrà decidere di dare in outsourcing la realizzazione di componenti, progetti e altro.

Qualora invece non siano presenti queste competenze di Product Management dovrà invece lavorare con un’ottica diversa, ovvero cercare logiche di collaborazione più che di fornitura.

In questo modo però, le attività legate al digitale, potranno crescere e dare molta più soddisfazione.