Pochi giorni fa abbiamo lanciato WebDiff: una app desktop pensata per le agenzie web che hanno tanti siti da mantenere aggiornati: https://webdiff.app/it
WebDiff non è il primo progetto che realizziamo in casa TangoDev. Il primo è stato Level-app, poi c’è stato Casualis, Magic Moment, ecc.
Ogni progetto ci è servito per imparare qualcosa, perché alla fine facciamo sempre gli stessi errori e se non ce ne rendiamo conto, possiamo anche lanciare 300 progetti diversi ma l’esito sarà sempre lo stesso. Mi capita di confrontarmi con altre realtà come la nostra e quando si parla di questi argomenti la sensazione è che, anche se passa del tempo, sono sempre le stesse cose a bloccarci.
Con WebDiff abbiamo veramente voluto impegnarci per cambiare rotta e agire diversamente su tutti quei punti che guardandoci indietro, non abbiamo affrontato “benissimo” nei progetti precedenti.
Li vogliamo condividere con voi, perché appunto sappiamo che alla fine sono sempre gli stessi errori che facciamo un po’ tutti, soprattutto se abbiamo un background tech.
Obiettivo: go live!
L’obiettivo di WebDiff era di pubblicarla entro la fine dell’anno, punto. Una volta identificato il set di funzionalità imprescindibili, non abbiamo fatto voli pindarici sulla scalabilità o cose simili: l’obiettivo era uscire con un prodotto funzionante per verificare se a qualcun altro nel mondo potesse servire WebDiff come serve a noi. Questa sembra una cosa da poco, ma cambia tutto: ogni singola scelta, sia essa tecnica o no, ha l’unico obiettivo di raggiungere la 1.0 entro il tempo stabilito. In altri progetti, come Magic Moment, non siamo stati così risoluti: abbiamo ad esempio nella 1.0 incluso un database cloud che avrebbe supportato dal giorno 1 centinaia di migliaia di clienti. Inutile dire che non lo abbiamo mai sfruttato, ma sarebbe invece stato meglio uscire prima, con un database più “terra a terra”, e investire il tempo (e il denaro) risparmiato nel far conoscere il servizio.
Lo stack e i silver bullets
Il mondo dev è fatto di puristi:
PHP? => Pessimo. Monoliti? => Dove siamo, nel 2009? WordPress? => Ma non ti vergogni? Bootstrap? => Svengo.
La verità (almeno per noi) è che ogni strumento ha il proprio caso d’uso (concetti vecchi di 40 anni ma che faticano a entrarci in testa soprattutto a noi sviluppatori) e che quando si lancia un prodotto come WebDiff è fondamentale valutare lo stack non sulla base dell’hype, ma invece valutare veramente quali sono gli strumenti adatti allo scopo del progetto, valutandone seriamente gli obbiettivi a breve e medio termine. WebDiff per noi da questo punto di vista è un gioiellino, perché in 100 ore/uomo abbiamo realizzato l’app, le pipeline di build e deploy, il sito, il flusso di acquisto, la documentazione, il tutto in due lingue (italiano e inglese). Ci siamo riusciti scegliendo accuratamente ogni strumento per massimizzare la nostra produttività e allo stesso tempo far uscire un qualcosa di cui potessimo essere fieri.
Target e dintorni
I prodotti migliori sono quelli per cui noi (che li realizziamo) siamo i primi utenti. C’è poco da farci, quando un progetto nasce da un vero bisogno diretto di chi lo realizza, ha una marcia in più. Sai come ragiona il tuo target perché tu sei il tuo target. Sai se un bisogno è un vero bisogno (per cui il tuo target è disposto a pagare) perché tu in primis puoi chiederlo a te stesso (questo non ti impedisce di prendere delle cantonate fortissime). Ci è capitato spesso di non essere al 100% nel target dei nostri prodotti, e questo ha sicuramente fuorviato molte decisioni, portandoci a dare peso a cose che per il nostro target non avevano alcuna importanza.
Cercare feedback (e ascoltarli)
Non dobbiamo avere paura dei feedback del mondo esterno. O meglio, è normale averne paura perché possono smontare mesi di lavoro in pochi secondi, ma dobbiamo cercare proattivamente il feedback soprattutto all’inizio per guidare le nostre scelte. Con WebDiff già la prima manciata di utenti ci ha dato dei suggerimenti e degli spunti che abbiamo già integrato nell’app e nella relativa comunicazione. Questo approccio è quello che guida tutto il flusso di lavoro:
voglio realizzare un prodotto snello => perché non so ancora se susciterà interesse => e perché so che il mio obiettivo è farlo uscire il prima possibile => per avere presto dei feedback su cui costruire gli step successivi.
Questa è una cosa che abbiamo imparato con Casualis: oggi il 50% degli utenti che usa Casualis lo fa per una funzionalità che nella nostra visione non era minimamente contemplata ma che abbiamo realizzato comunque in seguito ai feedback ricevuti soprattutto all’inizio.
Marketing > Prodotto (in un certo senso)
Il lancio non è l’arrivo, ma l’inizio. Da ingegneri pensiamo che il valore del prodotto che realizziamo possa attirare senza ulteriore sforzo i potenziali clienti (build it and they will come), la realtà è che non attira proprio nulla. Se c’è un errore comune che abbiamo fatto su TUTTI i progetti precedenti a WebDiff è aver sottovalutato la parte di marketing del prodotto. Qualche anno fa non l’avrei mai detto, ma ora siamo consci che questa parte conta di più del prodotto stesso, non perché non conti la qualità del prodotto, ma la qualità del prodotto non serve a molto se nessuno conosce il prodotto stesso.
Riassumendo
Ho scritto questo post un po’ per condividere ma soprattutto come riassuntone per noi, per farci vedere nero su bianco come il nostro percorso stia andando avanti e da ogni piccolo progetto, anche se fallimentare in termini numerici, siamo stati in grado di tirarci fuori qualcosa di utile che ha influenzato il progetto successivo.
