Per sapere quando fermarsi

Sapere quando fermarsi è uno dei momenti più complicati nello sviluppo di un prodotto software che si verifica dopo che una startup ha superato le sue fasi iniziali.

Assisto spesso a una realtà cupa in cui un prodotto di successo, che ha assicurato più risorse per il suo continuo sviluppo, inizia ad espandere rapidamente il proprio team. Ciò è comprensibile, poiché il piccolo team originario non aveva la capacità di implementare tutti gli aspetti importanti del progetto e l'aumento dei finanziamenti è destinato a risolvere questo problema.

Dopo l'espansione e l'assunzione di nuove persone, le cose tendono ad andare bene per un po'. Un nuovo, impressionante e più grande team di sviluppo è finalmente in grado di affrontare tutti i compiti attesi da tempo. Tuttavia, con l'espansione del team di sviluppo, nasce la necessità di espandere anche il team di gestione del prodotto.

Questo crea una trappola significativa. Una volta che il team ha la capacità di affrontare tutti i compiti necessari, il team di gestione inizia ad affrontare tutti i punti deboli con nuove risorse. Tuttavia, una volta completate tutte le attività critiche, i nuovi piani e le roadmap potrebbero non essere ancora disponibili. Nonostante questo, c'è spesso una forte necessità di fornire urgentemente nuovi compiti al team di sviluppo.

Inoltre, hai un gruppo di product manager appena assunti che hanno saldato con successo tutti i debiti di prodotto in sospeso. Mentre attendono con impazienza la prossima sfida significativa, iniziano a raccogliere idee per ulteriori miglioramenti al prodotto già ben funzionante.

In questa fase, il team deve spesso affrontare una carenza di metriche adeguate e metodologie di sperimentazione, che non hanno ancora implementato. Inoltre, è risaputo che valutare l'influenza di una singola funzionalità su una metrica di prodotto di primo livello può essere impegnativo. Di conseguenza, nuove funzionalità possono essere aggiunte semplicemente "perché ci piacciono" e non hanno alcun impatto negativo sul prodotto.

Quindi questa volta il prodotto inizia a cambiare senza motivo. Gli scenari utente, che rendono caro il nostro prodotto agli utenti, vengono alterati, con conseguente confusione tra gli utenti. L'interfaccia diventa ingombra di "campane e fischietti" che rendono difficile la comprensione.

Il prodotto un tempo intuitivo e familiare, che soddisfaceva efficacemente le esigenze dell'utente, si trasforma in un pasticcio confuso di funzionalità non necessarie che oscurano lo scenario di valore primario.

Pertanto, gli utenti potrebbero non essere più in grado di utilizzare lo scenario principale, che una volta era la caratteristica principale del prodotto. Solo perché i product manager non hanno niente da fare.

E poi tutti notano il calo della fidelizzazione e cercano di "aggiustarlo" inviando tonnellate di notifiche push...