[{"data":1,"prerenderedAt":723},["ShallowReactive",2],{"has-blog-posts":3,"post-troppi-ruoli-una-persona-rischio":4,"related-troppi-ruoli-una-persona-rischio":190,"datemod-troppi-ruoli-una-persona-rischio":170},true,{"id":5,"title":6,"body":7,"category":169,"date":170,"description":171,"extension":172,"image":173,"meta":174,"navigation":3,"path":175,"published":3,"seo":176,"seoTitle":177,"slug":178,"stem":179,"tags":180,"updated":188,"__hash__":189},"blog/blog/2026-04-23-troppi-ruoli-una-persona-rischio.md","Troppi ruoli su una persona: il rischio organizzativo nascosto",{"type":8,"value":9,"toc":158},"minimark",[10,14,21,26,29,36,39,43,52,55,71,74,78,81,84,87,98,101,105,108,111,114,118,121,124,127,131,137,145,149,152,155],[11,12,13],"p",{},"Nelle aziende che sviluppano software c’è una situazione molto comune che viene spesso scambiata per un punto di forza: una persona sola tiene insieme tutto. Parla con lo stakeholder, decide cosa costruire, tiene il piano, guida le scelte tecniche, mette mano al codice quando serve. Se c’è un problema, lo risolve. Se serve decidere, decide.",[11,15,16,17,20],{},"Dall’esterno sembra una fortuna.",[18,19],"br",{},"\nDall’interno, è una fragilità.",[22,23,25],"h2",{"id":24},"non-è-un-problema-di-talento","Non è un problema di talento",[11,27,28],{},"La lettura più comoda è: “è una persona molto brava”. Quella meno comoda è: l’azienda non ha costruito le funzioni di cui ha bisogno e le ha scaricate tutte su chi riesce a reggerle. Quasi sempre è la seconda.",[11,30,31,32],{},"C’è un modo semplice per capirlo: se quella persona sparisce per una settimana, cosa succede? Non se qualcuno la chiama — quello succede sempre. La domanda è: ",[33,34,35],"strong",{},"le decisioni vanno avanti o si fermano?",[11,37,38],{},"Se si fermano, non hai una risorsa preziosa. Hai un collo di bottiglia.",[22,40,42],{"id":41},"il-problema-non-è-il-carico-di-lavoro","Il problema non è il carico di lavoro",[11,44,45,46,51],{},"Chi vive questa situazione spesso regge. Lavora tanto, si organizza, trova il tempo. Il problema è il tipo di attenzione richiesta, più che il numero di ore. Pensare al prodotto richiede un certo tipo di testa, gestire il progetto un altro, prendere decisioni architetturali un altro ancora, scrivere codice richiede concentrazione profonda. Non sono attività che convivono bene nella stessa giornata, e ogni volta che cambi contesto paghi un costo: non in tempo, ma in qualità. È lo stesso problema delle interruzioni: ",[47,48,50],"a",{"href":49},"/blog/ogni-interruzione-costa-23-minuti","ogni cambio di contesto costa più di quanto pensi",".",[11,53,54],{},"Quando tutto passa da una persona, succede questo:",[56,57,58,62,65,68],"ul",{},[59,60,61],"li",{},"il codice si scrive di corsa",[59,63,64],{},"le decisioni si prendono a metà",[59,66,67],{},"il prodotto si capisce superficialmente",[59,69,70],{},"la visione di lungo periodo sparisce",[11,72,73],{},"Non perché la persona non sia capace, ma perché sta facendo cinque lavori insieme.",[22,75,77],{"id":76},"il-tentativo-che-peggiora-le-cose","Il tentativo che peggiora le cose",[11,79,80],{},"A un certo punto l’azienda se ne accorge, e prova a “scaricare un po’ di lavoro”: arriva qualcuno a fare project management, oppure qualcuno sul prodotto. Sulla carta, il problema è risolto. Nella pratica, no.",[11,82,83],{},"Le riunioni si fanno, i report girano, i task sono tracciati. Ma le decisioni continuano a passare dalla stessa persona di prima, perché chi è entrato non ha mandato reale: gestisce la superficie, non la sostanza.",[11,85,86],{},"Risultato:",[56,88,89,92,95],{},[59,90,91],{},"la persona centrale continua a decidere tutto",[59,93,94],{},"in più deve aggiornare qualcun altro",[59,96,97],{},"chi è entrato capisce di non contare davvero e si adatta o se ne va",[11,99,100],{},"È peggio di prima. Hai aggiunto overhead senza togliere il collo di bottiglia.",[22,102,104],{"id":103},"delegare-davvero-è-scomodo","Delegare davvero è scomodo",[11,106,107],{},"Uscire da questa situazione è difficile per un motivo semplice: richiede fare cose contro-intuitive.",[11,109,110],{},"La prima è smettere di delegare quello che pesa di più e iniziare da quello che è più visibile. Molti partono dal codice, ed è un errore: il codice è ciò che ti tiene agganciato alla realtà. Le prime cose da lasciare sono le funzioni di coordinamento: gestione progetto, comunicazione, parte operativa del prodotto.",[11,112,113],{},"La seconda è accettare che chi prende in carico una funzione la farà diversamente. È qui che la maggior parte delle deleghe fallisce: se continui a correggere ogni decisione, non hai delegato, hai solo creato un passaggio in più. La delega inizia quando qualcuno prende una decisione che tu non avresti preso — ma è comunque sensata — e tu la lasci passare.",[22,115,117],{"id":116},"il-punto-vero-cosa-tieni-e-cosa-molli","Il punto vero: cosa tieni e cosa molli",[11,119,120],{},"Non devi distribuire tutto. Devi scegliere cosa tenere. Per chi ha costruito un prodotto tecnico, la cosa più difficile da delegare è quasi sempre la guida tecnica sul core. È normale.",[11,122,123],{},"Tienila.",[11,125,126],{},"Ma tutto il resto — progetto, coordinamento, parte di prodotto — deve uscire. Altrimenti non stai proteggendo il sistema: stai solo rallentando il punto in cui smetterà di reggere.",[22,128,130],{"id":129},"il-test-che-non-perdona","Il test che non perdona",[11,132,133,134],{},"C’è un modo semplice per capire se hai davvero risolto il problema: per una settimana, sparisci. Non completamente — non è quello il punto. La domanda è: ",[33,135,136],{},"quali decisioni verrebbero rimandate al tuo ritorno?",[11,138,139,140,144],{},"Se la risposta è “quasi tutte”, sei esattamente dove eri prima. Se sono poche, stai migliorando. Se tutto va avanti tranne quello che hai deciso consapevolmente di tenere, allora l’organizzazione sta funzionando. È il ",[47,141,143],{"href":142},"/blog/bus-factor-developer-indispensabile","bus factor"," applicato alle decisioni, non solo al codice.",[22,146,148],{"id":147},"il-punto-scomodo","Il punto scomodo",[11,150,151],{},"Se stai guidando un’azienda e hai una persona che copre tre o quattro ruoli, non sei fortunato. Sei esposto.",[11,153,154],{},"Finché quella persona regge, sembra tutto sotto controllo. Poi succede qualcosa di normale — ferie, stanchezza, cambio lavoro — e lì scopri che non avevi costruito un sistema: avevi costruito una dipendenza.",[11,156,157],{},"Il costo per sistemarlo è reale: assunzioni, affiancamento, un periodo in cui le cose rallentano. Il costo di non farlo arriva tutto insieme, e quando arriva non hai margine per gestirlo.",{"title":159,"searchDepth":160,"depth":160,"links":161},"",2,[162,163,164,165,166,167,168],{"id":24,"depth":160,"text":25},{"id":41,"depth":160,"text":42},{"id":76,"depth":160,"text":77},{"id":103,"depth":160,"text":104},{"id":116,"depth":160,"text":117},{"id":129,"depth":160,"text":130},{"id":147,"depth":160,"text":148},"Sviluppo","2026-04-23","Se una persona sola tiene insieme tecnica, progetto e prodotto, l'organizzazione accumula un rischio che non si vede finché non esplode.","md","/images/blog/troppi-ruoli-una-persona-rischio.jpg",{},"/blog/2026-04-23-troppi-ruoli-una-persona-rischio",{"title":6,"description":171},"Troppi ruoli su una persona sola: il rischio nascosto","troppi-ruoli-una-persona-rischio","blog/2026-04-23-troppi-ruoli-una-persona-rischio",[181,182,183,184,185,186,187],"gestione-team","leadership","delega","bus-factor","burnout","organizzazione","ruoli",null,"CmlSLXqSh8HZW2B1aHBu1T9turx2H7asgaUU47sY-Vs",[191,396,557],{"id":192,"title":193,"body":194,"category":169,"date":380,"description":381,"extension":172,"image":382,"meta":383,"navigation":3,"path":384,"published":3,"seo":385,"seoTitle":386,"slug":387,"stem":388,"tags":389,"updated":188,"__hash__":395},"blog/blog/2026-04-21-outsourcing-software-low-cost.md","Outsourcing software in India: perché finisce quasi sempre male",{"type":8,"value":195,"toc":369},[196,201,204,210,213,217,224,231,235,238,241,245,248,251,257,261,264,270,281,284,288,291,294,303,307,310,314,317,323,326,329,343,347,354,358,361,366],[11,197,198],{},[33,199,200],{},"\"Abbiamo trovato un team in India che fa lo stesso lavoro a un terzo del costo.\"",[11,202,203],{},"L'outsourcing software low-cost — con l'India in testa, ma non solo — è una tentazione ricorrente: negli ultimi vent'anni, questa frase ha dato il via a centinaia di progetti. Molti sono partiti con entusiasmo. Molti, dopo un anno, si sono ritrovati con codice che \"funziona\" ma che nessuno riesce più a toccare senza rompere qualcosa.",[11,205,206,207,51],{},"È un problema di ",[33,208,209],{},"modello organizzativo",[11,211,212],{},"Il modello delle software farm low-cost è costruito per produrre tanto codice, in poco tempo, al costo più basso possibile. Funziona bene quando il problema è scrivere task. Funziona molto meno quando il problema è rappresentare fedelmente il tuo business, far evolvere il software nel tempo e mantenerlo sano per anni.",[22,214,216],{"id":215},"come-funziona-davvero-il-modello","Come funziona davvero il modello",[11,218,219,220,223],{},"Lo schema è quasi sempre lo stesso. L'azienda vuole ridurre i costi di sviluppo, si affida a una software farm con molti sviluppatori, la comunicazione passa attraverso uno o due project manager, il team tecnico è numeroso, junior e intercambiabile, e l'incentivo principale diventa ",[33,221,222],{},"chiudere ticket velocemente",", non capire il problema a fondo.",[11,225,226,227,230],{},"Questo modello ha senso industriale. È pensato per scalare. Ma ha un effetto collaterale enorme: il codice prodotto è ",[33,228,229],{},"scollegato dal contesto reale del tuo business",". E quando il codice è scollegato dal contesto, diventa fragile.",[22,232,234],{"id":233},"il-vero-ostacolo-è-la-comunicazione","Il vero ostacolo è la comunicazione",[11,236,237],{},"Quando lavori con un team a migliaia di chilometri di distanza, con poche ore di sovrapposizione e una comunicazione mediata da documenti e task, succede una cosa prevedibile: le sfumature si perdono. Le conversazioni veloci diventano thread di email, i chiarimenti immediati diventano messaggi che ricevono risposta il giorno dopo, i requisiti vengono interpretati alla lettera e non nel loro intento. Nessuna malafede: è la conseguenza naturale del contesto.",[11,239,240],{},"Nel software, però, un requisito frainteso non produce una piccola differenza. Produce un comportamento completamente diverso da quello che ti aspettavi.",[22,242,244],{"id":243},"il-fuso-orario-impedisce-la-collaborazione-vera","Il fuso orario impedisce la collaborazione vera",[11,246,247],{},"Quando il tuo team lavora mentre tu dormi, e tu lavori mentre loro dormono, la collaborazione diventa asincrona forzata.",[11,249,250],{},"Scompaiono le sessioni di analisi fatte bene, le discussioni architetturali spontanee e i chiarimenti rapidi sulle decisioni ambigue. Resta uno scambio di documenti e ticket. Il software, però, nasce bene dal confronto continuo, non da una catena di passaggi intermedi.",[11,252,253,254,51],{},"Questo non rallenta solo il progetto. Peggio: ",[33,255,256],{},"impedisce al team di capire davvero cosa sta costruendo",[22,258,260],{"id":259},"il-vero-problema-nessuno-possiede-il-codice","Il vero problema: nessuno possiede il codice",[11,262,263],{},"Nelle software farm low-cost, il turnover è spesso alto. Le persone cambiano progetto, cliente, azienda. Dopo sei mesi, chi ha scritto quel modulo potrebbe non esserci più. Dopo un anno, può capitare che nessuno del team originale sia ancora sul progetto.",[11,265,266,267,269],{},"Il codice resta. La conoscenza no. È il problema del ",[47,268,143],{"href":142}," portato all'estremo.",[11,271,272,273,280],{},"È una versione amplificata del problema descritto in ",[47,274,276],{"href":275},"/blog/aggiungere-sviluppatori-progetto",[277,278,279],"em",{},"The Mythical Man-Month",": aggiungere persone non crea comprensione, crea frammentazione.",[11,282,283],{},"Quando quel software passa in mano a un nuovo team — interno o esterno — sembra scritto da qualcuno che non conosceva il tuo business. Perché, di fatto, è così.",[22,285,287],{"id":286},"perché-allinizio-sembra-funzionare","Perché all'inizio sembra funzionare",[11,289,290],{},"Nei primi mesi tutto fila liscio: le feature arrivano, i ticket si chiudono, il costo è contenuto. Sembra una scelta brillante.",[11,292,293],{},"Il problema emerge dopo, quando devi fare modifiche non previste, il business cambia oppure serve aggiungere una logica nuova che interagisce con quelle esistenti. È lì che scopri che il codice è una somma di task chiusi, non un sistema pensato per evolvere. E ogni modifica diventa un rischio.",[11,295,296,297],{},"È il momento in cui inizi a dire:\n",[47,298,300],{"href":299},"/blog/software-fragile-regressioni",[33,301,302],{},"\"Ogni volta che tocchiamo qualcosa, si rompe qualcos'altro.\"",[22,304,306],{"id":305},"un-problema-di-incentivi-non-di-geografia","Un problema di incentivi, non di geografia",[11,308,309],{},"Il modello non è esclusivo dell'India: esiste ovunque il lavoro venga organizzato con tanti sviluppatori intercambiabili, poca ownership, comunicazione filtrata e focus sulla velocità più che sulla comprensione — dall'Europa dell'est al Sud-est asiatico. Il risultato tende a essere sempre lo stesso: codice che fa quello che c'è scritto nel ticket, ma non quello che serve davvero al business.",[22,311,313],{"id":312},"perché-oggi-questo-modello-ha-ancora-meno-senso","Perché oggi questo modello ha ancora meno senso",[11,315,316],{},"Per vent'anni, il vantaggio competitivo delle software farm low-cost era semplice:",[318,319,320],"blockquote",{},[11,321,322],{},"tanto codice a basso prezzo.",[11,324,325],{},"Anche accettando inefficienze e fragilità architetturale, il conto tornava. Perché il collo di bottiglia era sempre lo stesso: servivano tante ore uomo per scrivere codice.",[11,327,328],{},"Oggi questo presupposto sta saltando: strumenti come Claude Code o Codex producono codice in minuti, senza fuso orario, senza incomprensioni linguistiche e a un costo marginale quasi nullo.",[11,330,331,332,335,336,342],{},"Il valore si è spostato: da ",[33,333,334],{},"chi scrive il codice al prezzo più basso"," a ",[47,337,339],{"href":338},"/blog/ai-impatto-business-software",[33,340,341],{},"chi sa decidere cosa scrivere, come strutturarlo e come farlo evolvere",". Ed è esattamente la parte che il modello low-cost non copre.",[22,344,346],{"id":345},"il-paradosso-umano","Il paradosso umano",[11,348,349,350,353],{},"C'è un paradosso che vale la pena riconoscere. Per anni questo modello ha funzionato perché il mercato chiedeva quantità di codice, e moltissimi sviluppatori hanno lavorato esattamente per soddisfare quella richiesta. Oggi la richiesta è cambiata — da \"scrivi questo ticket\" a \"capisci questo sistema\" — e la cosa ",[33,351,352],{},"per cui vengono pagati"," sta perdendo valore molto velocemente.",[22,355,357],{"id":356},"la-lezione-per-chi-commissiona-software","La lezione per chi commissiona software",[11,359,360],{},"Alla base di questo modello c'è un'idea pericolosa:",[318,362,363],{},[11,364,365],{},"che il software sia un problema di manodopera.",[11,367,368],{},"Finché sembrava vera, l'outsourcing low-cost in India aveva senso economico. Oggi si vede chiaramente che il valore non era lì. Il software riguarda comprensione del business, decisioni architetturali, comunicazione continua e responsabilità sul sistema nel tempo: cose che non si possono spacchettare in ticket da mandare dall'altra parte del mondo, e oggi non si possono nemmeno delegare a un'AI.",{"title":159,"searchDepth":160,"depth":160,"links":370},[371,372,373,374,375,376,377,378,379],{"id":215,"depth":160,"text":216},{"id":233,"depth":160,"text":234},{"id":243,"depth":160,"text":244},{"id":259,"depth":160,"text":260},{"id":286,"depth":160,"text":287},{"id":305,"depth":160,"text":306},{"id":312,"depth":160,"text":313},{"id":345,"depth":160,"text":346},{"id":356,"depth":160,"text":357},"2026-04-21","Outsourcing software in India a un terzo del costo: il modello produce codice scollegato dal business, con incentivi sbagliati. E con l'AI ha ancora meno senso.","/images/blog/outsourcing-software-low-cost.jpg",{},"/blog/2026-04-21-outsourcing-software-low-cost",{"title":193,"description":381},"Outsourcing software India: rischi e costi nascosti","outsourcing-software-low-cost","blog/2026-04-21-outsourcing-software-low-cost",[390,391,392,393,394],"outsourcing","scelta-fornitore","rischi-software","qualita","ai","AEWykOP8KGCSfFP_ZVMsctJkUIzP64BE-2BzD5c4QtU",{"id":397,"title":398,"body":399,"category":169,"date":541,"description":542,"extension":172,"image":543,"meta":544,"navigation":3,"path":545,"published":3,"seo":546,"seoTitle":547,"slug":548,"stem":549,"tags":550,"updated":188,"__hash__":556},"blog/blog/2026-04-02-budget-software-go-to-market.md","Hai speso tutto il budget nel prodotto. E nessuno sa che esiste",{"type":8,"value":400,"toc":527},[401,407,410,414,417,420,423,427,433,436,444,448,451,456,462,470,474,481,485,492,496,499,503,506,510,513,516,520],[11,402,403,406],{},[33,404,405],{},"Il prodotto è pronto. Funziona, è curato, è stato testato. Mesi di sviluppo, budget importante investito."," Poi arriva il momento del lancio e ci si rende conto che non esiste un vero piano per farlo conoscere. Concentrare tutto il budget nello sviluppo software e trascurare il go-to-market, cioè tutto ciò che serve per portare il prodotto davanti alle persone giuste, è un errore comune: il risultato è un prodotto valido che non genera utenti, perché nessuno sa che esiste.",[11,408,409],{},"È un errore molto comune per chi ha un background tecnico: concentrare quasi tutto il budget sullo sviluppo e considerare il go-to-market come qualcosa da affrontare “dopo”. Il problema è che, quando arriva il “dopo”, spesso le risorse sono finite.",[22,411,413],{"id":412},"il-prodotto-non-si-vende-da-solo","Il prodotto non si vende da solo",[11,415,416],{},"C’è un’idea diffusa nella cultura tech: se il prodotto è buono, prima o poi i clienti arrivano. Nella pratica succede raramente.",[11,418,419],{},"Un prodotto compete per attenzione in un mercato saturo. Le persone non stanno aspettando che tu lanci qualcosa: stanno già usando alternative, magari peggiori, ma che conoscono. Farsi trovare, spiegare il valore, portare traffico qualificato richiede tempo, competenze e budget.",[11,421,422],{},"Se tutto il budget è stato assorbito dallo sviluppo, questa fase diventa improvvisata. Ed è qui che molti progetti si fermano.",[22,424,426],{"id":425},"la-regola-controintuitiva","La regola controintuitiva",[11,428,429,430,51],{},"Se non hai ancora clienti, ",[33,431,432],{},"il budget per far conoscere il prodotto è strategicamente più importante del budget per aggiungere nuove feature",[11,434,435],{},"Un prodotto con poche funzionalità ma con un piano di acquisizione utenti può iniziare a generare feedback e ricavi. Quei ricavi finanziano l’evoluzione del prodotto.",[11,437,438,439,443],{},"Un prodotto ricco di funzionalità ma senza utenti genera solo ",[47,440,442],{"href":441},"/blog/costi-manutenzione-software","costi di manutenzione"," e nessun apprendimento dal mercato.",[22,445,447],{"id":446},"come-ragionare-sulla-divisione-del-budget","Come ragionare sulla divisione del budget",[11,449,450],{},"Non esiste una formula universale, ma questo schema funziona in molti contesti digitali.",[452,453,455],"h3",{"id":454},"quando-non-hai-ancora-clienti","Quando non hai ancora clienti",[11,457,458,459,51],{},"Indicativamente: ",[33,460,461],{},"40% prodotto, 60% go-to-market e validazione",[11,463,464,465,469],{},"In questa fase l’obiettivo è dimostrare che qualcuno è disposto a usare (o pagare) ciò che stai costruendo, anche con poche feature. Il prodotto deve essere ",[47,466,468],{"href":467},"/blog/quando-lanciare-un-prodotto","piccolo ma solido",". Il resto del budget serve a raggiungere le persone giuste e capire se il problema che vuoi risolvere è reale.",[452,471,473],{"id":472},"quando-hai-già-clienti-interessati","Quando hai già clienti interessati",[11,475,476,477,480],{},"Puoi spostarti verso ",[33,478,479],{},"60% prodotto, 40% go-to-market",". Hai già un segnale di domanda, quindi ha senso investire di più nel soddisfarla, continuando però a mantenere attenzione su comunicazione e acquisizione.",[452,482,484],{"id":483},"quando-hai-già-traction","Quando hai già traction",[11,486,487,488,491],{},"Un punto di partenza ragionevole è ",[33,489,490],{},"50/50",", poi la distribuzione si adatta in base ai dati. Qui traction significa che il prodotto ha già mostrato segnali concreti di risposta dal mercato: utenti, richieste, vendite, interesse reale. Se il traffico è poco ma chi arriva converte, conviene investire di più nel marketing; se il traffico è alto ma pochi convertono, significa che il lavoro da fare è soprattutto sul prodotto.",[22,493,495],{"id":494},"il-segnale-che-stai-sbagliando-allocazione","Il segnale che stai sbagliando allocazione",[11,497,498],{},"Ci sono alcuni segnali ricorrenti: hai molte feature ma pochi utenti attivi, nessuno nel team si occupa in modo strutturato di acquisizione e comunicazione, il lancio è stato un post sui social e poco altro, oppure stai pensando di aggiungere nuove funzionalità prima ancora di aver capito perché le persone non usano quelle che già ci sono. In questi casi il problema riguarda quasi sempre visibilità e comprensione del mercato, molto prima di una feature mancante.",[22,500,502],{"id":501},"validare-prima-di-costruire","Validare prima di costruire",[11,504,505],{},"Spesso si può fare molto prima ancora di scrivere codice. Una landing page chiara con una proposta di valore e un piccolo budget in advertising permette già di capire se il messaggio genera interesse. Una lista d’attesa raccoglie email e dà un primo segnale di domanda. Una pre-vendita o anche solo una demo ben condotta ti dice qualcosa di ancora più importante: se qualcuno è disposto a pagare o a impegnarsi prima che il prodotto sia completo. Tutte queste attività costano molto meno dello sviluppo e riducono il rischio di costruire qualcosa che il mercato non sta cercando.",[22,507,509],{"id":508},"il-bias-di-chi-viene-dal-tech","Il bias di chi viene dal tech",[11,511,512],{},"Per chi viene dallo sviluppo, investire nel prodotto è naturale: è la zona di comfort. Ogni nuova feature è un risultato tangibile. Il marketing invece è incerto, meno misurabile nel breve periodo e quindi spesso rimandato.",[11,514,515],{},"Ma una feature senza utenti non genera valore. Un esperimento di acquisizione, anche se non funziona, genera dati utili per decidere meglio cosa costruire.",[22,517,519],{"id":518},"una-scelta-strategica-non-operativa","Una scelta strategica, non operativa",[11,521,522,523,526],{},"Ogni euro speso in sviluppo è un euro non speso in acquisizione: è a tutti gli effetti una decisione di business. ",[47,524,525],{"href":338},"L’AI sta riducendo il costo di sviluppo",", e questo rende ancora più evidente un punto: costruire è sempre meno il collo di bottiglia, raggiungere le persone giuste lo è sempre di più. Un prodotto valido che nessuno conosce resta un progetto ben fatto, ma isolato dal mercato.",{"title":159,"searchDepth":160,"depth":160,"links":528},[529,530,531,537,538,539,540],{"id":412,"depth":160,"text":413},{"id":425,"depth":160,"text":426},{"id":446,"depth":160,"text":447,"children":532},[533,535,536],{"id":454,"depth":534,"text":455},3,{"id":472,"depth":534,"text":473},{"id":483,"depth":534,"text":484},{"id":494,"depth":160,"text":495},{"id":501,"depth":160,"text":502},{"id":508,"depth":160,"text":509},{"id":518,"depth":160,"text":519},"2026-04-02","Un prodotto ottimo che nessuno conosce resta isolato dal mercato. Come distribuire il budget tra sviluppo e go-to-market a seconda della fase del prodotto.","/images/blog/budget-software-go-to-market.jpg",{},"/blog/2026-04-02-budget-software-go-to-market",{"title":398,"description":542},"Budget sviluppo software vs go-to-market: come distribuirlo","budget-software-go-to-market","blog/2026-04-02-budget-software-go-to-market",[551,552,553,554,555],"budget-startup","go-to-market","lancio-prodotto","validazione-mercato","pianificazione","JJkXzGwl1y64IBMDLH3xXPjQsVlNUjmv1K6Pk_KeO9U",{"id":558,"title":559,"body":560,"category":169,"date":709,"description":710,"extension":172,"image":711,"meta":712,"navigation":3,"path":713,"published":3,"seo":714,"seoTitle":715,"slug":716,"stem":717,"tags":718,"updated":188,"__hash__":722},"blog/blog/2026-03-31-quando-lanciare-un-prodotto.md","Quando lanciare un prodotto: meglio piccolo e funzionante che perfetto",{"type":8,"value":561,"toc":699},[562,568,572,582,589,596,599,603,606,609,613,616,619,622,625,629,637,641,651,658,665,669,672,676,679,686,690,693,696],[11,563,564,567],{},[33,565,566],{},"Capita spesso di vedere team che costruiscono per mesi un prodotto \"completo\", aggiungendo funzionalità una dopo l'altra, prima di mostrarlo a utenti reali."," Lanciare un MVP, cioè una prima versione piccola ma già usabile, prima di avere tutto pronto sembra rischioso, ma è l'opposto: il vero rischio è scoprire troppo tardi che il mercato voleva altro. Poi arriva il lancio e la realtà è brutale: alcune cose vengono ignorate, e le parti più usate non sono quelle su cui era stato investito di più. Il problema è costruire troppo a lungo senza verificare se il problema è davvero quello giusto, per le persone giuste.",[22,569,571],{"id":570},"la-perfezione-è-il-nemico-del-lancio","La perfezione è il nemico del lancio",[11,573,574,575,578,579,51],{},"C’è una differenza fondamentale tra un prodotto ",[33,576,577],{},"incompleto"," e un prodotto ",[33,580,581],{},"difettoso",[11,583,584,585,51],{},"Un prodotto difettoso è lento, instabile, perde dati, ha bug nei flussi principali. Questo non va bene, indipendentemente dalla fase. E infatti ",[47,586,588],{"href":587},"/blog/cos-e-un-mvp-software","un MVP non è una scusa per rilasciare software rotto",[11,590,591,592,595],{},"Un prodotto incompleto fa poche cose, ma le fa ",[33,593,594],{},"bene",". Mancano feature, manca personalizzazione, manca “comodità”. Ma il nucleo del valore è usabile, affidabile e comprensibile.",[11,597,598],{},"Molti team confondono le due cose: temono di essere giudicati per ciò che manca e finiscono per rimandare il lancio. Il rischio vero però è un altro: scoprire troppo tardi di aver costruito qualcosa che non corrisponde a un bisogno reale.",[22,600,602],{"id":601},"il-feedback-è-utile-solo-se-arriva-presto","Il feedback è utile solo se arriva presto",[11,604,605],{},"Interviste, benchmark e analisi competitor aiutano. Ma non sostituiscono ciò che succede quando un utente reale prova il prodotto nel suo contesto.",[11,607,608],{},"Quando lanci presto, purché il nucleo abbia qualità, scopri cose che raramente emergono in fase di pianificazione. Ti accorgi che la funzionalità considerata “secondaria” è quella che genera davvero valore, che un passaggio del flusso è confuso e blocca la conversione, che l’utente descrive il problema in modo diverso da come lo avevi modellato e che la priorità reale non era aggiungere feature ma semplificare il percorso. Sono scoperte che cambiano la roadmap, e più arrivano presto meno lavoro rischi di buttare via.",[22,610,612],{"id":611},"il-ciclo-lancia-misura-impara-migliora","Il ciclo: lancia, misura, impara, migliora",[11,614,615],{},"È un modo pratico di ridurre il rischio e di sostituire le ipotesi con segnali reali. La prima mossa è lanciare la versione minima che porta valore: “minima” non vuol dire “tirata via”, vuol dire identificare il nucleo del valore. Se stai costruendo un tool di prenotazione, il nucleo è che un utente possa prenotare e tu riceva la prenotazione in modo affidabile; reportistica avanzata, automazioni e personalizzazioni possono arrivare dopo.",[11,617,618],{},"Subito dopo devi mettere utenti veri davanti al prodotto. Meglio pochi utenti reali e coinvolti, che pagano o avrebbero un motivo concreto per usarlo, che cento curiosi. Il feedback di chi non ha nulla in gioco tende a essere rumoroso.",[11,620,621],{},"Poi conviene misurare cosa fanno, non solo cosa dicono. Le richieste del tipo “ci serve la feature X” spesso sono una soluzione proposta dall’utente, non il problema. Le metriche comportamentali dicono molto di più: dove si blocca il flusso, dove abbandonano, quali schermate usano davvero, quali passaggi richiedono supporto.",[11,623,624],{},"Infine si migliora in base a evidenze. Ogni iterazione dovrebbe rispondere a qualcosa che hai osservato, che sia un dato o un feedback ripetuto, e non a un’ipotesi non verificata o a un confronto estetico con il competitor.",[22,626,628],{"id":627},"il-costo-del-costruiamo-tutto-e-poi-vediamo","Il costo del “costruiamo tutto e poi vediamo”",[11,630,631,632,636],{},"Un prodotto costruito per mesi senza feedback tende a produrre due costi tipici. Il primo è l’accumulo di feature inutilizzate, che però vanno mantenute, testate, supportate e spiegate: un classico caso di ",[47,633,635],{"href":634},"/blog/budget-software-go-to-market","budget speso tutto nel prodotto"," senza vera validazione. Il secondo è un’architettura, insieme a una UX, modellate su ipotesi che diventano difficili da cambiare quando finalmente arriva la realtà. Il risultato è spesso una roadmap già pesante al day one, con molte parti in movimento, troppe dipendenze e poca capacità di adattamento.",[22,638,640],{"id":639},"ma-il-mio-settore-vuole-un-prodotto-completo","“Ma il mio settore vuole un prodotto completo”",[11,642,643,644,647,648,650],{},"È un’obiezione legittima. La risposta è che dipende da ",[277,645,646],{},"come"," definisci “completo” e da ",[277,649,646],{}," gestisci le aspettative.",[11,652,653,654,657],{},"Puoi lanciare una ",[33,655,656],{},"versione 1"," che fa poche cose essenziali molto bene, e comunicare in modo trasparente cosa è incluso e cosa arriverà dopo. La trasparenza, in molti contesti B2B, aumenta la fiducia perché segnala che stai costruendo con metodo e ascolto, non “a intuito”.",[11,659,660,661,664],{},"Il punto è lanciare qualcosa di ",[33,662,663],{},"limitato ma affidabile",", con la qualità concentrata sui flussi principali.",[22,666,668],{"id":667},"euristiche-pratiche-quando-sei-pronto-a-lanciare","Euristiche pratiche: quando sei pronto a lanciare",[11,670,671],{},"Se vuoi una regola operativa, guarda alcuni elementi minimi. Il flusso principale deve funzionare end-to-end, senza workaround e senza interventi manuali. Devi avere strumenti minimi di osservabilità, come error tracking, log e almeno una metrica di uso o attivazione. Devi sapere qual è la domanda a cui vuoi rispondere con il lancio, avere un canale di feedback e un modo ordinato per raccogliere richieste, e infine un piano semplice per iterare con una cadenza, delle priorità e qualcuno che decida. Se mancano questi punti, c’è ancora preparazione da fare.",[22,673,675],{"id":674},"le-feature-che-non-sviluppi-sono-un-vantaggio","Le feature che non sviluppi sono un vantaggio",[11,677,678],{},"Ogni feature che non costruisci basandoti su ipotesi è codice che non devi mantenere e che non può rompersi. È complessità evitata.",[11,680,681,685],{},[47,682,684],{"href":683},"/blog/stime-sviluppo-sbagliate-perche","Le stime sono spesso imprecise"," proprio perché il futuro cambia. Il ciclo iterativo non elimina l’incertezza: la rende gestibile, trasformando una scommessa grande in una serie di scommesse piccole.",[22,687,689],{"id":688},"il-prodotto-si-definisce-fuori-dal-tuo-ufficio","Il prodotto si definisce fuori dal tuo ufficio",[11,691,692],{},"È normale avere un’idea precisa di come “dovrebbe” essere, ma finché non lo metti nelle mani di utenti reali stai indovinando.",[11,694,695],{},"Lancia piccolo. Lancia bene. Ascolta. Migliora. Ripeti.",[11,697,698],{},"È meno “epico” di un grande lancio dopo mesi di lavoro nascosto, ma riduce drasticamente il rischio di costruire la cosa sbagliata e ti evita di scoprire troppo tardi che stai andando nella direzione sbagliata.",{"title":159,"searchDepth":160,"depth":160,"links":700},[701,702,703,704,705,706,707,708],{"id":570,"depth":160,"text":571},{"id":601,"depth":160,"text":602},{"id":611,"depth":160,"text":612},{"id":627,"depth":160,"text":628},{"id":639,"depth":160,"text":640},{"id":667,"depth":160,"text":668},{"id":674,"depth":160,"text":675},{"id":688,"depth":160,"text":689},"2026-03-31","Aspettare che il prodotto sia completo aumenta il rischio di costruire la cosa sbagliata. Come lanciare piccolo ma solido, raccogliere feedback e iterare.","/images/blog/quando-lanciare-un-prodotto.jpg",{},"/blog/2026-03-31-quando-lanciare-un-prodotto",{"title":559,"description":710},"Quando lanciare un prodotto: perché il lancio presto riduce il rischio","quando-lanciare-un-prodotto","blog/2026-03-31-quando-lanciare-un-prodotto",[553,719,554,720,721],"mvp","feedback-utenti","iterazioni","5BVlCMJYeJqQlQ3Rhju5O6ZeKPdwaZWVv5Q3BRB2km4",1777095241922]