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.

Dies ist einer der größten Fehler, die wir aus Entwicklungssicht hätten machen können, und einer der Gründe, warum wir so lange gebraucht haben, um Version 1.0 zu veröffentlichen. Wir haben die Unterstützung für gettext verzögert, da sie schwer zu implementieren war.

Eine lustige Geschichte darüber, wie wir angefangen haben, ist, dass wir nach dem Beta-Start einen einstündigen Stromausfall im Büro hatten. Während ich darauf wartete, dass der Strom zurückkam, fing ich an, meine Tastatur zu putzen. Es gab sowieso nichts Besseres zu tun, also machte ich ein Foto von der Tastatur, entfernte alle Tastenkappen und reinigte sie eine nach der anderen mit ein bisschen Reinigungsalkohol und einem Lappen.

Und in den nächsten 2 Stunden reinigte ich meine Tastatur und erstellte eine mentale Mindmap der Gettext-Implementierung in WordPress, wie unser Plugin Strings übersetzte und wie wir beides kombinieren konnten, ohne später Leistungsprobleme zu bekommen.

Danach hatte ich eine kurze Besprechung mit Madalin über gettext, wir beschlossen, dass wir es jetzt tun sollten, vor dem Start von Version 1.0, und ER machte sich an die Arbeit.

Aus dieser Geschichte lassen sich einige Lehren ziehen:

• Es ist keine gute Idee, komplizierte Funktionen ohne triftigen Grund aufzuschieben. Wir wussten, dass es kompliziert werden würde, deshalb haben wir es so lange hinausgezögert;
• Während die zwei Stunden Nachdenken über gettext in Bezug auf die tatsächliche Entwicklungszeit absolut nichts bewirkten (es dauerte einen Monat Arbeit für Madalin, bis es lief, und er ist nun im zweiten Monat dabei, sich mit wp_ajax und gettext herumzuschlagen), waren sie unendlich viel besser, als gar nicht darüber nachzudenken. Sie waren genau das, was wir brauchten, um eine Entscheidung zu treffen und weiterzukommen.

Zur Bewerbung der Beta haben wir:

• Ich habe einen Beta-Artikel geschrieben, der auch für folgendes Keyword SEO-optimiert ist: “WordPress in mehreren Sprachen”(es macht keinen Sinn, 2000+ Wörter zu schreiben, ohne in Zukunft auf ein bisschen SEO-Traffic zu hoffen.);
• einen Newsletter über das neue Plugin an unsere bestehenden Kunden bei Cozmoslabs gesendet;
• auf der TranslatePress-Website ordentliche Formulare zur “Anmeldung für die Beta-Version” bereitgestellt hatte;
• Zwei Wochen nach Beginn der Beta-Version baten wir die 100 Personen, die sich für die Beta-Version angemeldet hatten, um Feedback (dazu nutzten wir Mailchimp);
• Für weitere zwei Wochen schalteten wir Facebook-Anzeigen, die unsere Beta-Tester auf 160 erhöhten.

Version 1.0

Wir brauchten einen Monat entwickeln → Test → beheben Schritte, um die Gettext-Implementierung für von PHP gerenderte Strings (normale Seitentemplates) zum Laufen zu bringen.

Wir hatten immer noch keine Gettext-Unterstützung für wp_ajax-Aufrufe, aber Es war wichtig, jetzt und nicht später zu starten:

• Hätten wir die Fertigstellung verzögert, hätten wir Zeit für Marketing verloren (oder zumindest dafür zu sehen, was funktioniert und was nicht). Wenn es kein Produkt gibt, können wir nicht über das Produkt sprechen;
• wir hätten die Gelegenheit verpassen können WordCamp Bukarest sponsern Das passiert im Oktober;
• Sobald die Website, das Zahlungs-Gateway, die Lizenzen, der Support und die Dokumentation eingerichtet sind, müssen wir nur noch am Produkt arbeiten.

Marketing

Seit dem Beta-Start haben wir begonnen, über die Vermarktung des Plugins nachzudenken.

Ein Freemium-Geschäftsmodell bedeutet, dass wir von einer großen Anzahl an kostenlosen Nutzern und aktiven Installationen abhängig sind.

Mit einem neuen Plugin ist das viel schwieriger, als man vielleicht denkt, insbesondere angesichts des neuen WordPress-Verzeichnisses, das aktive Installationen, Bewertungen, die Anzahl der beantworteten Fragen in den Foren und andere quantitative Elemente berücksichtigt, auf die wir keinen Einfluss haben.

Unsere Bemühungen waren also darauf ausgerichtet, so viele WordPress-Administratoren wie möglich zu erreichen: 

• Wir haben Cross-Promotion in unsere anderen Plugins integriert (TranslatePress kann unsere anderen Plugins übersetzen, daher haben wir es in unserem Abschnitt „Empfohlene Plugins“ aufgeführt);
• Ich habe den kostenlosen Download zur Kontoseite aller unserer Kunden bei Cozmoslabs hinzugefügt;
• in Kontakt getreten mit ThemeIsle TranslatePress in die Liste der empfohlenen Plugins aufzunehmen, da es sich hervorragend zur Übersetzung ihrer komplexen Themes eignet (wir verwenden Hestia für unser Demoseite);
• das Sponsoring von WordCamp Bukarest und die Gelegenheit, mit potenziellen Nutzern von Angesicht zu Angesicht zu sprechen.

All diese Bemühungen sind gerade am Anfang besonders wichtig, um ein wenig Aufmerksamkeit zu erregen, damit TranslatePress in den Suchergebnissen von WordPress.org erscheint.

Wir haben versucht, so wenig wie möglich wie Spam zu wirken, falls es das überhaupt gibt. Wir haben keine Benachrichtigungen verwendet, die auf allen Backend-Seiten erscheinen, oder unseren bestehenden Kunden Newsletter um Newsletter geschickt (nur zwei für die Beta- und die Version-1.0-Einführung).

Zukünftige Marketingpläne:

• Wir planen, Tutorials für viele beliebte Themes und deren Übersetzung zu erstellen (danke Ionut);
• Setzen Sie unsere Outreach-Aktivitäten für Plugin- und Theme-Entwickler fort. Wir wollen Unterstützung für Plugins hinzufügen, nicht dass Plugins Unterstützung für uns hinzufügen müssen;
• Content-Marketing für mehrere Sprachen ist schwierig, weil wir in den Suchmaschinen nicht weit oben ranken werden. Jedenfalls nicht am Anfang. Während wir also an dieser Front aktiv sein werden, ist das für uns im Moment nicht von großer Bedeutung.

Erkenntnisse aus unserer TranslatePress-Einführung

Das Wichtigste, das ich an diesem achtmonatigen Prozess hervorheben möchte, ist, dass es nicht das Ende der Fahnenstange ist. Mangelndes Interesse am Anfang ist normal. Wenige bis gar keine Downloads sind normal. Wenig bis gar kein Feedback ist normal.

Anstatt mir über all das Sorgen zu machen, habe ich begonnen, erste Markteinführungen so zu sehen, wie sie wirklich sind: Struktur, auf der das Unternehmen das Produkt aufbauen und in Zukunft vermarkten kann.

Der echte Erfolg oder Misserfolg kommt zu einer viel späterer Zeitpunkt.

Es war für mich sogar komisch zu sehen, wie schlecht die anfänglichen Launches sind, und Wetten mit dem Rest des Teams abzuschließen, die fast immer viel optimistischer sind 🙂

Zum Schluss noch eine Liste der Erkenntnisse, die wir in den vergangenen acht Monaten im Zusammenhang mit der Einführung von TranslatePress gewonnen haben:

• startet als Aufbau der Projektstruktur. Einmal draußen können Sie am Marketing und der Verbesserung des Produkts arbeiten;
• Verschiebe nicht das Nachdenken über komplizierte Teile des Projekts. Sie können sich dafür entscheiden, sie in Version 1.0 einzubeziehen oder nicht, aber Sie dürfen niemals, absolut niemals nicht an sie denken;
• Bitte um Feedback von anderen Personen aus der Community. Ich hatte einige wirklich interessante Gespräche mit der PostStatus-Community (technisch), mit lokalen WordPress-Leuten, die mehrsprachige Websites implementieren (über Funktionen), mit tatsächlichen Benutzern (sie mochten die benutzerfreundliche Oberfläche, wenn das Plugin nur für alle Strings funktionieren würde 🙂 ), mit anderen WordPress-Produktleuten (Marketing). Zukünftige Funktionen, technische Entscheidungen und das Marketing werden durch dieses Feedback beeinflusst;
• Wende die nötige Zeit für wichtige Funktionen auf. Wir haben viel Zeit in die Gettext-Implementierung investiert und tun dies weiterhin. Sie ist das eine Element, das das gesamte Plugin so vielseitig macht, also muss sie funktionieren;
• Es sei denn, Sie verkaufen tatsächliche Designarbeiten, verwenden Sie nicht viel Zeit auf das Website-Design. Konzentrieren Sie sich stattdessen darauf, den Inhalt verständlich zu machen, ohne ausgefallene Wörter, und so zu strukturieren, dass er für eine nicht-technische Person nicht allzu kompliziert ist. Wenn Sie nicht sicher sind, wo Sie anfangen sollen, gehen Sie einfach zu AffiliateWP und ihre Content-Struktur stehlen. Niemand wird es merken;
• Alles, was man einmal einrichten und dann vergessen kann, sollte frühzeitig erledigt werden. Wenn Sie keine Standard-Tools für den Verkauf Ihres Plugins nutzen können, programmieren Sie diese jetzt selbst, sofern Sie über die entsprechenden Kenntnisse verfügen. Sobald die Infrastruktur steht, können wir uns im nächsten Jahr oder länger voll und ganz auf das Plugin konzentrieren, ohne uns Gedanken über Änderungen der Preisstruktur, Verlängerungen, Konten usw. machen zu müssen.

Also ist das Anfang unseres TranslatePress-Abenteuers.

Wenn Sie es geschafft haben, das alles zu lesen, vielen Dank für Ihre Zeit! Und versuchen Sie TranslatePress, und sei es nur, um damit zu spielen. So cool ist das!

[HINWEIS]: Dieser Artikel über die Markteinführung des TranslatePress wurde ursprünglich in der Beitragsstatus Newsletter.