Markteinführung des TranslatePress – Vom Konzept zum Produkt

Wenn man ein neues Projekt startet, schwingt immer eine Welle der Begeisterung, der Hoffnung und der Erleichterung mit, aber auch die Angst vor dem Scheitern und vor Enttäuschung.

Das ist etwas, das ich bei allen Projekten erlebt habe, an denen ich in den letzten 9 Jahren beteiligt war, und zwar so sehr, dass ich dem ersten fehlgeschlagenen Launch aktiv entgegenfiebere.

Nichts verdeutlicht das Oben Gesagte mehr als das Feedback, das wir von den Nutzern erhalten haben, die derzeit unsere TranslatePress Plugin.

Hoffnung: Wir nutzen Ihr kostenloses Plugin bereits. Wir möchten es später kaufen.
Angst vor dem Scheitern: Wenn es mit dem Plugin funktioniert, das die Buchung auf unserer Website abwickelt.

Dann ist da noch die miserable Anzahl aktiver Installationen, nachdem über 7.000 E-Mails an frühere Kunden gesendet wurden. Weniger als 10 für die ersten zwei Wochen.

Aber das ist keine Geschichte von etwas, das wie ein gescheiterter Produktstart aussieht (dazu später mehr).

Stattdessen werde ich bis zum Dezember 2016 zurückgehen und fast alles erläutern, was wir in den letzten acht Monaten im Rahmen unserer TranslatePress-Einführung durchgemacht haben – vom ersten Konzept bis hin zu einem brandneuen Plugin, mit dem Sie eine WordPress-Website in mehreren Sprachen.

Ich gehe durch:

• Warum ein neues Übersetzungsplugin und wie wir auf die Idee gekommen sind
• Zuweisung von Entwicklungsressourcen und Festlegung eines Zeitplans
• Überschreitung des Zeitrahmens um das fast 2,5-Fache und die Gründe dafür
• schnell ein Logo und etwas Markenähnliches entwickeln
• die Entscheidung, wie das Plugin monetarisiert wird
• Implementierung einer brandneuen Website, Einrichtung von Zahlungen und Lizenzen
• Die Beta-Version des Plugins veröffentlichen und an einem neuen Feature arbeiten
• Marketing
• Schlussfolgerungen

Lasst uns ein Plugin bauen, haben sie gesagt! Es wird Spaß machen, haben sie gesagt!

Wie jedes Jahresende haben wir ein Treffen mit dem Rest des Teams drüben bei Cozmoslabs darüber, was in diesem Jahr funktioniert hat, was völlig gescheitert ist und worauf wir uns im nächsten Jahr freuen.

Mein Kollege Razvan Mocanu wollte an einem brandneuen Projekt arbeiten. Einem neuen Plugin. Also machten wir uns eine mentale Notiz, gingen in die Weihnachtsferien und kamen im Januar mit einer einzigen guten Idee zurück, an der wir tatsächlich arbeiten wollten: ein Übersetzungsplugin für WordPress, das jeder nutzen kann.

Auch wenn das etwas willkürlich erscheint, ist es das eigentlich nicht:

• Als Plugin-Entwickler mussten wir uns vom ersten Tag an mit Übersetzungsplugins auseinandersetzen (zur Zeit haben wir Unterstützung für WPML in alle unser Plugins)
• Bevor wir zur Plugin-Entwicklung gewechselt sind, waren wir eine Agentur für Individualentwicklung, die WPML für verschiedene Kunden implementiert hat (für uns als Entwickler hat es funktioniert, für den Endkunden fast nie).
• Wir mochten den Übersetzungs-Workflow fast aller Übersetzungs-Plugins auf dem Markt wirklich nicht. (Nicht visuell, aus dem Kontext gerissen, an mehreren Orten zu finden)
• Wir wussten, dass wir keinen WPML-Klon erstellen oder mit Multisite-Installationen arbeiten wollten.

Das einzige andere existierende Plugin auf dem Markt, das etwas anderes tat, war WeGlot. Eine Software-as-a-Service-Implementierung, die automatische und manuelle Übersetzung anbietet. Im Grunde wird die Übersetzung Ihrer Website von deren Servern geladen.

Aus der Kombination der oben genannten Plugins und Ideen haben wir ein Konzept entwickelt, das ähnlich wie Weglot ist, sich aber in der Umsetzung deutlich unterscheidet:

Übersetzen Sie die gesamte Seite. Kein Hin- und Herschalten mehr zwischen Editor, String-Übersetzungsschnittstellen oder schlecht übersetzten Plugins. Sie können jetzt die finale Seite mit voller Unterstützung für WooCommerce und Website-Builder übersetzen.

Der Hauptunterschied liegt in der Implementierung:

• Unterstützung für dynamische Strings ( Gettext-Zeichenketten )
• alles lokal gespeichert, in Ihrer Datenbank (Sie besitzen Ihre Übersetzungen)
• ein GPL-Plugin (Zugang zum Codebasis, falls Sie etwas anderes benötigen)
• der Wunsch, dass unser Plugin mit jedem WordPress-Plugin oder -Theme funktioniert und nicht umgekehrt, dass Entwickler erst Unterstützung für Übersetzungsplugins hinzufügen müssen

Entwicklungsschätzungen

Im Januar berichtete mein Kollege Madalin Ungureanu über Tests mit dem Kern des Plugins, einer PHP-DOM-Parser-Klasse, um zu prüfen, ob wir damit arbeiten könnten. Es funktionierte recht gut: Wir konnten Zeichenfolgen in der Datenbank suchen und ersetzen, ohne die Testseite zu verlangsamen, also machten wir uns daran, das Projekt zu starten. Razvan sollte die Leitung der Entwicklung übernehmen und als 100% für die Bereitstellung der Alpha- und Beta-Versionen verantwortlich sein; ab diesem Zeitpunkt würden wir dem Projekt mehr Ressourcen zuweisen. Das war zwar nicht ideal, aber mehr konnten wir nicht tun, ohne weitere Mitarbeiter einzustellen.

3 Monate. Lass uns im April eine Alpha-/Beta-Version veröffentlichen. Im Juli begannen wir mit internen Tests und trieben einen Betastart voran. Am 31. Juli machten wir die Beta zum Download verfügbar. Der finale Launch war am 4. September, mehr als 5 Monate über unserer Schätzung.

Ich habe inzwischen auch gelernt, dass Softwareentwicklungsprojekte länger dauern als erwartet.

Wie bei dem langsamen Start habe ich inzwischen auch gelernt, dass Softwareentwicklungsprojekte länger als erwartet dauern.

Es gibt einige Ausnahmen von der Regel, aber das ist normalerweise am Ende eines Entwicklungszyklus der Fall, wenn das Problem bereits gut definiert und verstanden war, keine weitere Forschung erforderte und nur noch der Code geschrieben werden musste.

Warum hat es also länger gedauert als geschätzt?

• Offensichtlich haben wir die benötigte Zeit unterschätzt. Wir wussten wirklich nicht, wie lange es dauern wird.
• Der Zeitrahmen von 3 Monaten war eher praktischen Gründen geschuldet. Dränge das Projekt nicht in die Sommerferienzeit. (haben wir getan)
• Razvan ist noch Junior-Entwickler und dies war sein erstes großes Projekt im Unternehmen. Obwohl es ziemlich viele Diskussionen über die Entwicklungsrichtung und die Umsetzung gab, wurde in den ersten Phasen des Projekts von keinem anderen Teammitglied nennenswert eigener Code geschrieben. Daher war der Fortschritt langsam.
• Sobald ich im Juni mit dem Testen des Plugins begann, funktionierte nichts. Jedenfalls auf meiner Installation. Während Razvan versuchte, das Problem so weit wie möglich zu verallgemeinern (fast string replace), wurde uns schnell klar, dass es viel mehr Sonderfälle gab, als uns bewusst war und wofür wir Budget eingeplant hatten.

Logo-Design auf die Schnelle

Während das Plugin entwickelt wurde, konzentrierte ich mich auf das Design eines neuen Logos und Farbschemas für unsere zukünftige Website.

Ich bin absolut kein Grafikdesigner, aber ich komme ganz gut damit klar, in Photoshop ein paar Pixel zu verschieben. Ich kenne meine Grenzen und kann Quadrate, Rechtecke und Kreise ganz gut miteinander kombinieren, um etwas Akzeptables zu kreieren. Nicht großartig, aber okay. Also habe ich mir ein paar Stunden Zeit genommen und vier Vorschläge erarbeitet (die von kindlich bis einigermaßen akzeptabel reichen), die ich dem Rest des Teams gezeigt habe.

Wir haben uns für das letzte entschieden und sind fortgefahren mit dem Webseitendesign.

Alles in allem gab es wahrscheinlich 3-4 tatsächliche Arbeitstage, verteilt auf ein paar Monate um alle Grafiken und das Design zu erhalten, die wir für den Start benötigten. Das Theme war ein Klon desselben benutzerdefinierten Themes, das wir bereits bei www.cozmoslabs.com Also haben wir so wenig Zeit wie möglich darauf verwendet, das herauszubringen.

Obwohl das Design wirklich wichtig war, war es das noch mehr, dies mit minimalem Aufwand herauszubringen. Das Cozmoslabs-Design war das Ergebnis von 4 Monaten Arbeit mit einem Designer (mit viel Hin und Her) und weiteren zwei Monaten, um es vollständig zu implementieren. Wir konnten es uns zu diesem Zeitpunkt einfach nicht leisten, das zu tun. Also haben wir etwas in Ordnung gebracht und sind weitergegangen.

Monetarisierung

Wir haben früh beschlossen, dass es Free und Pro-Versionen. Sowohl unsere eigenen bisherigen Erfahrungen als auch die anderer Plugin-Entwickler in der WordPress-Community haben deutlich gemacht, dass dies der richtige Weg ist.

Nicht ganz klar war hingegen, wie wir die verschiedenen Versionen voneinander abgrenzen sollten. Zu den Elementen, die wir als Teil der Pro-Versionen betrachteten, gehörten:

• Übersetzung benutzerdefinierter Beitragstypen;
• mehrere Sprachen;
• Google Translate-API;
• SEO-Modul (Übersetzung von Slug, Seitentitel und Beschreibung).

Worauf wir uns schließlich geeinigt haben, war die Einbeziehung der SEO-Modul und Mehrsprachigkeits-Erweiterung in den Pro-Versionen + eine Differenzierung nach der Anzahl der aktiven Installationen.

Außerdem:

• Jeder Preisplan gilt für ein Jahr und verlängert sich automatisch;
• Die Pro-Versionen enthalten nur die Advanced Addons. Daher wird die kostenlose Version immer benötigt.

Start von TranslatePress – Brandneue Website, Einrichtung von Zahlungsabwicklung und Lizenzen

Um unser neues Plugin zu verkaufen, haben wir versucht, es so einfach wie möglich zu gestalten, und haben daher „Easy Digital Downloads“ und „Digital Licenses for EDD“ verwendet.

Leider waren für die Funktionsfähigkeit unserer Konfiguration individuelle Anpassungen erforderlich:

• unser Zahlungsgateway Avangate (mit eigener Programmierung, da die Avangate-API einfach seltsam ist)
• Automatische Verlängerungen über Avangate (hierfür können wir EDD nicht verwenden, sondern benötigen eine individuell programmierte Lösung)
• digitale Lizenzen für ein Produkt vom Typ “Bundle”, sodass eine Lizenz für alle Add-ons aus dem “Bundle” funktioniert (das funktioniert bei EDD nicht)

Wir wollten das All Access Pass Addon für EDD nutzen, das die digitalen Lizenzen für Bundles gelöst hätte, aber das hat für uns nicht funktioniert, weil:

• Wenn Sie einen All-Access-Pass besitzen, können Sie keinen weiteren erwerben, sondern lediglich die Lizenzlaufzeit verlängern.
• Es hat unsere automatischen Verlängerungen zerstört, die benutzerdefiniert waren (aufgrund der Art und Weise, wie Av mit automatischen Verlängerungen umgeht)
• Außerdem hat es die Upgrades beeinträchtigt, da diese aufgrund von Avangate wiederum individuell angepasst sind.

Am Ende haben wir also ein benutzerdefiniertes Add-on für EDD programmiert, das irgendwie wie All Access Pass funktioniert (der Code ist im Grunde von dem Add-on übernommen), aber ohne den All-Access-Teil 🙂

Ansonsten wurde das Theme wie bereits erwähnt von Cozmoslabs recycelt und wir haben unser eigenes verwendet Profile Builder Pro Plugin für die Funktionen „Anmelden“, „Profil bearbeiten“ und „Passwort zurücksetzen“.

Betastart

Eine Möglichkeit, einem Produkt Schwung zu verleihen, ist eine Beta-Einführung. Zwar gibt es noch andere Gründe für eine Beta-Einführung (Fehlermeldung), doch meine Erfahrungen mit anderen Plugins in der Vergangenheit haben gezeigt, dass Der größte Vorteil ist die Möglichkeit, über Ihr Produkt zu sprechen, auch wenn es noch nicht funktioniert. 🙂

Auch wenn das Ganze etwas oberflächlich ist, ist es doch einfach ein weiteres Marketinginstrument, das man nutzen kann. Und als Bonus haben wir auch ein paar fundierte Fehler- und Funktionsmeldungen erhalten, die deutlich gemacht haben, dass uns bei der Beta-Version etwas Entscheidendes gefehlt hat: Es gab keine Unterstützung für Gettext-Felder.

Die Unterstützung für gettext-Felder war eine der wichtigsten Funktionen, die wir eigentlich erst NACH dem Start einführen wollten. Da wir uns jedoch immer intensiver mit dem Plugin beschäftigt haben und die Rückmeldungen unserer Beta-Nutzer dazu gehört haben, haben wir den Sprung gewagt und direkt nach dem Beta-Start des Plugins mit der Arbeit an dieser Funktion begonnen.

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 mehreren Sprachen” (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 Demoseite);
• 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.