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.

Support for gettext fields was one of the big features we wanted to introduce AFTER launch. However, playing more and more with plugin and hearing what our beta users had to say about it, we bit the bullet and started working on this feature right after beta launching the plugin.

This is one of the biggest mistakes we could have done from a development point of view and one of the reasons why it took us so long to ship version 1.0. We delayed support for gettext because it was hard to implement.

A funny story about how we got started is that after the beta launch, we had a 1-hour power failure at the office. While I waited for the power to come back on, I started cleaning my keyboard. There was nothing better to do anyway, so I took a picture of the keyboard, removed all keycaps, and proceed to clean them one by one with a little bit of rubbing alcohol and a rag.

And for the next 2 hours, cleaned my keyboard and created a mental mindmap of the gettext implementation in WordPress, how our plugin was translating strings and how we could combine the two, without getting into performance issues further down the line.

After that, I had a quick discussion with Madalin about gettext, decided we should do it now, before version 1.0 launch and HE got to work on it.

There are a couple of takeaways from this story:

• it’s a bad idea to delay complicated features without a good reason. We knew it was going to be complicated, that’s why we delayed it for so long;
• while the 2 hours thinking about gettext did absolutely nothing in terms of actual development time (it took Madalin 1 month of work to get it working and he’s now in his second month dealing with wp_ajax and gettext), it was infinitely better than not thinking about it at all. It was what we needed to decide and get unstuck.

For promoting the beta we:

• wrote a beta article that’s also SEO optimized for “WordPress in più lingue” (no point in writing 2000+ words without hoping in the future for a bit of seo traffic.);
• sent a newsletter to our existing clients at Cozmoslabs about the new plugin;
• had proper “Signup for beta” forms on the TranslatePress website;
• two weeks into the beta we asked the 100 people who signed up for the beta for feedback (we used Mailchimp for this);
• for another two weeks, we ran Facebook ads that increased our beta testers to 160.

Version 1.0

It took us a month of develop → test → fix cycles to get the gettext implementation working for strings rendered by PHP (normal page templates).

We still didn’t have gettext support for wp_ajax calls, but it was important to launch now and not later:

• if we would have delayed getting everything done, we would have lost time for marketing (or at least see what works and what doesn’t). If there is no product we can’t talk about the product;
• we could have lost the opportunity to sponsor WordCamp Bucharest that’s happening in October;
• once the website, payment gateway, licenses, support, and documentation are all set up, all we’re left with is working ON the product.

Marketing

Ever since the beta launch, we started thinking about marketing the plugin.

A freemium business model means we’re dependent on a large number of free users and active installs.

With a new plugin that’s a lot harder than you might think, particularly with the new WordPress directory that takes into account active installs, reviews, number of responded questions on the forums, and other quantitative elements that we don’t have control over.

So our efforts were directed towards getting in front of as many WordPress admins as possible: 

• we added cross-promotion in our other plugins (TranslatePress can translate our other plugins, so we’ve listed it in our recommended plugins section);
• added the free download to the account page of all our clients over at Cozmoslabs;
• got in touch with ThemeIsle to add TranslatePress to a recommended plugin list as it works great to translate their complex themes (we’re using Hestia for our sito dimostrativo);
• sponsoring WordCamp Bucharest and getting to talk to potential users face to face.

All this effort is particularly important at the beginning to get a bit of traction so TranslatePress appears in the WordPress.org search results.

We tried to be as less spammy as possible, if that’s even a thing. We didn’t use notices that appear on all backend pages or send newsletter after newsletter to our existing clients ( just two for beta and Version 1.0 launch).

Future marketing plans:

• we plan to create tutorials for a lot of popular themes and how to translate them (thanks Ionut);
• continue our outreach efforts towards plugin and theme developers. We want to add support for plugins, not for plugins to have to add support for us;
• content marketing for multilingual is hard because we won’t rank high in search engines. Not at first anyway. So while we’ll be active on this front, it’s not highly important for us now.

Conclusions from our TranslatePress launch

The main thing I want to highlight about this 8 month process, is that it’s not the end of the line. Lack of interest at the beginning is normal. Little to no downloads are normal. Little to no feedback is normal.

Instead of worrying about all this, I’ve come to see initial launches for what they really are: structure on which the company can build the product and market it in the future.

The real success  or failure comes at a much later time.

It’s even been comical for me to see how bad initial launches are and to make bets with the rest of the team that are almost always way more optimistic 🙂

Finally, here’s a list of the things we’ve learned about our TranslatePress launch in this past 8 months:

• launches as building up the structure of the project. Once out you can work on marketing and improving the product;
• don’t delay thinking about complicated parts of the project. You can choose to include them or not in Version 1.0, but never, ever NOT think about them;
• ask feedback from other people from the community. I’ve had some really interesting discussions with the PostStatus community (technical), with local WordPress people who implement multilingual websites (about features), with actual users (they loved the easy-to-use interface, if only the plugin worked for all strings 🙂  ), with other WordPress product people (marketing). Future features, technical decisions, and marketing are influenced by this feedback;
• spend the needed amount of time on important features. We’ve spent a lot of time on the gettext implementation and continue to do so. It’s the one thing that makes the entire plugin so versatile, so it has to work;
• unless you’re selling actual design work, don’t spend a lot of time on the website design. Focus instead on making the content clear, without fancy words, and structured so it’s not overly complicated for someone non-technical. If you’re not sure where to start, just go over to AffiliateWP and steal their content structure. No one will notice;
• everything you can set up and forget should be done early on. If you can’t use off-the-shelf tools to sell your plugin, custom code them now if you know how to. With the infrastructure in place, we can 100% focus on the plugin for the next year or more, without worrying about changing the pricing structure, renewals, accounts, etc.

So this is the beginning of our TranslatePress adventure.

If you managed to read all of this, thank you for your time! And try TranslatePress, even if it’s just to play with it. It’s cool like that!

[NOTE]: This article about the TranslatePress launch was Originally published in the PostStatus newsletter.