Da sviluppatore a Technical PM: non pensavo mi sarebbe piaciuto così tanto

Quando ho iniziato a scrivere codice, non avevo in mente altro che fare bene quello. Javascript, componenti, CSS che si rompeva solo su Safari. Milano fuori dalla finestra e la musica nelle cuffie.

Poi… un giorno mi son trovato a non scrivere più codice, ma a scrivere task. A gestire un team. A prendere decisioni di progetto.
E no, non è stato un passaggio lineare né sempre comodo.
Ma è stato uno dei cambiamenti più importanti della mia carriera.

Il bello (e il brutto) di essere un Technical PM

Un PM tecnico è un po’ come stare in mezzo: capisci gli sviluppatori perché lo sei stato, ma capisci anche il business perché devi.

Non sei lì per “comandare”, sei lì per connettere: il perché dell’azienda con il come del codice.

E no, non serve essere il miglior dev della stanza.
Serve parlare il linguaggio giusto al momento giusto.
A volte in call con il marketing, a volte mentre si discute di caching strategy con gli sviluppatori.

Il progetto che ci ha messo alla prova

Un progetto vero, complesso: migrazione di un e-commerce da un monolite a un’architettura headless.

Tech stack:

• Nuxt 3 per il frontend
• Contentful per i contenuti
• Algolia per la ricerca
• Commerce Layer per la parte ecommerce
• Agile Scrum come metodo

Il bello?
Gli stakeholder erano molto esigenti e una deadline bloccata per esigenze business,

Le prime settimane: ascoltare, non correre

La prima cosa che ho fatto?
Non aprire Jira.

Ho parlato con:

• chi conosceva il vecchio sistema,
• chi scriveva i contenuti,
• chi voleva il sito “bello e veloce”.

Solo così ho capito davvero cosa serviva.
E ho costruito fiducia, che in questi progetti è oro.

Poi abbiamo fatto ordine: una vision, principi tecnici chiari, un backlog con storie utente ben scritte e una Definition of Done sensata.

Agile, ma per davvero

Sprint ogni 2 settimane, daily brevi (niente riunioni-fiume), review con demo vere, retrospettive con momenti umani.
Ah, e sì: backlog ordinato e aggiornato, altrimenti tutto crolla.

Un esempio di storia utente?

Come [content editor],
voglio [vedere l’anteprima],
affinché [possa sistemare il layout prima di pubblicare].

Banale? Forse.
Ma senza questi dettagli, il dev implementa una preview che non serve a nessuno.

Decisioni tecniche: fatte insieme

Non ho mai detto “si fa così perché l’ho deciso io”.

Abbiamo fatto workshop tecnici veri.
A volte ho spinto per una soluzione, altre volte ho lasciato che fosse il team a decidere.
Spoiler: il team spesso ha avuto ragione.

Alcuni punti chiave:

• cache stratificata
• modelli flessibili in Contentful
• ambienti separati per preview e pubblicazione
• pattern d’integrazione con Algolia

E sì, un po’ di debito tecnico lo abbiamo accettato, ma consapevolmente.

E poi?

Il progetto è uscito.
Bene o male, in tempo. E funzionava - si qualche bug da sistemare, ma c’eravamo.

Ma soprattutto: il team era soddisfatto.
Abbiamo imparato cose nuove, affrontato crisi, trovato soluzioni. Insieme.

Qualche consiglio se vuoi fare il salto da dev a PM

• Non smettere mai di imparare (soprattutto soft skill)
• Parla con tutti, ascolta tanto
• Sii chiaro e umano
• Ricorda che dietro ogni Jira task c’è una persona
• Celebra i successi, anche quelli minuscoli

Non pensavo mi sarebbe piaciuto fare il PM.
Avevo paura di “allontanarmi” dal codice.

Ma ho scoperto che, in realtà, sto ancora costruendo cose.
Solo che ora costruisco team.

E in fondo… è un po’ come refactorare un legacy project.
Solo che il codice è fatto di persone.