Quando lo scoping non si verifica

Mi sono fidato un po' troppo. E me ne pento. Normalmente sono un PM eccessivamente sospettoso che fa molta due diligence quando dice di sì a un progetto di sviluppo prodotto.

Questa volta ho sbagliato. E ho dovuto ammetterlo e controllare i danni. Allora, cos'è successo?

La mia azienda utilizza una tassonomia, così come la maggior parte delle aziende tecnologiche che si affidano alla SEO. Questa tassonomia è fondamentale per molte decisioni aziendali e guida parte dell'esperienza del cliente.

Questo è il problema dei dati. Una volta che i dati validi entrano in un ecosistema digitale, tutti vogliono usarli. Quindi, se dovessi indovinare, ci sono circa 40 team a valle che utilizzano questi dati nella mia azienda. E questo è solo internamente.

E si applica nel prodotto che gestisco.

Detto questo, ho pensato che una piccola modifica alla tassonomia sarebbe stata trascurabile. La richiesta è arrivata dal team di vocabolario, tassonomia e ontologia che possiede l'elenco legale di termini e schemi. Quindi... come un ingenuo figlio di una pistola... ho detto di sì alla richiesta di semplificare l'interfaccia utente. Ho pensato che il team VTO avesse fatto l'ambito. Lo hanno fatto, ma non fino alla profondità necessaria per apportare con sicurezza questo cambiamento.

In sostanza, lo schema nell'interfaccia utente passerebbe da una struttura a 3 livelli fino a un singolo punto di dati di livello. Nel backend, l'intento era quello di attaccare i viticci nascosti a ciascun ramo.

Barra laterale: se non hai familiarità con le tassonomie , questo è probabilmente un mucchio di jibberish. Ma puoi pensarlo come un elenco di termini che aiuta a organizzare una raccolta di dati.

Il design e la funzionalità originali nell'interfaccia utente per l'applicazione della tassonomia richiedevano l'unione di diverse tabelle nel codice. Ma quando il team VTO ha richiesto il singolo punto dati, sono andato avanti e ho detto ai miei ingegneri di eliminare il codice più complesso e utilizzare solo la singola tabella.

Avanti veloce a una demo con alcuni dirigenti. Ho mostrato loro la funzionalità pensando che sarebbero stati entusiasti dell'idea che i loro dipendenti (i miei utenti) non avrebbero avuto un carico cognitivo elevato mentre stavano creando il loro design didattico. Questa funzionalità ha semplificato l'esperienza dell'utente. Ma con mio sgomento, hanno rifiutato l'idea e hanno detto molte cose del tipo: "Temo che questo avrà un impatto sulla ABC".

Sebbene abbia semplificato l'esperienza dell'utente, potrebbe anche avere un impatto significativo su un modello di machine learning. Ciò si tradurrebbe nella nostra azienda che perde migliaia e migliaia di dollari.

Fortunatamente, non avevamo rilasciato la funzione. Faccio SEMPRE una demo di qualcosa prima del rilascio se si tratta di un importante aggiornamento dell'interfaccia utente. E per fortuna i dirigenti hanno parlato.

Questo mi ha portato a fare ulteriori indagini che hanno dato a me e al mio team alcune opzioni. Tuttavia, non è stato facile dire al povero ingegnere che ha lavorato così instancabilmente a questo progetto che probabilmente avrebbe dovuto annullare le sue modifiche. E speravamo di farlo uscire entro la fine dell'anno. Non sta succedendo. (Indica la musica del trombone più basso.)

Fa schifo. Questa è la realtà di essere un product manager, però. A volte falliamo. E dobbiamo ammettere quel fallimento.

Ma viviamo per vedere un altro giorno. O un'altra versione di funzionalità.