Perché prototipo in codice
La maggior parte dei PM non scrive codice. Non è un problema. Il product management non richiede di saper programmare. Ma se sai farlo, cambia il modo in cui prendi decisioni.
Non parlo di scrivere funzionalità in produzione. Parlo di costruire la cosa minima necessaria per rispondere a una domanda prima di chiedere al team settimane di lavoro.
CasaHunter: quando il codice mostra l'architettura
Un esempio recente. Serviva un appartamento in affitto. 8 portali, filtri inadeguati, nessuno che notificasse quando usciva qualcosa di buono. Il primo istinto da PM: mappare il problema — fonti, criteri, flusso. Il secondo istinto: aprire l'editor e costruire uno scraper.
In un weekend, un sistema funzionante che raccoglieva annunci da 8 fonti e li deduplicava. Ma il problema interessante non era lo scraping. Era lo scoring. Come capire se un annuncio è buono?
La prima versione mandava tutto a un LLM. Funzionava. Costava troppo e non migliorava la qualità sopra una certa soglia. Ristrutturazione: primo passaggio deterministico che filtra l'80% del rumore gratuitamente, secondo passaggio AI solo sul 20% che sopravvive. Terzo passaggio adattivo sui feedback.
QubicaAMF: leggere l'API che nessun altro leggeva
In azienda succede la stessa cosa su scala diversa.
In QubicaAMF un centro stava per cancellare l'integrazione pagamenti. Il problema: ogni transazione appariva come "uncategorized income" in Square. Nessuna attribuzione per terminale, nessun modo di chiudere i libri. La diagnosi interna era "problema del partner". Insolubile.
La documentazione dell'API raccontava un'altra storia. Tracciando il data model è saltato fuori un campo esistente, external_payment_type, che poteva portare l'attribuzione senza cambiare niente sull'architettura di nessuna delle due parti. La spec di implementazione ha chiuso la discussione. Il centro è rimasto ed è diventato un account di riferimento.
Questo non è lavoro da ingegnere. Non si tratta di scrivere codice di produzione. Si tratta di sapere dove cercare — e quello viene da anni a leggere documentazione tecnica e scrivere codice. Quando un PM sa muoversi dentro un'API, la conversazione con l'engineering cambia. Non "dobbiamo risolvere questo problema." Ma "questo campo dell'API potrebbe risolvere il problema, ecco una spec, cosa ne pensate?"
LeadsBridge: risolvere la causa, non il sintomo
In LeadsBridge il flusso di configurazione dei bridge generava errori a ripetizione. Ogni errore diventava un ticket di supporto. Il team cresceva e il supporto cresceva con lui. La richiesta: costruire un chatbot.
Il funnel raccontava un'altra storia. Il problema non era il volume di ticket. Era il flusso multi-step che generava errori. La soluzione non era gestire il volume. Era eliminare la causa.
La stessa conclusione sarebbe arrivata senza saper leggere il codice? Forse. Ma avrebbe richiesto più tempo, qualcun altro avrebbe dovuto fare l'analisi, e proporre un redesign del flusso core del prodotto avrebbe avuto meno credibilità. "Ho guardato il codice e il problema è qui" fa partire la conversazione da un punto diverso rispetto a "credo che il problema potrebbe essere nel flusso."
Il rischio del PM che programma
C'è un rischio. Un PM che sa programmare può cadere nella trappola di voler costruire tutto. Di sentirsi indispensabile per ogni decisione tecnica. Di non delegare.
È un rischio reale. La risposta non è smettere di programmare. È sapere quando è il momento di scrivere codice e quando è il momento di scrivere un brief e dare fiducia al team.
Accumulo, non errore
Il punto non è che tutti i PM dovrebbero programmare. Il punto è che un percorso — designer, poi developer, poi PM — non è stato un errore di carriera. È stato un accumulo di strumenti.
Un problema di prodotto visto da tre angolazioni contemporaneamente: come appare all'utente, come funziona sotto il cofano, e cosa significa per l'azienda. Non perché lo dice un framework. Perché quei tre lavori li ho fatti.
A volte la soluzione è nel design. A volte è nel codice. A volte è nel dire "no" a qualcosa che tutti vogliono. La capacità di prototipare non è la risposta a tutto. Ma è uno strumento in più nel momento in cui serve. E quando serve, fa la differenza tra indovinare e sapere.