Ein gutes Produkt kann vollständig unsichtbar bleiben, wenn seine Entwicklung nur im Git-Verlauf stattfindet. Wer regelmäßig shippt, aber öffentlich nichts davon zeigt, nimmt potenziellen Kunden jede Gelegenheit, das Produkt zu entdecken, zu verstehen und ihm zu vertrauen.
Marcus ist eine erfundene Figur, zusammengesetzt aus einem vertrauten Gründerproblem. An einem Donnerstagabend sitzt er mit kaltem Kaffee in einer Berliner Altbauküche und aktualisiert die Statistik seines neuen Releases. Am Vortag hatte er eine Funktion veröffentlicht, an der er mehrere Wochen gearbeitet hatte. Die Produktseite steht, der Checkout funktioniert, der Changelog enthält sechs sauber formulierte Einträge.
Es gibt trotzdem keine neue Anmeldung.
Am Montag muss Marcus entscheiden, ob er weiter an diesem Produkt arbeitet oder wieder mehr Aufträge annimmt. Ohne erste zahlende Kunden reicht sein Puffer nicht für beides. Sein GitHub-Profil zeigt grüne Kästchen bis an den Rand. Seine öffentlichen Kanäle zeigen den letzten Beitrag vom Frühjahr.
Zwei Zeitlinien erzählen zwei verschiedene Geschichten
Der Commit-Verlauf erzählt von Fortschritt:
`fix: token refresh after reconnect`
`feat: export filtered results`
`docs: add self-hosting guide`
Die öffentliche Zeitlinie erzählt etwas anderes: Hier passiert nichts.
Interessenten können den Code nicht aus Marcus’ Perspektive lesen. Sie sehen weder die schwierige Entscheidung hinter dem neuen Export noch den Supportfall, der zum Token-Fix führte. Sie wissen auch nicht, warum die Anleitung für selbst gehostete Installationen für ihr Team wichtig sein könnte.
So entsteht eine unangenehme Lücke. Marcus hat Beweise dafür, dass er sein Produkt verbessert. Diese Beweise liegen jedoch an einem Ort, den fast nur andere Entwickler besuchen. Seine potenziellen Käufer sehen weder das Problem noch die Lösung.
Das Schweigen wirkt außerdem länger, als es ist. Ein leerer Feed kann bedeuten, dass der Gründer konzentriert arbeitet. Für Außenstehende kann er ebenso gut bedeuten, dass das Produkt ruht, aufgegeben wurde oder nie über einen ersten Versuch hinausgekommen ist.
Ein Commit ist Rohmaterial für eine verständliche Geschichte
Marcus braucht keine künstliche Gründerpersönlichkeit und keinen täglichen Motivationsbeitrag. Er muss übersetzen, was ohnehin geschieht.
Aus `feat: export filtered results` wird zum Beispiel:
„Wer eine lange Ergebnisliste geprüft hat, musste bisher alles exportieren und anschließend wieder aussortieren. Ab heute enthält der Export genau die aktuell gesetzten Filter.“
Der Commit beschreibt die technische Änderung. Der Beitrag beschreibt den Moment, in dem ein Nutzer davon profitiert.
Diese Übersetzung lässt sich mit drei Fragen strukturieren:
- Welches konkrete Problem hat die Änderung ausgelöst?
- Was kann ein Nutzer jetzt tun, was vorher umständlich oder unmöglich war?
- Wer sollte davon heute erfahren?
Eine Änderung kann anschließend mehrere brauchbare Formate liefern: einen kurzen Beitrag, einen Abschnitt im Newsletter, ein Video mit echter Produktaufnahme und einen ausführlicheren Artikel. Wie aus einem Produktupdate fünf Formate werden beginnt genau bei diesem vorhandenen Material.
Entscheidend ist die gemeinsame Grundlage. Zielgruppe, Positionierung, Brand Voice und Kanalstrategie sollten pro Produkt feststehen, bevor aus jedem Commit neue Texte entstehen. Sonst erklären sieben Veröffentlichungen dieselbe Funktion auf sieben widersprüchliche Arten. Sieben Launch-Entwürfe sollten nicht sieben Produkte erfinden.
Der Wendepunkt liegt im Wochenrhythmus
Am Freitagmorgen legt Marcus seine beiden Zeitlinien nebeneinander. Links stehen die Änderungen der vergangenen Woche. Rechts stehen die Kanäle, auf denen seine Zielgruppe tatsächlich mitliest.
Er wählt keinen beliebigen Commit. Er nimmt den Token-Fix, weil dahinter ein verständlicher Schmerz steckt: Eine unterbrochene Verbindung zwang Nutzer bisher zu einem zusätzlichen Schritt. Marcus schreibt einen kurzen Beitrag, zeichnet den Ablauf im Produkt auf und setzt das Thema in seinen Redaktionskalender.
Marketing Agent kann diesen Ablauf aus einer gemeinsamen Produktstrategie unterstützen: relevante Themen und Trends finden, Content und Videos für verschiedene Kanäle erstellen und freigegebene Beiträge dort veröffentlichen, wo die jeweilige Anbindung es erlaubt. Wer feste Grenzen definiert, kann Teile davon unbeaufsichtigt ausführen lassen. Freigaben, Budgets, tägliche Sicherheitsgrenzen und pausierte Funktionen bleiben produktbezogen steuerbar.
Das nimmt Marcus die Übersetzungsarbeit nicht vollständig ab. Er entscheidet weiterhin, welche Änderung wichtig ist, welche Aussage stimmt und was veröffentlicht werden darf. Die wiederkehrenden Handgriffe müssen jedoch nicht jedes Mal bei null beginnen.
Sichtbarkeit beginnt mit einer kleinen, belastbaren Gewohnheit
Am folgenden Donnerstag steht in Marcus’ Git-Verlauf wieder eine Reihe neuer Commits. Dieses Mal ist seine öffentliche Zeitlinie nicht leer. Dort finden sich ein erklärter Fehler, eine kurze Bildschirmaufnahme und ein Artikel über das Problem hinter dem Export.
Noch ist daraus kein Beweis für Umsatz entstanden. Marcus behauptet auch keinen. Der Unterschied ist konkreter: Menschen außerhalb von GitHub können nun erkennen, für wen das Produkt gedacht ist, welche Probleme es löst und dass es weiterentwickelt wird.
Die praktikable Regel lautet: Prüfe einmal pro Woche deine Commits und wähle eine Änderung mit erkennbarem Kundennutzen. Formuliere zuerst das Problem, dann die Veränderung und zuletzt den nächsten sinnvollen Schritt für den Leser.
Dein Commit-Verlauf dokumentiert, dass du gearbeitet hast. Deine öffentliche Zeitlinie muss erklären, warum diese Arbeit für jemanden zählt.
Kommentare
Noch keine Kommentare.