👋 Ciao, sono Sara! Questo è Prodotti per Davvero, dove scopriamo com’è costruire un prodotto digitale, intervistando chi lo fa sul campo.
Questa prima stagione contiene 6 interviste + 6 articoli che riassumono i concetti chiave che vediamo con gli ospiti.
Questa è la quinta (e penultimaaaa) puntata con Marcello Majonchi, Head of Product in Arduino. Iniziamo!
🎧🎧🎧
Ascolta intervista su Substack,
sul canale YouTube di Belka o su Spotify.
Product Management tra Europa e US
Per Marcello negli Stati Uniti il ruolo di product manager è formalizzato, riconosciuto, con una popolazione di professionisti ampia e un ecosistema consolidato attorno ad esso. In Europa — e in Italia in particolare — quella figura spesso non esiste in forma pura.
Chi risponde agli annunci di PM viene per lo più da due provenienze: il project manager, figura che ha consegnato progetti on-time&on-budget, o il category manager, figura che ha posizionato prodotti sul mercato. Entrambi i background hanno una certa trasferibilità nel mondo del prodotto, ma non sono la stessa cosa.
La differenza che Marcello usa per spiegarlo al suo team è quella tra consulente e product manager. Il consulente raccoglie requisiti, li analizza, fa scope e li consegna all’engineering. Il product manager parla con molti clienti, cerca i bisogni comuni, definisce come risolverli e costruisce un prodotto che vale per N clienti, non per uno. In Italia per Marcello ci sono tanti product manager che in realtà fanno da “consulenti” con i propri CPO/CEO nelle aziende in cui lavorano.
Perché succede questo? Per Marcello il motivo storico è abbastanza chiaro: il prodotto tecnologico come lo conosciamo — digitale, agile, iterativo — è nato prevalentemente oltreoceano. In Italia c’è una lunga tradizione di prodotto fisico — automotive, elettronica di consumo, appliances — ma quei cicli erano lunghi e il waterfall non era solo una scelta metodologica: lo imponeva il materiale stesso.
“Non puoi fare hardware agile perché non lo permette fisicamente il materiale.”
— Marcello Majonchi
Fare prodotto quando c’è anche l’hardware di mezzo
Combinare hardware e software è storicamente difficile, e non è solo un problema italiano.
C’è un pattern che si è ripetuto nel tempo: i giapponesi, bravissimi sull’hardware, hanno sempre faticato a fare software competitivo. Gli americani, eccellenti sul software, hanno faticato col manufacturing fisico. I cinesi hanno replicato lo stesso schema qualche decennio dopo.
L’Italia si trova in una posizione di mezzo: c’è cultura del fisico, c’è cultura del digitale, ma manca la capacità di scalare entrambi alla velocità e all’ampiezza dei competitor americani e orientali.
Quello che però è cambiato negli ultimi trent’anni è il peso relativo dei due mondi. Marcello lo spiega con un esempio semplice: il suo primo computer era in gran parte hardware, con software relativamente elementare. Un iPhone oggi è l’opposto — hardware ancora sofisticatissimo, ma la complessità del software l’ha superato di gran lunga. Il peso del valore si è spostato.
E questo ha una conseguenza diretta su chi fa prodotto: le sfide da gestire sono sempre più legate al software, anche quando il prodotto ha una forma fisica.
Roadmap: i piani sono inutili, la pianificazione è fondamentale
Marcello cita Eisenhower — “i piani sono inutili, ma la pianificazione è fondamentale” — e dice che si applica perfettamente al concetto di roadmap.
La roadmap è fatta per essere cambiata. Avere una roadmap monolitica che non si tocca mai è un controsenso in un contesto di prodotto digitale, dove puoi correggere la rotta velocemente. L’agilità di poter cambiare è un vantaggio, non una debolezza.
La condizione che rende tutto questo sostenibile è avere un processo molto solido. Non perché il processo ti salvi dagli errori, ma perché un processo solido ti permette di iterare velocemente senza perdere il filo di quello che stai facendo o testando. La roadmap può sembrare stabile anche quando non lo è — e quello è esattamente l’obiettivo: avere sempre il miglior prodotto possibile (o le miglior ipotesi) da sviluppare in ogni momento.
Poi Marcello distingue due fasi che richiedono approcci diversi:
Pre-lancio. Il challenge è definire il MVP nel modo più centrato possibile. Ma attenzione: MVP non vuol dire solo viable, vuol dire anche valuable. Il prodotto che lanci deve dare valore reale, piccolo ma diretto, al cliente che lo adotta — e deve validare non solo il prodotto in sé, ma la strategia. Deve trasmettere che quel valore crescerà nel tempo.
Post-lancio. Qui si entra nel ciclo di feedback. La parte importante non è fare esattamente quello che il cliente chiede, ma usare il feedback come input per un ciclo di analisi che permette di capire quale feature risolve davvero il problema. E rilasciare in modo atomizzato: scope piccoli, rilasci frequenti, validazione costante sul campo.
AI e prodotto: dove siamo davvero
Marcello lavora su IoT e sistemi embedded, e da questa prospettiva il tema AI si fa molto concreto — e molto più profondo di come viene raccontato di solito. Marcello ci racconta due problemi principali dell’AI dal suo punto di vista.
Il primo problema tecnico principale è che i sistemi di intelligenza artificiale sono per natura non deterministici: generano output su base statistica, mettendo insieme ciò che è più probabile che stia insieme.
Il mondo embedded su cui lavora Marcello è fatto di oggetti che non sembrano computer ma lo sono — il pannello della lavatrice, il sensore dell’airbag, il lettore del bancomat — e i microcontrollori che li fanno funzionare operano in modo deterministico: fanno una cosa sola, la fanno continuamente, e devono dare sempre lo stesso output allo stesso input. Se devo far scrivere all’AI del codice che deve comandare l’apertura di un finestrino, o gestire un sistema di automazione critico, ottenere un output “abbastanza affidabile” non è sufficiente.
In Arduino hanno fatto un test: hanno messo a confronto diversi provider AI per scegliere il motore dell’Arduino Assistant. Nessuno arrivava al 100% di affidabilità. Le performance variano. Hanno scelto la soluzione migliore disponibile (Anthropic nel loro caso), ma quella scelta è accettabile solo per un’area ben delimitata di casi d’uso.
C’è poi un secondo problema che riguarda tutti, non solo il mondo embedded: i modelli LLM perdono efficacia molto rapidamente nelle iterazioni successive. La capacità di fare refactoring e far evolvere il codice nel tempo crolla già alla terza o quarta iterazione. Per chi fa prodotto questo è un limite serio: la vita di un prodotto è fatta di centinaia di iterazioni.
Takeaway di Marcello:
Dove l’AI funziona già bene: prototipazione, sviluppo di un prodotto v1.0, esplorazione di soluzioni.
Dove non ha ancora risolto il problema: prendere quel v1.0 e portarlo a v1.2, v2.0, gestire l’intero ciclo di vita del prodotto.
Dove è ancora lontana: hardware. La distanza tra un prompt e un prodotto fisico finito passa per design del concept, UX fisica, ingegneria elettronica, meccanica, produzione. Non c’è un Lovable del mondo fisico ancora in orizzonte.
“Non vi sembra incredibile che in un mondo dove le catene di montaggio di tutto il mondo sono automatizzate, il 99% del software che fa girare il nostro mondo sia scritto artigianalmente?”
— Marcello Majonchi
Come riconoscere un buon product manager: una hard skill, una soft skill
Marcello chiude con quello che cerca quando assume un PM.
Hard skill: saper raccogliere segnali dagli utenti e trasformarli in requisiti di prodotto. Non tradurre una richiesta in un requisito funzionale — quello lo fa un analista. Ma trasformare molte richieste diverse in una feature che risolve il problema sottostante per più persone.
Soft skill: saper prendere decisioni senza avere tutte le informazioni necessarie per farlo in modo sicuro. Essere consapevole delle approssimazioni che si fanno e del rischio che ci si prende — e decidere comunque. Perché non decidere è, in sé, già una decisione.
Per valutare questa soft skill nei colloqui usava una domanda perfetta, che l’evoluzione tecnologica ha reso quasi inutile: “Vai all’Ikea, compri un mobile, arrivi a casa e nella scatola non ci sono le istruzioni. Cosa fai?”
Oggi la risposta ovvia è cercare online. Un tempo quella domanda ti metteva in una situazione con informazioni incomplete e ti chiedeva come ragioni, come decidi, come arrivi a una conclusione ragionata tenendo insieme quello che sai, quello che non sai e il rischio che ti stai prendendo.
Questo è tutto
Se questa newsletter ti sta dando spunti concreti, condividila con il tuo team e iscriviti per non perdere i prossimi contenuti.
E se vuoi scoprire perché il tuo prodotto non sta crescendo puoi prenotare 30 minuti gratuiti con Belka.
xx
Sara 👋
