Prodotti a uso interno: valore e sfide principali

Con l’articolo di oggi cantiamo e celebriamo le gesta di eroi spesso ignorati del mondo di prodotto: i product manager che lavorano sugli strumenti sviluppati internamente all’azienda. Quei tool nascosti all’occhio umano, che chiunque vuole che funzionino (e che lo facciano bene), per cui non ci saranno mai le risorse necessarie e per cui assumere qualcuno è sempre una sfacchinata.

Ok, magari non sono sempre presentati come la cosa necessariamente più entusiasmante su cui lavorare, ma lascia che ti spieghi perché valga la pena metterli nel tuo arsenale di esperienze e perché, almeno personalmente, me ne sia innamorato…

In questo articolo scoprirai:

• Il valore di una solida struttura di tool interni, e
• Le sfide principali che ti puoi aspettare

Se anche tu combatti ogni giorno in trincea per creare prodotti digitali che abbiano impatto, la community di Product Heroes è il posto giusto per te. Non te ne pentirai.

Il valore dei tool interni

Partiamo dalla definizione:

dicesi tool interno ogni prodotto fatto “su misura” all’azienda e che aiuta i team coinvolti a… fare meglio il proprio lavoro. Il tuo obiettivo è sostanzialmente quello di migliorare la vita altrui.

Banalmente, da qui proprio il loro valore:

• senza i tool a supporto del Servizio Clienti l’utente non è ascoltato;
• senza tool di reporting non è possibile fare diagnostica e di conseguenza prendere decisioni mirate;
• senza un sistema di fatturazione la tal collaborazione non può essere onorata, e così via.

Ne giova nel tutto anche la retention aziendale: il fatto di doversi trovare a fare e rifare manualmente e continuamente lo stesso task non è un buon incentivo per qualcuno a restare (anzi nel lungo direi essere il contrario…), e tutto il processo di recruiting come ben sai è duro e dispendioso sia in termini di tempo che di risorse.

Product management è (anche) risolvere problemi e portare valore e in questo senso niente lo fa di più di questi tool.

Personalmente, mi sono affacciato al mondo dello sviluppo di tool interni direttamente durante la mia primissima esperienza a Bumble, lavorando con developer prettamente di back office ed in supporto al team di customer service e community operations. In seguito, mi sono spostato a gestire i componenti a supporto di ogni pratica possibile ed inimmaginabile di internazionalizzazione. 

Operativamente, creo interfacce per la Units di internazionalizzazione e mi assicuro che tutti gli stakeholders che ne fanno parte (dal team di Product alla Head di Localisation al traduttore esterno in Indonesia fino al QA seduto di sopra) possano possa fare il loro mestiere e che lo possano fare, idealmente, nel più facile e soprattutto scalabile dei modi in particolare in vista di un’espansione in un nuovo mercato.

Ma perché un’azienda dovrebbe essere interessata a interiorizzare un intero prodotto piuttosto che acquistare una soluzione B2B esterna? Beh, come in tante domande la risposta è: dipende. Le motivazioni più immediate che mi vengono in mente sono principalmente due:

1. In molte aziende ci sono tanti B2B SaaS tool che i team possono utilizzare e che risolvono almeno parzialmente il problema. Tuttavia, parecchi non sono molto complementari o non funzionano per tutti i casi d’uso o per i requisiti che il tal team ha necessità di risolvere;
2. Decisioni di policy aziendali interne relative al trattamento di dati (ritenuti) sensibili.

Vantaggio competitivo ne abbiamo?

Internalizzare e investire in determinati processi (soprattutto in ambito operations) può essere inoltre, in ottica strategica, un vantaggio competitivo ed una ulteriore fonte di guadagni sul lungo periodo. 

Un esempio virtuoso su tutti in questo caso può essere Amazon Connect, la soluzione contact center omnichannel di proprietà di Amazon lanciata nel 2017 e che ha come obiettivo la penetrazione in almeno una fetta di mercato, quello del servizio al cliente, dominato da forti player con soluzioni sì robuste ma anche parecchio costose. 

Giocando sul fattore di prezzo (più economico) e sull’enorme esperienza validata lungo i 10 anni precedenti in cui la soluzione è stata internamente sviluppata, Amazon è stata in grado di creare un extra revenue touchpoint che mira a portare la medesima flessibilità ora anche altrove. 

Le sfide

Le più grandi sfide a questo livello sono essenzialmente quattro:

1. Creare il business case
2. Priorizzazione rispetto ad altri progetti o features customer-facing 
3. La discovery
4. Il dovere di build for scope

Nascita del business case 

Come nasce un business case in questo caso?

E’ un’area in cui generalmente il product manager necessita di applicare una buona dose di strategia e due di motivazione (il motivo lo vedremo tra un attimo) per raggiungere il Sacro Graal dalla forma di consenso necessario e sufficiente da parte del management.

La criticità in questo caso è soprattutto nelle relazioni che dovrai instaurare con gli stakeholders per cui il tool dovrà essere fornito: tutti ne avranno bisogno ma pochi avranno davvero la voglia materiale di sedersi con te regolarmente e investire del tempo in interview faccia a faccia per un tool con così poca visibilità e così poco “sentito”.

Per dare un esempio brutale: la ragazza di Customer Service magari già oberata di cose da fare nella giornata (e con KPI molto severi) ci vedrà veramente poca utilità nell’implementazione del feature A o B. Il tuo lavoro non le cambia la vita (o meglio, non sembra che le cambi la vita), a differenza magari dell’utente della app stessa a cui invece puoi seriamente fare tutta la differenza del mondo.

A differenza degli utenti esterni (per così dire “standard”) i tuoi saranno letteralmente seduti accanto a te e nella peggiore delle ipotesi dovrai pure passarci diverse ore al giorno insieme, con relative situazioni strane al primo no che dirai o al primo feedback non esattamente positivo.

Tali relazioni (positive) però assicurati di cementificarle, di passarci molto tempo faccia a faccia e assicurarti di portare la loro voce (e i loro dati) con te al tavolo delle contrattazioni. Quale problema hanno e come pianifichi di risolverlo con la tua soluzione interna?

In molti casi queste “seconde voci” possono davvero fare la differenza tra successo e fallimento e possono inoltre aiutarti, dati e metriche alla mano, a quantificare (anche in termini monetari) e portare di fronte alla audience che conta i perché le risorse o i team X o Y stiano al momento performando ben al di sotto delle loro reali potenzialità.

Priorizzazione rispetto ad altri progetti o features customer-facing

Ok, ce l’hai fatta. Hai fatto breccia nei cuori e nei portafogli di chi siede nella stanza dei bottoni, hai l’ok e il batti cinque di tutti e fuori c’è una splendida giornata di sole che la seconda non ce n’è. 

Ora però come competi in termini di priorizzazione con progetti e feature ad alta visibilità come può essere lo sviluppo di una feature ad alto impatto in termini di revenue?

In un mondo ideale, la cosa migliore sarebbe naturalmente avere anche solo un piccolo team dedicato, che possa allontanarsi da certe dinamiche e che ti permetta di priorizzare rispetto ad altre iniziative a loro volta interne, minimizzando il rischio di venire inghiottito da altri progetti customer-facing o con una maggiore visibilità sulla leadership. 

Senza questo “ambiente protetto” c’è oggettivamente il rischio che l’internal tool rimanga sempre “tiepido”, vale a dire una cosa che non risolve DAVVERO il problema a nessuno, o almeno non completamente e che finisce per perdere lo slancio e in un attimo il morale va sotto i piedi (già ce la vedi eh la gente dire “ah è quel tool che sono 2 anni che è stato presentato e..… meh.”).

Discovery

In termini di Discovery trovo che almeno a livello di accessibilità sia parecchio più facile, in particolare rispetto ad altri contesti B2B dove magari trovi un po’ di ostilità da parte dell’account manager di turno che vuole farne una cosa in presenza (sua), il che non è mai il massimo della libidine. La disponibilità “fisica” per così dire è semplice, ti basta guardarti attorno e applicare le più comuni pratiche per lo stakeholders management che abbiamo coperto di recente.

Piu facile a dirsi che a farsi, perché il rovescio della medaglia è che… sì, già l’ho menzionato poco sopra: il fatto che possano essere molto molto occupati e che l’ultima o penultima cosa che vogliano fare sia una sana sessione di D&R “Parlami dell’ultima volta che hai fatto X”. 

Quindi in termini generali trovo che da un certo punto di vista sia più semplice mentre dall’altro si tratta di un fine bilanciamento tra chiedere “favori” e prendere ulteriore prezioso tempo dalle loro giornate dopo i primi sorrisi e disponibilità iniziali.

In termini visuali, consiglio di partire da un buon esercizio di user journey mapping che parta dalla radice del problema da risolvere (o del job to be done) e segua passo per passo la vita dell’utente lungo il prodotto.

L’idea di base è che al termine tu riesca a completare un esercizio quasi narrativo da sinistra a destra lungo il flusso lavorativo che riesca in ultimo a riassumerne la complessità, le inefficienze e soprattutto le dependencies da altri moduli/sistemi interni (problema che coprirò nella prossima sezione).

Bonus point è anche il fatto che, se fatte bene, mappe visuali di questo tipo possono essere inoltre usate per l’onboarding di nuove figure nel team!

Build for scope

Fondamentale è la possibilità per il team di Prodotto interno di aggiungere moduli e nuove feature mano a mano che la user base cresce o nuovi problemi necessitano di venire risolti, senza che questi però influiscano sulla performance e affidabilità.

Assicurati quindi che vi sia una forte architettura, e che ogni nuovo modulo possa venire agilmente aggiunto mano a mano che un nuovo business requirement verrà presentato e cerca di pensare ogni volta che un componente viene rilasciato a quali altri casi d’uso possa essere utile o ancora come possa venire riutilizzato/condiviso in altre iniziative.

In conclusione

Il livello di ammmuore e attenzione che puoi dare ad un prodotto interno e direttamente correlato alla capacità sia tua che della tua organizzazione di realizzarlo. Le aziende più grandi e strutturate potranno permettersi un team dedicato, cosa che purtroppo può non essere per la realtà più piccola o una startup.

Non lasciare tuttavia che questo ti impedisca di creare un prodotto in modo intelligente e che faccia quello per cui la figura del product manager è nata: risolvere problemi. Lavora a stretto contatti con i tuoi stakeholder e presenta una vision che miri a risolvere problemi senza inutili sforzi nel lungo periodo e che al contempo aiuti a creare continuamente nuove opportunità di sviluppo.

E tu? Qual è la tua esperienza con i tool interni?