Software product management: costruire prodotti che durano

Le decisioni più costose nel software product management arrivano prima che esista la prima riga di codice. Eppure la maggior parte dei team parte dall'altro capo: prepara il backlog, scrive i ticket, pianifica lo sprint. Si costruisce dal primo giorno, si decide dopo, ammesso che si decida. Il rituale sembra professionale e gira comunque al contrario.

Il backlog dà la sensazione di progresso: ticket nuovi ogni settimana, qualcosa rilasciato ogni settimana. La roadmap si riempie prima che esista la direzione. Ma la velocità senza direzione non è una virtù, il team manca il cliente solo più in fretta. E la situazione si sta acuendo: l'AI ha reso economico costruire. Il codice arriva in ore invece che in settimane. Questo sposta il collo di bottiglia dove è sempre stato di casa: decidere cosa si costruisce e cosa no.

Questa pagina mette in ordine esattamente quelle decisioni, dal posizionamento allo scope all'organizzazione, e raccoglie tutti gli articoli sul lato prodotto. Scritta per product leader, founder e dirigenti di aziende software B2B che devono decidere dove va il poco tempo di sviluppo.

Lavoro all'incrocio tra prodotto, GTM e AI. GTM sta per go-to-market, cioè il percorso che il tuo prodotto fa fino al cliente. In questo momento sto contribuendo a costruire Teklens, un software che lavora dentro i team di prodotto. Quindi le domande di questa pagina per me non sono teoria, sono la mia routine settimanale: cosa costruire, cosa tagliare, cosa misurare.

Cosa impari

• Le tre domande che reggono ogni decisione di prodotto: per chi, quale problema, misurato come.
• Perché il posizionamento viene prima del codice e come testarlo in una frase.
• Quanto può essere ristretta una prima versione e cosa di proposito non si costruisce nei primi 90 giorni.
• Come riconoscere il product-market fit in modo misurabile e cosa cambiano gli agenti AI nel costruire prodotti.

I buoni prodotti nascono da decisioni chiare, non da più feature

Software product management significa decidere cosa si costruisce, per chi e perché, e fare in modo che quelle decisioni reggano nel lavoro quotidiano. È tutta qui la tesi di questa pagina. Non più feature, non più processo, non il prossimo framework, ma decisioni chiare che sopravvivono al primo desiderio urlato da un cliente. Il resto della pagina è la prova, decisione dopo decisione, fino a un traguardo misurabile.

Cosa rende buono il software product management?

Risposte chiare a tre domande: per chi costruiamo? Quale problema risolviamo? Come misuriamo il successo? Se non riesci a rispondere a ciascuna delle tre in una frase, stai costruendo su un sospetto.

La terza domanda è la più scomoda. Successo non significa download o feature rilasciate, ma per esempio: i clienti usano il prodotto ogni settimana e rinnovano il contratto. Solo un criterio misurabile trasforma un'idea di prodotto in una scommessa verificabile.

Un buon product management dice anche no più spesso di sì. Ogni feature costa tre volte: costruirla, mantenerla e spiegarla. La capacità più importante quindi non è dare priorità alle idee ma tagliarle. E le risposte devono sopravvivere al lavoro quotidiano: una strategia che si ribalta al primo desiderio urlato da un cliente non è mai stata una strategia. Le tre risposte stanno su una pagina sola, visibile a tutto il team, non in un documento di strategia che nessuno apre. Ogni nuova idea di feature deve misurarsi con quelle frasi, altrimenti alla fine decide la voce più forte.

Perché il prodotto inizia prima del codice?

Le decisioni di prodotto più importanti arrivano prima che sia scritta la prima riga. Chi è il cliente, qual è il problema, perché siamo noi la risposta giusta? È lavoro di posizionamento, descritto nella guida al posizionamento di prodotto B2B.

Posizionamento significa che i clienti capiscono subito perché il tuo prodotto fa per loro. Se manca, si vendica due volte. Il team costruisce feature per tutti e per nessuno, e il sales spiega un prodotto diverso a ogni prospect. Le aziende DACH tecnicamente forti tendono in particolare a sottovalutare questo lavoro, perché non sembra lavoro. Un test semplice: spiega il tuo prodotto in una frase, senza il nome dell'azienda. Se la frase va bene per altri dieci fornitori, non hai un posizionamento, hai una descrizione.

E siccome un prodotto vive solo se arriva al mercato, costruire e fare marketing vanno insieme in coppia, come nell'articolo su product marketing e product management. Un team costruisce il prodotto, l'altro lo porta ai clienti. Quanto bene i due giocano insieme decide la tua crescita.

Quanto ristretta può essere la prima versione?

Più ristretta di quanto la maggior parte delle persone osi. L'errore di prodotto più comune è la megalomania nello scope. La mia contro-posizione: un prodotto SaaS in 90 giorni, ristretto, onesto, rilasciato. Non tutto quello che vorresti, ma la parte per cui i clienti pagano.

Altrettanto importante è la lista di quello che nei primi 90 giorni non si costruisce: nessun sistema di ruoli e permessi, nessuna integrazione per ipotetici clienti enterprise, nessuna dashboard di amministrazione, nessun supporto multilingua. Tutto questo può arrivare dopo, quando lo chiede un cliente pagante. Fino ad allora è capitale morto che devi mantenere. L'effetto dello scope ristretto è doppio: rilasci prima e impari prima. Un cliente che usa davvero una versione ristretta ti dice sul tuo prodotto più di dieci workshop su una versione grande.

Ne fa parte la domanda onesta se vuoi davvero un business di prodotto oppure un'agenzia, vedi Agenzia di servizi contro prodotto software. Quella decisione di fondo appartiene al capitolo entrepreneurship, perché dà forma a tutto quello che viene dopo.

Ti serve un framework come il modello Spotify?

Quasi sicuramente no. I modelli organizzativi copiati falliscono perché manca il contesto da cui sono nati: la dimensione dell'azienda, la cultura, i problemi di quell'epoca. Perché il famoso modello di squad e tribe, cioè piccoli team autonomi e gruppi di quei team, da te non funzionerà lo trovi in Il modello Spotify da te non funzionerà.

E con team piccoli più assistenti AI non ti serve comunque. I problemi di coordinamento che questi framework dovrebbero risolvere compaiono solo con molti team in parallelo. Resta sotto quella soglia il più a lungo che puoi. Un team piccolo con responsabilità chiare batte la struttura di un gruppo ricostruita a tavolino.

Software product management nella pratica: primi passi ed errori comuni

Come partire senza disperdersi:

• Rispondi per iscritto alle tre domande: per chi, quale problema, misurato come.
• Formula il posizionamento in una frase prima di pianificare le feature.
• Taglia la prima versione fino a quello per cui un cliente paga oggi.
• Definisci il traguardo in modo misurabile, per esempio con i tre dieci di Hendrikse, tra poco ne parlo.
• Impara i termini tecnici di base. Non devi programmare, ma dovresti saper collocare i termini di base. Cloud-native, IaaS, PaaS e SaaS spiega il mondo del cloud in parole semplici.

Gli errori comuni sono le inversioni: costruire senza posizionamento, perché costruire sembra più produttivo che pensare. Guidare la roadmap in base al cliente più rumoroso invece che all'ideal customer profile. Copiare modelli organizzativi invece di risolvere il problema vero. E sentire il product-market fit invece di misurarlo, finché i soldi finiscono. Aggiungici un errore silenzioso: ignorare le fondamenta tecniche finché non si fanno sentire. Se sai collocare i termini di base, capisci cosa rallenta il tuo team e cosa lo regge.

Il traguardo misurabile: product-market fit, e cosa ci cambia l'AI

Per chiudere, i due argomenti più pesanti: un traguardo che puoi misurare e uno spostamento che sta colpendo adesso ogni organizzazione di prodotto.

Come riconosci il product-market fit?

Dai numeri, non dalla sensazione. Product-market fit significa che il tuo prodotto risolve un problema così bene che i clienti pagano e restano. Stijn Hendrikse rende misurabile quel traguardo in T2D3: il product-market fit è raggiunto quando, tra le altre tappe, ci sono 10 clienti paganti, 10 referenze pubbliche e 10 nuovi clienti arrivati per passaparola.

La sensazione ti inganna in modo sistematico. I prospect sono gentili, i clienti pilota lodano senza impegnarsi, e un calendario pieno sembra domanda. I tre dieci di Hendrikse sono incorruttibili: pagato, sostenuto in pubblico, raccomandato. Solo quando degli sconosciuti portano avanti il tuo prodotto da soli, il prodotto regge davvero. Hendrikse scrive da un contesto SaaS americano, con investitori alle spalle. La sua checklist funziona comunque per qualsiasi struttura di capitale, perché conta solo quello che i clienti fanno volontariamente: pagare, raccomandare, esporsi in pubblico.

Dietro c'è un modello di maturità con un ordine fisso, come le basi nel baseball: prima la prima versione vendibile del prodotto, poi il product-market fit, solo dopo la scalata. Nessuna base si può saltare. Se ci provi lo stesso, dopo torni indietro a riparare. Per il tuo product management significa: prima del traguardo conta imparare, non espandersi.

Cosa cambia l'AI nel software product management?

Il codice è diventato economico, le decisioni e il contesto sono diventati costosi. Cambia in profondità il modo stesso di lavorare: gli assistenti AI scrivono codice e lavorano dentro il team, se li guidi. Con questo il product management diventa più importante, non meno.

Cosa significa in concreto lo mostrano From vibe coding to agentic engineering e Agentic product engineering: da 30 a 3. Programmare a braccio con l'AI ha lasciato i postumi: codice insicuro, team più lenti. Ora conta guidare gli assistenti invece di fidarsi alla cieca. E il lavoro che una volta richiedeva un'intera organizzazione di prodotto oggi lo fa un team piccolo con gli agenti.

Guidare qui significa fornire contesto. Un compito è descritto bene solo quando una persona e un assistente AI possono eseguirlo senza fare domande. Come è fatto un ordine di lavoro così lo trovi nell'anatomia di un ticket GTM. I team piccoli più gli agenti sostituiscono le strutture a squad di ieri. Per la pianificazione dei team significa: invece di copiare modelli organizzativi, descrivi il lavoro in modo che diventi delegabile, alle persone come agli agenti. È questa la nuova competenza centrale nel product management. Su come automazione e lavoro di prodotto si incastrano trovi altro nell'hub automazione e AI nel B2B.

Decidere invece di accumulare: cosa resta

✅ Dove brilla: le tre domande non costano nulla e funzionano subito. Un team che sa rispondere in una frase a per chi, quale problema e misurato come prende decisioni migliori già da domani, senza un solo tool nuovo.

❌ Dove non brilla: le decisioni chiare sembrano più lente del costruire. Tagliare non produce nessuna demo, e un no nella sprint review sembra niente. Reggi quel ritmo solo se la leadership lo sostiene.

⚠️ Attenzione: la trappola più grande è il codice a basso costo. Siccome l'AI rende quasi gratis costruire, lo scope cresce più in fretta di quanto qualcuno lo metta in discussione. Se oggi costruisci senza posizionamento, fai il vecchio errore alla velocità delle macchine.

Il cerchio si chiude con l'inizio: le decisioni più costose arrivano ancora prima della prima riga di codice, solo che oggi dopo ogni decisione arriva più codice che mai. Il backlog non è mai stato il punto di partenza giusto, e ora non è nemmeno il collo di bottiglia. Se vuoi appunti come questi con regolarità, iscriviti alla mia newsletter.

Qui sotto trovi tutti gli articoli sul lato prodotto, ognuno descritto in parole semplici.