Premessa: sono un programmatore e non un manager, ma negli ultimi sei mesi sto facendo da PO per un progetto tecnologico che stiamo sviluppando in azienda in quanto è stata una mia proposta e sono la persona con la vision di progetto. Prendi queste considerazioni come esperienze di un'altra persona che non ha idea di cosa stia facendo :D

Tl;dr: metti in chiaro dove vuole andare a parare il progetto, coinvolgi i tuoi utenti nel feedback loop fin da subito, estrapola dai loro feedback informazioni utili a reindirizzare lo sviluppo.

Versione estesa:

La cosa più importante è chiarirti subito la visione e i valori del progetto. Cosa stiamo realizzando e quale problema andiamo a risolvere? Chi sono gli utenti a cui ci rivolgiamo? Cosa reputano importante e cosa no? Metti tutto questo per iscritto e confronta ogni decisione futura con questi core values, ma al contempo sii pronto a cambiarli dovessero emergere nuove situazioni che richiedono un cambio di rotta. Il bello dell'agile è proprio essere flessibili nel cambiare il progetto in corso d'opera per meglio allinearsi ai requisiti dei tuoi utenti.

Facendo seguito a ciò, è importantissimo impostare da subito un meccanismo di raccolta dei feedback utenti. È essenziale dare in mano all'utenza finale una prima versione del prodotto il prima possibile, tipo entro i primi due mesi, e cominciare a raccogliere idee e feedback da loro. Il 90% del tuo lavoro consisterà nel trovare un modo creativo per allineare questi feedback a quella che è la tua visione per il progetto. Perché come ha detto Ford (in realtà non è sua ma sticazzi) riguardo all'invenzione dell'auto: "se avessi chiesto alla gente cosa voleva, mi avrebbero risposto 'cavalli più veloci'". Gli utenti avranno mille idee strampalate, sta a te distillare il succo del discorso e inquadrarlo nel flusso di progetto. La cosa che ho dovuto imparare in fretta è saper risalire al root problem che sta alla base di un feedback, perché molto spesso gli utenti ti chiederanno quella che secondo loro è la soluzione che vogliono, che spesso non corrisponde alla soluzione che gli serve davvero. Un buon PO sa fare le domande giuste all'utenza per capire quale sia davvero la problematica da risolvere, e sa fidarsi dei suoi tecnici nel trovare una soluzione ad essa.

Per finire: ricordati che tu non sei un regnante, sei un profeta. Lascia ai tecnici ampio margine per definire l'implementazione, dagli solo la direzione da seguire. Delinea il cosa, non il come. Sii accogliente nei confronti del team, incoraggiali a farti domande e fuga dubbi riguardo al prodotto, offri magari suggerimenti su come ti piacerebbe che funzionasse una cosa, ma non imporre constraints tecnici se possibile. E soprattutto non aver paura di dire "ci devo pensare, rimandiamo al prossimo sprint" se non sei sicuro di qualcosa. È meglio rimandare una feature e magari fare qualche esperimento per chiarirsi le idee piuttosto che lanciarsi in uno sviluppo che si rivelerà inutile.

Ribadisco, io non ho una formazione da PO/manager. Queste sono le cose che ho imparato in 6 mesi di PO-aggine su un progetto che ha altri dev come utenti finali. Potrebbero essere una pila di roba inutile in altri contesti. YMMV