Product Thinking per i team di dati

Hai mai affrontato una qualsiasi delle situazioni nella tua organizzazione?

• I livelli C o la leadership senior hanno scoperto che i dashboard critici per l'azienda non vengono aggiornati per un po 'in una riunione critica
• Il product manager, il consumatore di dati , informa il team di analisi dei dati, il produttore di dati , che i data mart non sono stati aggiornati negli ultimi n giorni
• Il team di ingegneria del software ha modificato lo schema del database di produzione e si è dimenticato di informare il team di ingegneria dei dati di aggiornare i propri eventi consumer su una sperimentazione critica di Growth Hacker

La spiacevole realtà

Nei miei articoli precedenti ( questo e questo ) ho cercato di stabilire una base per i prodotti di dati. Questi prodotti vengono creati dai team di produttori di dati (team di dati centrali e team di produttori di dati di dominio) e utilizzati da vari consumatori (team di marketing e data science o utenti finali). Sulla carta va tutto bene, vero?

Ehhh la realtà è un po' diversa. Anche se si è tentati di utilizzare il termine "Prodotti di dati" per tutti i casi d'uso che ci circondano, la realtà è che la maggior parte dei casi d'uso sono "Progetti di dati".

Ma qual è la differenza tra un prodotto dati e un progetto dati? Per rispondere a questa domanda bisogna capire le differenze tra un prodotto e un progetto!

Prodotto vs Progetto

Mi piacciono molto le descrizioni create da Futurice ;

Un prodotto ; potrebbe essere un software o un servizio, ma mira a soddisfare un'esigenza specifica e richiederà manutenzione e aggiornamenti continui. I team di prodotto, quindi, rimangono insieme a lungo termine per ideare, costruire ed eseguire il prodotto. A differenza dei progetti, che riguardano il risultato, i prodotti riguardano il viaggio. Non esiste un endpoint noto e i partecipanti stanno imparando mentre procedono. Con un prodotto, non sai mai quando finirà ogni fase del ciclo di vita, ad esempio quando passerai dalla sperimentazione alla crescita. Anche se tutto sembra prevedibile nella fase di maturità, non sai quando ci sarà un'interruzione. Non puoi controllare il ciclo di vita del prodotto; tutto quello che puoi fare è cercare di prepararti al cambiamento.

Un progetto ; d'altra parte, è un modo di eseguire un'idea. In termini pratici, con un progetto, devi capire molte cose prima di iniziare: quanto tempo, denaro e persone hai a disposizione, la qualità prevista e tutti gli altri vincoli e driver durante l'esecuzione del progetto. Tutto ciò deve essere delineato nell'ambito. Un progetto è estremamente focalizzato sull'esecuzione: se consegni in ritardo o oltre il budget, di solito non è un successo anche se la tua storia dice diversamente. I progetti sono temporanei con un inizio definito, una o più pietre miliari e una scadenza fissa. Quando il progetto è finito, i membri del team se ne vanno e iniziano un nuovo progetto. I progetti presuppongono un ambiente prevedibile per iniziare e avere successo e la pianificazione è una parte essenziale del processo.

Sulla base di queste descrizioni forniamo esempi di progetti dati e prodotti dati;

• Prodotto dati: creazione di un sistema di motore di raccomandazione per il tuo sito Web di e-commerce per migliorare la personalizzazione e il coinvolgimento dei clienti. I clienti interagiscono con i tuoi consigli, raccogli punti dati e migliori i tuoi modelli. Questo non finisce.
• Progetto dati: sviluppo di un rapporto ad hoc per i livelli C che abbia una chiara spiegazione e obiettivi e sai che questo non si ripeterà più in futuro! Consegni il rapporto alle 21:00 e il progetto è finito!

Product Thinking per principianti

Nel suo articolo, "Product Thinking 101" , Naren Katakam fornisce ottime spiegazioni ed esempi sul pensiero del prodotto. Secondo Naren;

Il pensiero del prodotto è il viaggio dallo spazio dei problemi degli utenti allo spazio delle soluzioni dell'azienda. L'obiettivo di questo viaggio è ridurre il divario tra gli utenti e l'azienda.

Nel mondo dei dati, i nostri utenti, clienti o stakeholder potrebbero pensare di conoscere il meglio e chiederci di fornire ciò che desiderano; ad es. relazione ad hoc a livello dirigenziale. Può essere allettante consegnare l'argomento dato perché non è necessario effettuare ulteriori investimenti nella ricerca sullo spazio del problema e hai già una soluzione in mente. Non farlo! Non essere la persona dei dati che guida le parti interessate a Jira per creare un ticket di dati!

Ci sono molte altre trappole in cui potresti cadere e metodi per evitarle;

Inizia con il problema non la soluzione

Ogni viaggio nel prodotto inizia con una chiara comprensione del problema dell'utente. Il problema dell'utente dà forma al tuo prodotto. Più domande fai, più dati raccogli e più chiaramente il percorso si rivela.

Un errore comune è pensare alle soluzioni finali e ai prodotti negli stati intermedi senza definizioni adeguate del problema e KPI ad essi collegati. Come ha menzionato Ash nel suo articolo, "Ama il problema, non la tua soluzione" .

Evita di essere una fabbrica di funzionalità

Il termine fabbrica di funzionalità si riferisce alle aziende che sfornano funzionalità per il loro software o prodotto in modo coerente. Il termine è generalmente usato negativamente per descrivere le aziende che apprezzano la quantità rispetto alla qualità. Nel tentativo di aumentare il numero di cose che un prodotto può fare, il prodotto alla fine diventa sfocato e gonfio. Le funzionalità vengono aggiunte solo per aggiornare continuamente e generare clamore per il prodotto piuttosto che per aggiungergli valore.

Ma come succede? In che modo il team del prodotto o l'organizzazione non hanno potuto scegliere le funzionalità importanti?

• Effetto HIPPO : HIPPO è un acronimo e sta per H ighest Paid P erson's Opinion . L'effetto afferma che l'opinione della persona più pagata viene presa in maggiore considerazione in una decisione perché ha un valore più alto di per sé. La questione dell'opinione è quindi legata alla retribuzione della persona che esprime tale opinione. Più alto è lo stipendio, più critica è l'opinione.
• Cercare di accontentare tutti: quando non esiste una metodologia centralizzata per dare la priorità a iniziative e funzionalità, la visione del tuo team di dati non è chiara e i tuoi stakeholder ti stanno facendo pressioni per consegnare le cose, puoi perdere tutto il tuo potere di controllare le cose e iniziare a soddisfare tutti. Alla fine della giornata, costruisci cose inutili che nessuno usa.

La scoperta continua è un approccio alla ricerca degli utenti utilizzato nei team agili in cui la ricerca viene condotta come attività piccole e frequenti durante l'intero ciclo di vita dello sviluppo del prodotto . Ciò infonde il feedback dei clienti in tutte le decisioni sui prodotti invece di concentrarsi su un'attività di ricerca una tantum all'inizio di un progetto. Per ulteriori dettagli su questa metodologia, vi consiglio di leggere il libro di Teresa Torres .

La scoperta continua è una tecnica salvavita nello sviluppo del prodotto. Testiamo, raccogliamo dati, valutiamo i nostri risultati e iteriamo sulla nostra roadmap.

È probabile che tu fallisca se sviluppi progetti

Sei circondato da statistiche che dicono che il tuo progetto di dati fallirà;

• L'85% dei progetti di big data fallisce ( Gartner , 2017)
• L'87% dei progetti di data science non arriva mai alla produzione ( VentureBeat , 2019)
• "Fino al 2022, solo il 20% degli insight analitici fornirà risultati di business" ( Gartner , 2019)

Conclusione

Il pensiero del prodotto è una mentalità e una cultura che devono essere coltivate nei team di dati. Simile a qualsiasi cambiamento di mentalità, anche questo richiede tempo per essere abbracciato e applicato ovunque. Inizia in piccolo, scegli un team o un progetto pilota e inizia a trattarli come un team di prodotto. Raccogli quanto appreso, migliora e scala. Sembra Product Thinking sulla tua organizzazione, giusto? Se stai lottando per scoprire da dove cominciare, offri semplicemente un caffè ai tuoi amici ingegneri. Lo stanno applicando da 40 anni!

Grazie per aver letto

In questo articolo, ho provato a dare un'idea del Product Thinking for Data (Producer) Teams. Nel prossimo articolo, presenterò il giocatore di squadra chiave per i team di dati: Data Product Manager!