Lancio di TranslatePress – Dall’idea al prodotto

Quando lanci un nuovo progetto c'è sempre un fermento di entusiasmo, speranza, sollievo, ma anche la paura del fallimento e della delusione.

Questo è qualcosa che ho sperimentato per tutti i progetti di cui ho fatto parte negli ultimi 9 anni, al punto che non vedo attivamente l'ora del primo lancio fallito.

Nulla dimostra quanto detto meglio del feedback che abbiamo ricevuto dagli utenti che stanno attualmente utilizzando il nostro TranslatePress plugin.

Speranza: Stiamo già usando il vostro plugin gratuito. Vorremmo acquistarlo più tardi.
Paura del fallimento: Se funziona con il plugin che gestisce la prenotazione nel nostro sito.

Poi c'è il numero disastroso di installazioni attive dopo aver inviato oltre 7.000 email ai clienti precedenti. Meno di 10 per le prime due settimane.

Ma questa non è la storia di qualcosa che assomiglia al lancio fallito di un prodotto (ne parleremo più avanti).

Tornerò invece al dicembre 2016 e inizierò a spiegare quasi tutto ciò che abbiamo affrontato negli ultimi 8 mesi per il lancio di TranslatePress, dall’idea iniziale fino a un plugin completamente nuovo che permette di tradurre un Sito web WordPress in più lingue.

Ci passo:

• perché un nuovo plugin di traduzione e come ci è venuta l'idea
• allocare risorse di sviluppo e decidere una tempistica
• superando i tempi previsti di quasi 2,5 volte e le relative motivazioni
• ideare un logo e qualcosa che assomigli a un marchio in fretta
• la decisione su come monetizzare il plugin
• implementazione di un sito completamente nuovo, configurazione di pagamenti e licenze
• lanciare la versione beta del plugin e lavorare su una nuova funzione
• marketing
• Conclusioni

Creiamo un plugin, dicevano! Sarà divertente, dicevano!

Come ogni fine anno, abbiamo una riunione con il resto del team presso Cozmoslabs su ciò che ha funzionato in quell'anno, ciò che ha completamente fallito e le cose che non vediamo l'ora di affrontare nel prossimo anno.

Il mio collega Razvan Mocanu voleva lavorare a un progetto nuovissimo. Un nuovo plugin. Così abbiamo preso nota mentalmente, siamo andati in vacanza di Natale e siamo tornati a gennaio con un'unica buona idea su cui avevamo davvero voglia di lavorare: un plugin di traduzione per WordPress che chiunque può usare.

Sebbene sembri alquanto arbitrario, non lo è affatto:

• come sviluppatori di plugin, abbiamo dovuto avere a che fare con i plugin di traduzione fin dal primo giorno (al momento abbiamo il supporto per WPML in tutto nostro plugin)
• prima di passare allo sviluppo di plugin, eravamo un'agenzia di sviluppo su misura che implementava WPML per vari clienti (funzionava per noi come sviluppatori, quasi mai per il cliente finale)
• non ci è piaciuto per niente il flusso di lavoro di traduzione della quasi totalità dei plugin di traduzione sul mercato. (Non visivo, fuori contesto, trovato in più punti)
• sapevamo di non voler fare un clone di WPML o di lavorare con installazioni Multisite

Quindi l'unico altro plugin esistente sul mercato che faceva qualcosa di diverso era WeGlot. Un'implementazione di tipo Software as a Service che offre traduzione automatica e manuale. In pratica, la traduzione del tuo sito viene caricata dai loro server.

Dalla combinazione dei plugin e delle idee precedenti siamo giunti a un concetto simile a WeGlot, ma piuttosto diverso nella sua implementazione:

Traduci l'intera pagina. Niente più passaggi tra l'editor, le interfacce di traduzione delle stringhe o plugin tradotti male. Ora puoi tradurre la pagina finale con il pieno supporto per WooCommerce e site builder.

La differenza principale sta nell'implementazione:

• supporto per stringhe dinamiche ( stringhe gettext )
• tutto memorizzato localmente, nel tuo database (le tue traduzioni sono tue)
• un plugin GPL (accesso alla base di codice nel caso in cui tu abbia bisogno di qualcosa di diverso)
• il desiderio di fare in modo che il nostro plugin funzioni con qualsiasi plugin o tema WordPress e non viceversa, dove gli sviluppatori devono aggiungere il supporto per i plugin di traduzione

Stime di sviluppo

A gennaio, il mio collega Madalin Ungureanu ha riferito di aver testato il nucleo del plugin, una classe di parser DOM in PHP, per verificare se fosse utilizzabile. Ha funzionato piuttosto bene: siamo riusciti a eseguire operazioni di ricerca e sostituzione di stringhe nel database senza rallentare il sito di prova, quindi abbiamo deciso di procedere con l’avvio del progetto. Razvan sarebbe stato lo sviluppatore capo e si sarebbe occupato di rilasciare le versioni alpha e beta, a quel punto avremmo destinato maggiori risorse al progetto. Pur non essendo la soluzione ideale, era tutto ciò che potevamo fare senza assumere altro personale.

3 mesi. Facciamo una versione alfa/beta ad aprile. A luglio abbiamo iniziato i test interni e spinto per il lancio della beta. Il 31 luglio abbiamo reso la beta disponibile per il download. Il lancio finale è avvenuto il 4 settembre, con più di 5 mesi di ritardo rispetto alla nostra stima.

Ho anche imparato ad aspettarmi che le attività di sviluppo software richiedano più tempo del previsto

Come per il lancio lento, ho anche imparato ad aspettarmi che le attività di sviluppo software richiedano più tempo del previsto.

Ci sono alcune eccezioni alla regola, ma ciò avviene solitamente alla fine di un ciclo di sviluppo, quando il problema era già ben definito e compreso, non richiedeva ulteriori ricerche e tutto ciò che rimaneva da fare era scrivere il codice.

Quindi perché ci è voluto più tempo del previsto?

• Ovviamente abbiamo sottostimato il tempo necessario. Davvero non sapevamo quanto ci sarebbe voluto.
• Il termine di 3 mesi è stato imposto più per motivi pratici. Non spingete il progetto nel periodo delle vacanze estive. (lo abbiamo fatto)
• Razvan è ancora un junior developer e questo è stato il suo primo grande progetto in azienda. Sebbene ci siano state parecchie discussioni riguardo alla direzione dello sviluppo e all'implementazione, c'è stato pochissimo codice effettivo scritto da chiunque altro del team nelle prime fasi del progetto. Quindi i progressi sono stati lenti.
• Non appena ho iniziato a testare il plugin a giugno, non ha funzionato nulla. Sulla mia installazione almeno. Mentre Razvan ha cercato di generalizzare il problema il più possibile (sostituzione rapida di stringhe), ci è stato subito chiaro che c'erano molti più casi limite di quanto avessimo realizzato e preventivato.

Design di loghi veloci

Mentre il plugin era in fase di sviluppo, ho concentrato la mia attenzione sul design di un nuovo logo e di una nuova combinazione di colori per il nostro futuro sito web.

Non sono affatto un graphic designer, ma me la cavo a spostare pixel in Photoshop. Conosco i miei limiti e mi sta bene combinare quadrati, rettangoli e cerchi per inventare qualcosa che sia decente. Non eccezionale, ma decente. Quindi ho ritagliato qualche ora e ho tirato fuori 4 proposte (che vanno da infantile a passabile) che ho mostrato al resto del team.

Abbiamo scelto l'ultimo e siamo andati avanti con progettazione del sito.

Tutto sommato, c'erano probabilmente 3-4 giorni effettivi di lavoro distribuiti nell'arco di un paio di mesi per ottenere tutta la grafica e il design di cui avevamo bisogno per il lancio. Il tema era un clone dello stesso tema personalizzato che abbiamo usato su www.cozmoslabs.com quindi abbiamo dedicato il minor tempo possibile alla sua pubblicazione.

Sebbene il design sia davvero importante, rilasciare questo prodotto con il minimo investimento lo era ancora di più. Il design di Cozmoslabs è stato il risultato di 4 mesi di lavoro con un designer (con molti botta e risposta) e di altri due mesi per implementarlo nella sua interezza. Semplicemente non potevamo permettercelo in questa fase. Quindi abbiamo fatto qualcosa di buono e siamo andati avanti.

Monetizzazione

Abbiamo deciso fin dall'inizio che ci saranno versioni gratuite e Versioni Pro. Sia le nostre esperienze precedenti che quelle di altri sviluppatori di plugin nella comunità di WordPress hanno reso chiaro che questa era la strada da percorrere.

Ciò che non era così chiaro è come dovremmo differenziare le versioni. Le cose che abbiamo considerato parte delle versioni Pro erano:

• traduzione di tipi di post personalizzati;
• lingue multiple;
• API Google Translate;
• Modulo SEO (traduzione di slug, titolo della pagina e descrizione).

Ciò su cui alla fine abbiamo deciso è di includere il Modulo SEO e Lingue Multiple nelle versioni Pro + una differenziazione basata sul numero di installazioni attive.

Oltre a questo:

• ciascuna fascia di prezzo è valida per 1 anno, con rinnovo automatico;
• Le versioni Pro contengono solo gli Addon Avanzati. Quindi la versione gratuita sarà sempre necessaria.

Lancio di TranslatePress – Nuovo sito, configurazione dei pagamenti e delle licenze

Per vendere il nostro nuovo plugin, abbiamo cercato di mantenerlo il più semplice possibile, quindi abbiamo utilizzato Easy Digital Downloads e Digital Licenses per EDD.

Purtroppo, per far funzionare la nostra configurazione abbiamo avuto bisogno di un lavoro personalizzato:

• il nostro gateway di pagamento Avangate (personalizzato via codice perché l'API di Avangate è semplicemente strana)
• rinnovi automatici da Avangate (non possiamo usare EDD per questo ma qualcosa di sviluppato su misura)
• licenze digitali per un tipo di prodotto “Bundle” in modo che una sola licenza funzioni su tutti i componenti aggiuntivi del “Bundle” (questo non funziona con EDD)

Volevamo utilizzare il componente aggiuntivo All Access Pass per EDD che risolveva le licenze digitali per i bundle, ma non ha funzionato per noi perché:

• Se possiedi un All Access Pass, non puoi acquistarne un altro, ma puoi solo estendere il periodo di validità della licenza.
• ha rotto i nostri rinnovi automatici personalizzati (a causa del modo in cui Avangate gestisce i rinnovi automatici)
• ha anche rotto gli aggiornamenti perché, di nuovo, gli aggiornamenti sono personalizzati a causa di Avangate.

Così abbiamo finito per programmare su misura un componente aggiuntivo per EDD che funziona un po' come All Access Pass (il codice è fondamentalmente preso dal componente aggiuntivo), ma senza la parte All Access 🙂

A parte questo, il tema è stato riciclato da Cozmoslabs come menzionato in precedenza e noi abbiamo usato il nostro Profile Builder Pro plugin per le funzionalità di login, modifica del profilo e reset della password.

Lancio Beta

Un modo per creare slancio per un prodotto è il lancio di una beta. Sebbene vi siano altri motivi per un lancio beta (la segnalazione di bug), ciò che ho sperimentato con altri plugin in passato è che Il vantaggio principale è la possibilità di parlare del tuo prodotto anche se non funziona ancora. 🙂

Sebbene sia alquanto superficiale nel suo intento, è solo un altro strumento di marketing che si può utilizzare. E come bonus, abbiamo anche ricevuto un paio di segnalazioni corrette di bug/funzionalità che hanno reso più chiaro il fatto che ci mancava qualcosa di fondamentale con la versione beta: non c'era alcun supporto per i campi gettext.

Il supporto per i campi gettext era una delle grandi funzionalità che volevamo introdurre DOPO il lancio. Tuttavia, giocando sempre di più con il plugin e ascoltando ciò che i nostri utenti beta avevano da dire al riguardo, abbiamo fatto di necessità virtù e abbiamo iniziato a lavorare su questa funzionalità subito dopo il lancio della beta del plugin.

Questo è uno dei più grandi errori che avremmo potuto fare dal punto di vista dello sviluppo e uno dei motivi per cui ci è voluto così tanto tempo per rilasciare la versione 1.0. Abbiamo ritardato il supporto per gettext perché era difficile da implementare.

Una storia divertente su come abbiamo iniziato è che, dopo il lancio della beta, abbiamo avuto un'interruzione di corrente di un'ora in ufficio. Mentre aspettavo che la luce tornasse, ho iniziato a pulire la mia tastiera. Non c'era niente di meglio da fare comunque, così ho fatto una foto alla tastiera, ho rimosso tutti i tasti e ho proceduto a pulirli uno per uno con un po' di alcol denoturato e uno straccio.

E per le 2 ore successive, ho pulito la mia tastiera e creato una mappa mentale dell'implementazione di gettext in WordPress, di come il nostro plugin traduceva le stringhe e di come avremmo potuto combinare le due cose, senza incorrere in problemi di prestazioni in futuro.

Successivamente, ho fatto una breve discussione con Madalin riguardo a gettext, ho deciso che dovremmo farlo ora, prima del lancio della versione 1.0, e LUI si è messo al lavoro.

Ci sono un paio di insegnamenti da trarre da questa storia:

• è una cattiva idea rimandare le funzionalità complicate senza un buon motivo. Sapevamo che sarebbe stato complicato, ecco perché lo abbiamo rimandato così a lungo;
• Mentre le 2 ore spese a pensare a gettext non hanno fatto assolutamente nulla in termini di tempo di sviluppo effettivo (ci è voluto 1 mese di lavoro a Madalin per farlo funzionare e ora è al suo secondo mese a combattere con wp_ajax e gettext), sono state infinitamente meglio che non pensarci affatto. Era ciò di cui avevamo bisogno per decidere e sbloccarci.

Per promuovere la beta abbiamo:

• ho scritto un articolo beta che è anche ottimizzato per il SEO per “WordPress in più lingue”(inutile scrivere più di 2000 parole senza sperare in futuro in un po' di traffico SEO).;
• ho inviato una newsletter ai nostri clienti esistenti di Cozmoslabs riguardo al nuovo plugin;
• sul sito web di TranslatePress erano presenti appositi moduli di “Iscrizione alla beta”;
• Due settimane dopo l'inizio della beta, abbiamo chiesto un riscontro alle 100 persone che si erano iscritte alla beta (abbiamo usato Mailchimp per questo);
• per altre due settimane, abbiamo pubblicato annunci su Facebook che hanno aumentato i nostri beta tester a 160.

Versione 1.0

Ci è voluto un mese di sviluppare → test → ripara cicli per far funzionare l'implementazione di gettext per le stringhe rese da PHP (normali modelli di pagina).

Non avevamo ancora il supporto gettext per le chiamate wp_ajax, ma era importante lanciare ora e non più tardi:

• Se avessimo ritardato il completamento di tutto, avremmo perso tempo per il marketing (o almeno per vedere cosa funziona e cosa no). Se non c'è un prodotto, non possiamo parlare del prodotto;
• avremmo potuto perdere l'opportunità di sponsor del WordCamp di Bucarest questo accade in ottobre;
• una volta configurati il sito web, il gateway di pagamento, le licenze, l'assistenza e la documentazione, tutto ciò che ci resta da fare è lavorare SUL prodotto.

Marketing

Fin dal lancio della beta, abbiamo iniziato a pensare alla commercializzazione del plugin.

Un modello di business freemium significa che dipendiamo da un gran numero di utenti gratuiti e di installazioni attive.

Con un nuovo plugin, l'operazione risulta molto più complessa di quanto si possa pensare, soprattutto alla luce della nuova directory di WordPress che tiene conto delle installazioni attive, delle recensioni, del numero di domande a cui è stata data risposta nei forum e di altri elementi quantitativi su cui non abbiamo alcun controllo.

Quindi i nostri sforzi sono stati diretti a raggiungere quanti più amministratori di WordPress possibile: 

• abbiamo aggiunto la promozione incrociata nei nostri altri plugin (TranslatePress è in grado di tradurre i nostri altri plugin, quindi lo abbiamo inserito nella sezione dei plugin consigliati);
• ho aggiunto il download gratuito alla pagina dell'account di tutti i nostri clienti su Cozmoslabs;
• sono entrato in contatto con ThemeIsle aggiungere TranslatePress all'elenco dei plugin consigliati, poiché funziona alla grande per tradurre i loro temi complessi (noi stiamo usando Estia per il nostro sito dimostrativo);
• sponsorizzare WordCamp Bucharest e poter parlare con potenziali utenti faccia a faccia.

Tutto questo impegno è particolarmente importante all’inizio per ottenere un po’ di visibilità, in modo che TranslatePress compaia nei risultati di ricerca di WordPress.org.

Abbiamo cercato di essere il meno possibile "spam", se una cosa del genere esiste. Non abbiamo usato avvisi che compaiono in tutte le pagine del backend né inviato newsletter su newsletter ai nostri clienti esistenti (solo due per la beta e il lancio della Versione 1.0).

Futuri piani di marketing:

• pianifichiamo di creare tutorial per molti temi popolari e su come tradurli (grazie Ionut);
• continuare i nostri sforzi di outreach verso gli sviluppatori di plugin e temi. Vogliamo aggiungere il supporto per i plugin, non che siano i plugin a dover aggiungere il supporto per noi;
• Il content marketing multilingue è difficile perché non ci posizioneremo in alto nei motori di ricerca. Non all'inizio comunque. Quindi, sebbene saremo attivi su questo fronte, non è molto importante per noi ora.

Conclusioni tratte dal lancio della nostra iniziativa TranslatePress

La cosa principale che voglio sottolineare di questo processo durato 8 mesi è che non è la fine della corsa. La mancanza di interesse all'inizio è normale. Pochi o nessun download sono normali. Poco o nessun feedback è normale.

Invece di preoccuparmi di tutto questo, ho iniziato a vedere i lanci iniziali per quello che sono veramente: struttura su cui l'azienda può costruire il prodotto e commercializzarlo in futuro.

Il vero successo o fallimento arriva a un molto più tardi.

È stato persino comico per me vedere quanto siano brutti i lanci iniziali e fare scommesse con il resto del team che sono quasi sempre molto più ottimiste 🙂

Infine, ecco un elenco delle cose che abbiamo imparato sul lancio di TranslatePress negli ultimi 8 mesi:

• i lanci come costruzione della struttura del progetto. Una volta fuori potrai lavorare sul marketing e sul miglioramento del prodotto;
• non rimandare il momento di pensare alle parti complicate del progetto. Puoi scegliere di includerli o meno nella Versione 1.0, ma mai, in nessun caso, devi smettere di pensarci;
• chiedere feedback ad altre persone della comunità. Ho avuto discussioni davvero interessanti con la community di PostStatus (tecniche), con esperti WordPress locali che realizzano siti web multilingua (sulle funzionalità), con utenti reali (hanno adorato l'interfaccia facile da usare, se solo il plugin avesse funzionato per tutte le stringhe 🙂 ), con altri professionisti di prodotti WordPress (marketing). Le funzionalità future, le decisioni tecniche e il marketing sono influenzati da questo feedback;
• Dedica il tempo necessario alle funzioni importanti. Abbiamo dedicato molto tempo all'implementazione di gettext e continuiamo a farlo. È l'elemento che rende l'intero plugin così versatile, quindi deve funzionare;
• a meno che tu non stia vendendo veri e propri lavori di design, non perdere molto tempo sul design del sito web. Concentrati invece sul rendere il contenuto chiaro, senza parole complesse e strutturato in modo che non sia eccessivamente complicato per qualcuno non tecnico. Se non sai da dove cominciare, vai semplicemente su AffiliateWP e rubare la loro struttura di contenuto. Nessuno se ne accorgerà;
• Tutto ciò che puoi configurare una volta per tutte dovrebbe essere fatto sin dall’inizio. Se non puoi utilizzare strumenti già pronti per vendere il tuo plugin, sviluppali su misura adesso, se sai come farlo. Una volta che l’infrastruttura sarà a posto, potremo concentrarci al 100% sul plugin per il prossimo anno o più, senza preoccuparci di modificare la struttura dei prezzi, i rinnovi, gli account, ecc.

Quindi questo è il inizio della nostra avventura TranslatePress.

Se sei riuscito a leggere tutto questo, grazie per il tuo tempo! E prova TranslatePress, anche solo per giocarci. È figo così!

[NOTA]: Questo articolo sul lancio di TranslatePress è stato originariamente pubblicato su StatoPost newsletter.