Costruire invece di vendere è la procrastinazione più convincente che un founder abbia, perché lascia dietro di sé qualcosa di reale. Aggiungi una funzione, l'app è davvero migliore, e ti sembra di aver lavorato. Ma se nessuno ha usato le ultime cinque cose che hai costruito, la sesta non è lavoro sul prodotto.
È evitamento con una cronologia di commit. Il segnale onesto che lo stai facendo è semplice: continui a migliorare un prodotto che non ha visto quasi nessuno.
Devo aggiungere funzioni o cercare clienti
Se devi chiedertelo, lo sai già. L'indizio non è la domanda, è il tuo riflesso quando l'outreach diventa scomodo. La richiesta di una funzione sembra urgente, la roadmap sembra in ritardo, e costruire la prossima cosa sembra la mossa responsabile. Niente di tutto questo riguarda il cliente.
Riguarda il fatto che stai più comodo nell'editor che nell’inbox di qualcuno.
Ecco la versione semplice. Prima che persone reali abbiano usato quello che hai, altre funzioni non possono dirti niente. Stai aggiungendo risposte a domande che nessuno ha ancora fatto. L'unica informazione che conta all'inizio arriva da qualcuno fuori dalla tua testa che tocca la cosa e resta, oppure se ne va.
Finché non succede, ogni funzione è un'ipotesi sopra un'altra ipotesi.
Come distinguo l'evitamento dal vero lavoro sul prodotto
Il vero lavoro sul prodotto viene dopo una persona. Qualcuno ha usato il prodotto, ha sbattuto contro un muro, te l'ha detto o te l'ha mostrato con il suo comportamento, e tu stai sistemando quel muro preciso. L'evitamento viene prima di persone immaginarie. Ti immagini un utente che vorrebbe questa cosa, e costruisci per lui.
La differenza è se sai dire per chi è la funzione e indicare il momento in cui gli è servita. Se la risposta è un'ipotesi ("un utente potrebbe voler esportare in CSV"), è un tentativo alla cieca.
Se la risposta è concreta ("tre delle sette persone che l'hanno provato hanno chiesto il CSV nella stessa settimana"), è lavoro. Sette persone bastano per agire. Zero persone non è una versione più piccola di sette. È un'altra categoria, e nessuna quantità di sviluppo lo cambia.
Una funzione che nessuno ha chiesto non è un progresso. È una scommessa piazzata prima che qualcuno si sedesse al tavolo.
Troppe funzioni quando non hai utenti
Accumulare funzioni quando hai utenti è un problema di disciplina. Accumulare funzioni senza utenti è un problema di nascondersi, ed è peggio, perché sembra il contrario del nascondersi. Stai producendo. Il repo è pieno di attività. Il changelog è lungo.
E per tutto il tempo il vero collo di bottiglia, far guardare la cosa a uno sconosciuto, resta intatto, perché è l'unico compito che non offre codice da scrivere né una sensazione pulita di aver finito.
Ho rifatto una pagina delle impostazioni per evitare di mandare cinque messaggi. I messaggi mi avrebbero insegnato qualcosa. La pagina delle impostazioni non mi ha insegnato niente, a parte che sono bravo a evitare i messaggi.
Se ti è mai capitato di riorganizzare lo schema del database il giorno in cui ti eri promesso di fare outreach, conosci esattamente la sensazione, e sai che non è una virtù.
Smetti di costruire, inizia a vendere: la regola che regge davvero
La forza di volontà non lo risolve, perché costruire fa davvero stare bene e vendere fa davvero stare male. Ti serve una regola che tolga la decisione, quindi ecco quella che uso io. Ha un solo elemento variabile, di proposito.
Nessuna nuova funzione finché N persone giuste non hanno visto quella attuale.
È tutta la regola. Il meccanismo intorno:
- Scegli N e la persona. Piccolo e reale. Qualcosa come "venti founder che lavorano da soli e gestiscono la loro prospezione". Non un mercato, una persona che riesci a immaginare. Se non riesci a immaginarla, non riesci a contarla.
- "L'ha vista" vuol dire l'ha usata, non l'ha visitata. Una visualizzazione di pagina non è una persona. Si è iscritta, ha cliccato in giro, o ti ha guardato mentre gliela mostravi. Questo conta come visto.
- La funzione che hai è congelata finché non arrivi a N. I bug che bloccano l'uso si possono sistemare. Le rifiniture, le nuove superfici, la cosa che non vedi l'ora di costruire, tutto bloccato.
- Quando arrivi a N, leggi cosa è successo prima di costruire. Cosa hanno fatto, dove si sono fermati, cosa hanno chiesto due volte. Adesso hai una coda che viene da fuori dalla tua testa.
- Poi, e solo allora, costruisci la prima voce. E il contatore si azzera. La prossima funzione aspetta il prossimo N.
La regola funziona perché fa del compito scomodo l'unico compito sbloccato. Vuoi costruire, e l'unica strada per tornare a costruire passa dritta per l'outreach che stavi evitando. Smette di essere una lotta di forza di volontà e diventa un cancello.
Dove entra uno strumento, e dove no
Puoi applicare questa regola oggi con nient'altro che un foglio di calcolo e la tua inbox, e dovresti farlo, almeno finché far vedere la cosa alle persone non è l'unico passaggio che ancora si rompe. Se il tuo problema è che continui a costruire invece di lanciare, nessun software lo risolve. Il cancello qui sopra è gratis, ed è tutta la soluzione.
L'unico punto in cui uno strumento si guadagna il suo posto è il secondo passaggio, dove "l'ha vista" deve voler dire che N persone reali hanno davvero guardato. A mano non scala. Una vera presentazione per una persona richiede dieci minuti, e venti così sono tutta la tua settimana, quindi piano piano degenera in un invio generico in massa che nessuno guarda.
È il muro per cui ho costruito Personade, e sì, questo lo rende un'altra cosa che ho costruito invece di vendere. La differenza è che esiste per rimandarti a inviare.
Gestisce il tuo outreach su LinkedIn: l'invito, il messaggio e i follow-up, inviati dal tuo account, fermandosi appena qualcuno risponde. Se il tuo messaggio è una presentazione, un add-on video in più dà a ogni lead la sua versione con un'apertura pensata solo per lui, e ti dice chi ha guardato. È il segnale "l'ha vista", contato per te.
Quello che non farà è scrivere l'outreach, scegliere il tuo N o trasformare un prodotto che nessuno vuole in uno che le persone vogliono. Queste parti restano a te.
Se vuoi la versione completa del perché questo cambiamento è successo, ho scritto su perché costruire è diventato gratis e vendere no, e se il problema più profondo è che hai saltato del tutto la distribuzione, parti da lì.
Domande frequenti
Devo aggiungere altre funzioni o concentrarmi sui clienti? Prima i clienti, quasi sempre. Una funzione ti insegna qualcosa solo dopo che persone reali hanno usato il prodotto e ti hanno mostrato dove si rompe. Senza utenti, una nuova funzione è un'ipotesi senza niente con cui verificarla. Datti una regola che puoi far rispettare: nessuna nuova funzione finché un certo numero di persone giuste non ha davvero usato quella attuale.
Come faccio a sapere se sto costruendo per evitare di vendere? Fatti due domande sulla funzione. Per chi è, e quando ha sbattuto contro il muro che sistema. Se sai nominare persone reali e il momento esatto, è lavoro sul prodotto. Se l'utente è ipotetico e il momento è "prima o poi", è evitamento. Repo pieni di attività e changelog lunghi sembrano progressi, ma non misurano niente finché nessuno ha visto il prodotto.
Qual è una buona regola per non accumulare funzioni senza utenti? Congela il prodotto finché un numero fisso di persone giuste non ha usato quello che hai già costruito. Scegli qualcosa di piccolo e reale, tipo venti. "L'ha usato" vuol dire che si sono iscritte e hanno cliccato in giro, non che hanno visitato una pagina. Solo quando arrivi al numero leggi cosa hanno fatto e costruisci la richiesta principale. Poi il contatore si azzera e ricominci.
Le funzioni di cui vai fiero sono invisibili a tutti tranne che a te, finché qualcuno fuori dalla tua testa non ha un motivo per toccarle. Non è un problema di sviluppo, e il problema dello sviluppo l'hai già risolto.
È l'unico compito senza una sensazione pulita di aver finito, ed è proprio per questo che continua a perdere contro quello che ce l'ha. Metti il cancello davanti a te questa settimana e lascia decidere lui.