SaaS
Sie liefern alle zwei Wochen aus und schreiben darüber zweimal im Jahr
Softwareteams mangelt es nicht an Themen. Ihnen fehlt die Person, die sie ausspricht, denn Schreiben ist immer die Aufgabe, die verschoben wird, wenn der Release spät dran ist – und sie wird jedes Mal verschoben, bis der letzte Blogbeitrag elf Monate alt ist und „Wir stellen vor“ sagt.
Der Fehler ist strukturell, nicht redaktionell
Jedes Team weiß, dass es mehr schreiben sollte. Die Ingenieure können schreiben; der Gründer kann schreiben; irgendjemand macht es meistens gern. Das Problem: Schreiben hat keine eigene Deadline, und alles ohne Deadline verliert gegen alles mit einer – alle zwei Wochen, für immer.
Ein Plan liefert die fehlende Deadline. Ein datierter Slot mit Thema und Autor ist ein Versprechen, das in einer ruhigen Woche gegeben und in einer unruhigen Woche eingelöst wird – und der Entwurf erscheint, ob sich jemand erinnert oder nicht. Freigeben dauert Minuten; von Null schreiben kostet einen Nachmittag, der nie kommt.
Das ist das ganze Argument. Nicht, dass ein Modell besser schreibt als Ihr Team – tut es nicht. Sondern: Ein Entwurf, den Sie am Dienstag bearbeiten, existiert. Ein Beitrag, den Sie schreiben wollten, nicht.
Eine Roadmap ist ein Plan, den Sie bereits geschrieben haben
Der Großteil der sechs Monate ist schon entschieden. Sie wissen ungefähr, was in den nächsten zwei Quartalen ausgeliefert wird, welche Teile des Produkts missverstanden werden, welche Integrationen immer wieder erfragt werden und welche Fragen jede einzelne Woche im Support landen.
Jedes davon ist ein Thema. Die Roadmap liefert den Takt – ein Release wird zu einer Reihe von Slots statt zu einem einzigen Changelog-Eintrag – und der Support liefert die Evergreen-Hälfte, denn eine Frage, die zwanzigmal im Monat gestellt wird, ist ein Beitrag, den man einmal schreibt und für immer verlinkt.
Lassen Sie Lücken. Releases verzögern sich, und ein Plan ohne leere Slots macht aus einem verzögerten Release drei Beiträge über etwas, das noch nicht existiert. Ein Viertel der Slots offen zu lassen ist keine Nachlässigkeit; es ist der Teil des Plans, der den Kontakt mit Ihrem echten Zeitplan überlebt.
- 1BlogWas ausgeliefert wurde und warum es existiert. Zuerst das Problem, dann das Feature.
- 2Facebook / InstagramDie Ein-Satz-Version, für Leute, die niemals ein Changelog öffnen werden.
- 3BlogWie jemand das tatsächlich benutzt hat. Konkret, mit den unangenehmen Stellen drin.
- ·Falls es sich verschiebtDie Slots bewegen sich mit dem Release. Nichts kündigt etwas an, das nicht existiert.
- 4BlogDie Support-Frage, die dieser Release endlich beantwortet, einmal formuliert.
Die Roadmap gibt den Takt vorDer Support gibt die Themen vor
Ihr Changelog ist kein Content. Es ist ein Beleg.
Zwei Autoren, manchmal drei
Der eine erklärt das Produkt, der andere spricht über das Unternehmen
Das sind wirklich unterschiedliche Stimmen, und ihre Vermischung erzeugt genau die blande Einförmigkeit, für die Software-Blogs bekannt sind — ein Beitrag, der weder eine technische Erklärung noch ein menschlicher Bericht über irgendetwas ist.
Der technische Autor
Erklärt präzise, was etwas tut, ohne Adjektive. Weiß, wofür Ihr Produkt gedacht ist und wofür nicht, und darf das auch sagen. Das ist der Autor, dessen Beiträge in Support-Tickets verlinkt werden.
Die Unternehmensstimme
Schreibt über Entscheidungen, Abwägungen und das, worauf Sie hinarbeiten. Nützlich auf eine Weise, die schwer zu messen, aber offensichtlich ist — beim Recruiting, in Sales-Gesprächen und darin, warum jemand einen kleinen statt eines großen Anbieters wählt.
Die Antwortende
Bearbeitet Kommentare gemäß Ihrer Richtlinie. Beantwortet, was es kann, markiert, was es nicht kann, und spekuliert nie über eine Roadmap. Alles, was nach einem Support-Vorfall aussieht, geht sofort an eine Person.
Die Freigabe-Schwelle leistet hier echte Arbeit
Für eine Bäckerei ist ein nicht freigegebener Beitrag eine kleine Peinlichkeit. Für ein Softwareunternehmen ist er eine Support-Last, ein Sales-Einwand oder ein Versprechen, dem niemand zugestimmt hat. Ein Entwurf, der eine Grenze leicht falsch beschreibt, wird Ihnen von einem Kunden wörtlich zurückgespielt, und ein Entwurf, der ein Datum andeutet, wird als Zusage behandelt.
Das ist also der Fall, bei dem Autopilot die größte Vorsicht verdient. Eine sinnvolle Regelung ist Autopilot für die kurzen Social-Slots, die etwas bereits Veröffentlichtes wiedergeben, und Freigabe für alles, was eine Aussage über das Produkt macht. Alles zu Preisen, Kapazitäten oder Terminen sollte dauerhaft von einer Person gelesen werden, und es lohnt sich, das in die Regeln des Autors zu schreiben, damit Entwürfe dieser Art zurückgehalten und markiert werden, statt in die Warteschlange zu wandern.
Was der Bericht einem kleinen Team sagt
Geplant versus veröffentlicht ist die Zahl, die zählt, und für ein Softwareteam ist sie im ersten Quartal meist unangenehm. Sie ist auch das einzige ehrliche Maß dafür, ob das Schreiben nicht wieder gegen den Release verloren hat.
Die Resonanz ist weniger wichtig, als sie aussieht. Ein technischer Beitrag findet sein Publikum über Monate, nicht Tage, und ihn in Woche zwei zu bewerten, führt dazu, dass Sie die Beiträge einstampeln, die funktionieren würden. Die Themenbalance ist am Anfang nützlicher: Sie zeigt, ob Sie nur über das schreiben, was ausgeliefert wurde — der Standard-Fehlermodus und der Grund, warum so viele Software-Blogs wie ein Changelog mit Absätzen klingen.
Der ehrliche Teil: Wenn Ihr Produkt wirklich technisch ist, brauchen die tiefsten Beiträge weiterhin einen Ingenieur für einen Nachmittag. Was ein Plan ändert, ist, dass diese Nachmittage eingeplant werden und die übrigen achtzig Prozent des Schreibens nicht mehr mit ihnen konkurrieren.