Product-market fit: smetti di costruire quello che non serve a nessuno

Immagina un fondatore seduto davanti a un potenziale cliente.

Il prodotto funziona. La demo è curata. Le funzioni AI fanno quello che promettono. Il cliente annuisce, fa qualche domanda intelligente e dice una frase che ogni fondatore ha già sentito:

"Davvero interessante. Mandami qualche informazione."

Un altro meeting promettente. Un'altra opportunità nel CRM. Tre settimane dopo, niente.

Il fondatore aggiunge un'altra funzione, migliora l'onboarding e riscrive il pitch di vendita. Forse il prodotto deve solo essere un po' migliore. O forse non serviva a nessuno fin dall'inizio.

È uno scenario illustrativo, ma la maggior parte dei fondatori lo riconoscerà. Confondiamo l'interesse del cliente con l'intenzione d'acquisto, l'uso del prodotto con il product-market fit e l'attività con il progresso. È la stessa confusione che trasforma gli MQL in teatro dei lead.

L'AI rende questa confusione più costosa. Costruire è diventato economico, quindi oggi possiamo costruire molto prima che qualcuno abbia preso un impegno concreto.

In un episodio recente di Lenny's Podcast, Rob Snyder, autore di The Power of Pull, ha spiegato il suo framework per trovare il product-market fit. Lenny lo presenta come qualcuno che ha aiutato più di 50 startup a passare da zero a 1 milione di dollari di ARR.

La sua idea centrale sta in due frasi. Trova persone che devono già far succedere qualcosa e non ci riescono con le opzioni che hanno. Poi guarda se provano davvero a comprare.

Credo che questo vada ben oltre le startup in fase iniziale. Cambia il modo in cui dovremmo affrontare il product management, il go-to-market e i sistemi AI che li collegano.

Il tuo concorrente più grande è la to-do list del cliente

La maggior parte dei team di prodotto parte dai problemi. Fanno interviste ai clienti, individuano i pain point, stimano le opportunità di mercato e costruiscono soluzioni. Poi il marketing traduce quelle soluzioni in value proposition e le vendite cercano di convincere i prospect a interessarsene.

Il processo sembra logico. Manca solo una variabile: la priorità.

Un cliente può avere un problema reale, riconoscere che il tuo prodotto lo risolve e concordare che offre un ottimo valore. E non avere comunque nessuna intenzione di comprare.

Ha altre quindici cose da chiudere in questo trimestre. La soluzione di ripiego che usa oggi è accettabile. Il capo ha chiesto altro. Oppure il problema è fastidioso ma non ha conseguenze rilevanti.

Nel framework di Snyder, la differenza tra interesse e domanda reale è il pull. Il pull nasce quando una persona precisa sta già cercando di realizzare qualcosa di importante, deve farlo adesso e trova insufficienti le opzioni che ha.

Quella persona sta già cercando di cambiare. Nessuno deve convincerla che il cambiamento è necessario.

Questa distinzione ribalta l'approccio al product-market fit. La domanda passa da come convincere più persone a comprare a dove le persone stanno già cercando di comprare qualcosa che ancora non esiste del tutto.

Il framework PULL: quattro condizioni per una domanda reale

Snyder lo scompone in quattro elementi.

Elemento	La domanda
P: Project (progetto)	Che cosa sta cercando attivamente di realizzare questa persona?
U: Unavoidable (inevitabile)	Perché deve realizzarlo adesso?
L: List of options (lista di opzioni)	Quali alternative sta valutando o usa già?
L: Limitations (limiti)	Perché quelle alternative non bastano a portare a termine il lavoro?

Contano tutti e quattro. Un progetto senza urgenza diventa una bella idea per l'anno prossimo. Urgenza senza limiti significa che il cliente probabilmente può risolverlo da solo. Un prodotto migliore senza un progetto importante è solo un altro tool di cui qualcuno non ha bisogno.

Snyder porta un esempio da Jump, un prodotto AI per le note delle riunioni pensato per i consulenti finanziari.

I consulenti finanziari devono documentare gli incontri con i clienti e tenere i registri nel loro CRM. Snyder spiega che gli obblighi di compliance rendono questo lavoro inevitabile. Gli strumenti AI generici per prendere appunti possono produrre buoni riassunti, ma non si integrano per forza con i sistemi richiesti né soddisfano i requisiti di compliance. Jump copre proprio questa lacuna.

Ora confrontalo con gli agenti assicurativi. Anche loro passano tempo a incontrare clienti, e forse anche a loro non piace scrivere note. Ma nell'esempio che descrive Snyder, non hanno lo stesso obbligo di tenere quei registri nel CRM. Non fare nulla è un'alternativa accettabile.

Stesso dolore di fondo. Workflow simile. Comportamento d'acquisto molto diverso.

È una lezione importante per chiunque definisca un ideal customer profile.

Un settore non è il tuo cliente. Un'azienda non è il tuo cliente. Il tuo cliente è una persona con un progetto inevitabile.

E le priorità attuali di quella persona contano più della tua value proposition limata con cura.

L'AI ha cambiato i costi di sbagliare il product-market fit

Qui è dove estenderei l'argomento di Snyder.

Per anni, costruire software è stato abbastanza costoso da imporre una certa disciplina. Una funzione importante richiedeva sviluppatori, pianificazione, test e mesi di capacità di engineering.

Oggi un fondatore capace può usare lo sviluppo assistito dall'AI per produrre un prototipo funzionante in pochi giorni. È un progresso reale, e crea una nuova trappola: iniziamo a usare la velocità di esecuzione come prova di progresso.

Un team costruisce dieci funzioni, lancia tre landing page, automatizza l'outbound e crea una demo curata. La review settimanale sembra produttiva. Eppure la domanda più importante resta senza risposta.

Chi sta cercando di comprarlo, e perché adesso?

Scrivere codice è diventato veloce. Arrivare sul mercato no. Più precisamente, il collo di bottiglia si è spostato. Quando costruire diventa economico, decidere che cosa merita di essere costruito vale relativamente di più. Quando ho scritto di come costruire un prodotto SaaS in 90 giorni, la parte difficile non è mai stata il codice. Era tagliare.

Il product-market fit non può più essere trattato come una fase che arriva dopo lo sviluppo del prodotto. Deve guidare lo sviluppo fin dall'inizio.

Questo significa che le conversazioni con i clienti sono più di semplici input di ricerca per i product manager. Sono esperimenti commerciali che verificano se il cliente agirà. E il segnale più forte è un acquisto.

Smetti di intervistare le persone sulla tua idea. Verifica se provano a comprare.

Snyder consiglia di partire da quella che chiama ipotesi di pull. Prima di costruire il prodotto, metti per iscritto le tue assunzioni sulla situazione del buyer.

Ecco un esempio ipotetico dallo sviluppo di software B2B. Una VP Product è sotto pressione per consegnare una release importante questo trimestre. Il suo team usa Jira, strumenti di documentazione e assistenti AI per il coding, ma le decisioni di prodotto importanti non si riflettono in modo coerente nel lavoro di implementazione. La release è a rischio, e aggiungere sviluppatori non risolverà per forza il problema di coordinamento.

L'ipotesi diventa:

• Progetto: Consegnare una release già promessa senza perdere requisiti critici tra prodotto ed engineering.
• Inevitabile: La release ha una scadenza promessa all'esterno.
• Opzioni: Più meeting, più product manager, documentazione migliore, integrazioni Jira esistenti e tool AI per il coding.
• Limiti: Queste opzioni possono migliorare singoli compiti senza tenere allineati in modo affidabile decisioni, ticket e implementazione.

Nota che cosa manca. Nessuna lista di funzioni, nessuna grande visione di prodotto, nessun pitch sulla magia dell'AI. Solo una persona precisa, un progetto importante e un motivo per cui i metodi esistenti non funzionano.

È il tipo di ipotesi che vale la pena testare per un prodotto come Teklens, che ho cofondato: un Product Brain condiviso, un'unica memoria per persone e agenti AI che collega le conversazioni di prodotto, Jira e il codice.

Ma resta un'ipotesi. Il buyer giusto potrebbe non considerare urgente il problema. Il team potrebbe già gestirlo abbastanza bene. Oppure il vero buyer è un CTO che si prepara a un audit, non una VP Product che gestisce una release.

Lo scopo della discovery è scoprirlo.

Snyder consiglia di mostrare ai potenziali clienti una descrizione semplice del progetto, dell'urgenza e dei limiti, seguita da una spiegazione concettuale di come potresti aiutarli. Poi osserva che cosa fanno.

Alcuni chiedono un piano di implementazione, coinvolgono un collega, avviano il procurement o chiedono quando possono iniziare. Altri si complimentano per la visione e promettono di restare in contatto. Sono segnali molto diversi.

Una promessa verbale di acquisto è incoraggiante. Un impegno pagato è più forte. Adozione e retention reali lo sono ancora di più.

Cinque conversazioni di vendita possono insegnarti più di cinque settimane di sviluppo

Uno dei consigli più utili di Snyder è lavorare in piccoli cicli di discovery. Parti da un'ipotesi. Trova le persone giuste. Fai circa cinque conversazioni. Rivedi che cosa hai imparato.

Se nessuno cerca di andare avanti, non prenotare in automatico altri cinquanta meeting. Cambia l'ipotesi. Forse il problema è reale ma non urgente. Forse è in mano alla persona sbagliata. Forse i tool esistenti bastano già. O forse hai scoperto un altro progetto che conta molto di più.

Snyder chiama uno dei modi per scoprirlo la domanda Hail Mary:

"C'è qualcosa nella tua to-do list che pagheresti qualcuno per toglierti dalle mani adesso?"

È una domanda semplice, e molto più utile che chiedere quali funzioni qualcuno vorrebbe vedere. Sposta la conversazione dalle opinioni sul prodotto alle priorità reali.

Le persone sono generose di feedback su prodotti che non hanno nessuna intenzione di comprare. Passano volentieri un'ora a disegnare la tua roadmap. Solo che non la finanziano.

Snyder è particolarmente scettico verso le collaborazioni con i design partner che generano molto feedback ma poco impegno commerciale.

Io non scarterei del tutto i design partner. In ambienti B2B complessi, lo sviluppo congiunto può far emergere vincoli di integrazione, la realtà dei workflow e requisiti organizzativi che altrimenti resterebbero invisibili. Ma il test commerciale conta comunque. Un design partner dovrebbe avere un progetto reale, un criterio di successo definito e un percorso credibile per diventare cliente pagante. Altrimenti potresti aver reclutato un utile consulente di prodotto invece di un buyer.

Vendi il risultato prima di costruire la piattaforma

C'è un'altra implicazione che l'AI rende particolarmente interessante. Non sempre ti serve un prodotto software finito per testare la domanda. Se un cliente ha bisogno di portare a termine un lavoro specifico, a volte puoi consegnare il risultato con una combinazione di persone, software esistente e automazione.

Snyder descrive fondatori che partono con offerte simili a un servizio prima di sviluppare il software sottostante.

Immagina un'azienda che deve ridurre il suo ciclo di ricerche di mercato da settimane a giorni. La prima versione potrebbe prevedere ricercatori che usano tool AI, controlli di qualità manuali e una semplice interfaccia di reporting. Il buyer ottiene il risultato. Il fornitore impara quali passi sono ripetibili. Poi il team automatizza quei passi. È l'ordine in cui lavora un forward deployed engineer: prima mappa il processo reale, poi automatizza ciò che si ripete.

Questo inverte la sequenza tradizionale. Quella vecchia: costruisci il software, trova clienti, spera che lo usino. Quella nuova: trova un lavoro urgente, vendi il risultato, consegnalo, impara il workflow, poi automatizza ciò che si ripete.

Questo è particolarmente rilevante per le aziende B2B AI-native. Ma c'è un rischio. Se ogni cliente richiede un'implementazione diversa, non hai per forza trovato un prodotto scalabile. Potresti aver costruito una società di consulenza con ottimi strumenti. Ho scritto di dove passa questo confine, e della via di mezzo onesta di prodotto più servizi, in agenzia di servizi vs prodotto software.

La disciplina sta nel separare il nucleo ripetibile dal lavoro su misura che gli sta intorno. Fatti pagare presto per il risultato. Impara che cosa è riutilizzabile. Trasforma in prodotto il lavoro ricorrente. Non confondere cinque progetti di clienti scollegati tra loro con il product-market fit.

Il product-market fit non finisce quando i clienti comprano

Un cliente che vuole comprare con urgenza può comunque andarsene. Forse il prodotto non funziona come promesso. Forse l'implementazione è troppo complicata. Forse il progetto immediato del buyer finisce, e il prodotto non serve più.

Snyder suggerisce di pensare al percorso del cliente in due fasi. Prima dell'acquisto, devi trovare qualcuno per cui comprare ha ovviamente senso. Dopo l'acquisto, devi individuare il momento in cui andarsene non avrebbe più senso.

Questo secondo momento è più utile che festeggiare i tassi di attivazione. Un login prova poco. Un cliente che completa un compito che prima bloccava il suo business è un segnale molto migliore.

Per un prodotto che collega requisiti, ticket e codice, quel momento potrebbe essere un team che individua un disallineamento importante prima che arrivi in produzione, e poi lo risolve con il contesto giusto. Per un sistema GTM, potrebbe essere un venditore che riceve un segnale d'acquisto su cui può agire e che altrimenti sarebbe sparito tra CRM, meeting ed email.

Sono ipotesi da testare, non metriche di attivazione universali. La domanda operativa è:

Che cosa deve vivere un cliente prima che il prodotto gli manchi davvero, se sparisse?

Poi costruisci l'onboarding a ritroso partendo da quel momento.

Gestisci la tua azienda come una fabbrica di case study

Verso la fine dell'intervista, Snyder introduce un'idea che trovo più utile dell'acronimo PULL stesso: pensa alla tua azienda come a una fabbrica che produce storie di successo dei clienti ripetibili.

Intende risultati per i clienti che si ripetono, cliente dopo cliente. I case study di marketing con loghi patinati e percentuali sospette sono un'altra cosa.

Ogni cliente di successo segue più o meno lo stesso schema. Una persona precisa ha un progetto urgente. Le opzioni che ha non bastano. Compra qualcosa che la aiuta. Ottiene il risultato desiderato. Resta perché la soluzione continua ad avere valore.

La tua azienda diventa un sistema per ripetere quello schema:

1. Trova il buyer giusto.
2. Capisci il progetto urgente.
3. Dimostra una soluzione credibile.
4. Ottieni un impegno commerciale.
5. Consegna il risultato promesso.
6. Arriva a un valore duraturo.
7. Mantieni il cliente, impara e ripeti.

Questo modello mentale collega product management, vendite, marketing e customer success attorno a un'unica definizione di successo. Cambia anche il modo in cui pensi alla crescita.

Se il collo di bottiglia è la pipeline, migliora il modo in cui trovi buyer simili. Se i clienti hanno progetti urgenti ma non comprano, analizza l'offerta, la credibilità, il processo commerciale o i vincoli d'acquisto. Se comprano ma non restano, migliora la consegna e il tempo necessario per arrivare al valore, oppure chiediti di nuovo se la domanda iniziale è ripetibile.

Il focus cambia con il vincolo. È molto più utile che dire a ogni reparto di migliorare tutti i suoi KPI insieme.

Dove il contesto condiviso diventa l'infrastruttura che manca

Qui vedo un collegamento con i sistemi che stiamo costruendo attorno a prodotto, GTM e AI.

Immagina che un cliente dica alle vendite che la sua priorità più grande è ridurre i ritardi delle release. La conversazione produce prove utili su urgenza, soluzioni esistenti, ostacoli, budget e persone coinvolte.

In molte organizzazioni, quelle informazioni restano in una registrazione della call o in una nota nel CRM. Il prodotto riceve una richiesta di funzione privata del suo contesto originale. Il marketing crea un messaggio generico sui pain point. Il Customer Success riceve una checklist di onboarding ma non il risultato di business che il cliente si aspetta. Poi si chiede a un agente AI di preparare un follow-up con i frammenti che riesce a recuperare.

Tutti lavorano. Tutti hanno informazioni diverse.

La fabbrica di case study di Snyder richiede qualcosa di più coerente. Le stesse prove del cliente dovrebbero guidare la decisione di prodotto, la promessa commerciale, il piano di implementazione e la milestone di retention. Per questo nessuno deve leggere un documento enorme. Ogni persona e ogni agente ha bisogno delle prove rilevanti nel momento in cui decide.

È il principio dietro Get Multiplayer: Le persone fissano gli obiettivi, decidono e approvano. Gli agenti preparano e si occupano del lavoro ripetitivo. Obiettivi condivisi e contesto condiviso tengono insieme il lavoro.

Per esempio, un agente può estrarre da una conversazione di vendita il progetto attivo di un cliente e le sue alternative. Un altro può confrontare quei requisiti con il backlog di prodotto. Un terzo può preparare un piano di onboarding basato sul risultato promesso.

Ma le persone devono comunque verificare le prove e decidere che cosa significano. Altrimenti stai solo automatizzando supposizioni. Più in fretta. Su larga scala.

Dove non sono d'accordo: il pull da solo non garantisce un grande business

Il framework di Snyder è utile soprattutto perché impone onestà commerciale. Ma non è una teoria completa su come si costruisce un'azienda.

Un cliente può avere un'urgenza reale e rappresentare comunque un pessimo mercato. Forse il progetto si presenta solo una volta ogni cinque anni. Forse il buyer non ha l'autorità per spendere. Forse la consegna costa più del contratto. Forse il problema ha un valore enorme ma esiste in troppo poche organizzazioni.

Un pull forte convalida un'opportunità specifica. Non convalida in automatico la dimensione del mercato, margini interessanti, una distribuzione ripetibile o la difendibilità.

Nel B2B enterprise, la distinzione tra una persona che vuole la soluzione e un'organizzazione che può acquistarla è particolarmente importante. Il champion può avere pull. Sicurezza, ufficio legale e procurement hanno comunque requisiti propri.

Per questo vedo il framework PULL come un complemento a un processo di vendita enterprise ben gestito, non come un suo sostituto. Ed è per questo che la retention conta quanto l'intenzione d'acquisto iniziale.

Ti servono tre livelli di prova:

• Domanda: Le persone provano a comprare con urgenza?
• Valore: La soluzione produce un risultato che a loro interessa?
• Economia: Puoi ripetere quel risultato in modo redditizio su abbastanza clienti?

Solo quando questi tre livelli si rafforzano a vicenda un'opportunità entusiasmante inizia ad assomigliare a un business scalabile.

Un playbook pratico per il product-market fit

Se lunedì prossimo iniziassi un nuovo prodotto B2B, organizzerei il primo ciclo attorno a sette attività.

1. Scegli una persona, non un mercato. Identifica il ruolo, la responsabilità e la situazione in cui il bisogno è probabilmente urgente. "SaaS mid-market" è troppo vago.
2. Scrivi un'ipotesi PULL. Documenta il progetto, perché adesso, le opzioni esistenti e perché quelle opzioni falliscono. Tieni le assunzioni separate dalle prove confermate dai clienti.
3. Avvicinati al lavoro. Osserva i workflow reali, i meeting con i clienti, i tool e i passaggi di consegne. Le interviste aiutano, ma vedere qualcuno faticare con un compito reale può rivelare quello che si dimentica di dire.
4. Fai cinque conversazioni commerciali. Chiedi dei progetti in corso, delle scadenze, delle soluzioni già tentate e dei passi d'acquisto. Mostra solo quel tanto della soluzione proposta che basta a verificare se andrebbero avanti.
5. Cerca azioni, non entusiasmo. Una diagnosi a pagamento, un ordine firmato, un impegno commerciale o un processo di procurement avviato dal cliente sono prove più forti di un feedback positivo.
6. Consegna il risultato e trova il momento della retention. Lavora a stretto contatto con i primi clienti. Individua l'evento che dimostra un valore duraturo, poi metti quell'evento al centro dell'onboarding.
7. Trasforma ciò che impari in un sistema ripetibile. Porta le prove convalidate nel posizionamento, nelle priorità di prodotto, nella qualificazione commerciale e nell'onboarding. Trova il prossimo collo di bottiglia e miglioralo.

L'AI può aiutare in ogni fase. Può analizzare le call, raggruppare gli schemi ricorrenti, confrontare opzioni, produrre prototipi, preparare proposte, documentare ciò che si è imparato e automatizzare il lavoro di consegna ripetibile.

Quello che non può fare è fabbricare una priorità urgente del cliente dove non esiste. Per questo il ruolo umano resta essenziale: decidere se le prove giustificano il prossimo investimento.

Costruisci meno. Impara che cosa merita di essere costruito.

Sono partito da un fondatore con una demo curata e un prospect che aveva promesso di farsi risentire.

La reazione tipica è migliorare il prodotto, mandare un altro follow-up e aumentare il volume di outreach. A volte è esattamente quello che serve. A volte il passo successivo più prezioso è ammettere che stai cercando di vendere qualcosa che nessuno sta cercando di comprare con urgenza.

Rob Snyder ci dà un modo pratico per distinguere i due casi. L'AI ci dà la possibilità di agire su ciò che impariamo molto più in fretta. La combinazione funziona, a patto di usare la tecnologia nell'ordine giusto.

Trova il progetto urgente. Dimostra che il cliente agirà. Consegna il risultato. Rendilo ripetibile.

Prima trova i clienti per cui vale la pena costruire. Poi lascia che l'AI ti renda veloce.

Se vuoi una nota operativa a settimana su prodotto, GTM e AI, iscriviti alla newsletter The Science of GTM.

Basato sulla conversazione di Rob Snyder con Lenny Rachitsky a Lenny's Podcast, An 86-minute guide to finding PMF, pubblicata il 25 ottobre 2026 (ascolta su Snipd). Il libro di Rob Snyder: The Power of Pull, John Murray Business, 2026. Il framework PULL, la domanda Hail Mary e la fabbrica di case study sono di Snyder. La lettura per prodotto, GTM e AI e le estensioni pratiche sono mie.