Notizen zum Bau eines ruhigen Produkts

Mole for Mac hat etwa drei Wochen nach dem Start einen kleinen Verkaufsmeilenstein erreicht. Statt über Zahlen zu schreiben, möchte ich ein paar Entscheidungen festhalten, die ich unterwegs getroffen habe, denn die meisten davon laufen den Instinkten eines praktizierenden Ingenieurs zuwider, und es sind genau die Entscheidungen, die ich als Erstes verteidigen würde. Wenn Sie Ihr eigenes Produkt bauen, spart Ihnen das vielleicht den einen oder anderen Umweg.

Ich beantworte jede E-Mail selbst

Jeder Support-Fall seit dem Start lief von Hand: Rückerstattungen, Zurücksetzen der Aktivierung, Erstattung einer Preisdifferenz nach einem Rabatt, ganz gewöhnliche Fragen. Das Volumen ist klein, deutlich unter einem Prozent der Nutzer schreibt überhaupt, und ich hätte in einer halben Stunde einen Agenten dafür anbinden können. Ich habe mich dagegen entschieden, aus zwei Gründen.

Erstens: Im Support sagt Ihnen das Produkt die Wahrheit. Eine Rückerstattungsanfrage erzählt, warum das Produkt jemanden enttäuscht hat. Eine ungeschickte Frage zeigt, welcher Teil der App sich nicht selbst erklärt. Ein paar E-Mails hin und her legen offen, was der Nutzer eigentlich wollte, und das ist oft etwas anderes als die erste Formulierung. Filtern Sie das am ersten Tag durch Automatisierung, verlieren Sie genau das Signal, das Sie am dringendsten brauchen.

Zweitens: Jeder Fall macht Sie flüssig. Nach genug Runden kennen Sie die beste Antwort auf jede Problemklasse, und Sie wissen, welche Probleme das Produkt absorbieren sollte, damit die Frage gar nicht erst gestellt wird. Wenn das Volumen wächst und ich dann Automatisierung einführe, wird sie diese Flüssigkeit abbilden, statt auf Rätselraten zu setzen.

Mein Schwellenwert für Automatisierung ist keine Ticket-Zahl. Die Frage soll sich wiederholen, die Antwort stabil bleiben und die Ausnahmen verstanden sein. Bis dahin ist das unordentliche Gespräch die Recherche. Danach kann die Automatisierung den bekannten Pfad übernehmen und den ungewöhnlichen Fall leicht zu einem Menschen durchreichen.

Bisher hält der Ansatz: Ich habe nichts für Marketing ausgegeben, das Wachstum läuft über Mundpropaganda, und die Rückerstattungsquote liegt unter 0,8 Prozent.

Das Gerüst kann warten

Dieselbe Logik gilt für die Infrastruktur. Vor dem Start habe ich kein Ticket-System, kein Helpdesk und keine Wissensdatenbank aufgesetzt. Ingenieure bauen gern zuerst die begleitende Maschinerie, weil sie den Teil kennen, und KI hat daraus einen Halbtagsjob gemacht, was die Versuchung erhöht und die verfrühte Optimierung genauso leicht macht. Der halbe Tag ist real; real ist auch die laufende Pflege eines Systems, das Sie noch nicht brauchten. Ich würde das System einführen, wenn das Fehlen Anfragen verliert, Antwortzeiten verschleiert oder dieselbe Antwort inkonsistent macht. Davor ist der Posteingang einfacher und informativer.

Entscheiden, was man nicht baut

Der Unterschied zwischen einem guten und einem durchschnittlichen Produkt liegt vor allem in dem, was es ablehnt. Welche Funktionen in welche Version gehören, welche Wünsche echte Bedürfnisse sind und welche nur so klingen, welche wirklich guten Ideen trotzdem nicht in dieses Produkt gehören. Ich habe mich bei Nutzern entschuldigt, die Features vorgeschlagen haben, die für sich genommen gut waren, weil ein Mac viele nette Tricks kennt, die Mole nicht ausführen sollte. Sagen Sie zu allem ja, entsteht ein Eintopf, und ein Eintopf ist schwer zu pflegen und noch schwerer, wenn man ihm das Löschen von Dateien anvertrauen soll.

Ich behalte ungefähr ein halbes Jahr des Produktwegs im Kopf: was jede Version hinzufügt, was draußen bleibt, und wo Dinge landen, damit ein Erstnutzer sie ohne Anleitung findet. Wenn die häufigste erste Aufgabe ein Handbuch braucht, hat die Oberfläche die Menschen im Stich gelassen, die ich am meisten erreichen will. Dokumentation bleibt wichtig für Tiefe, Randfälle und Vertrauen, aber sie sollte die Grundform des Produkts nicht retten. Die alte Regel sagt es am besten: Fügen Sie keine Entität hinzu, wenn sie nicht nötig ist.

Vor der Roadmap prüfe ich heute drei Vetos. Es soll keinen dauerhaft laufenden Timer, Listener oder Sampling-Kosten erzeugen, solange der Nutzer die Funktion nicht betreten hat. Es soll den privilegierten Helper nicht erweitern und keine neue Berechtigung verlangen, nur um eine kleine Bequemlichkeit möglich zu machen. Und es soll keine Einstellung hinzufügen, wenn eine ruhige Voreinstellung die Entscheidung für alle treffen kann. Das sind keine universellen Regeln für Software. Es ist ein Budget für dieses Produkt: Residenzarbeit, Privilegien und Konfiguration sind Formen von Oberfläche, der Nutzer für immer vertrauen müssen.

Die Position

Moles Position ist ein Satz: ein stiller Hüter für Ihren Mac. Es räumt auf, deinstalliert, optimiert, analysiert und beobachtet, und hält sich ansonsten zurück. Der Anspruch lässt sich einfach sagen: Wenn einer von hundert Mac-Nutzern Mole behält, ist es wirklich nützlich geworden. Kürzlich begannen sehbehinderte Nutzer, es zu verwenden, und stießen auf raue Kanten, daher rückten Barrierefreiheits-Fixes vor neue Features. Ich freue mich darauf, wie sich die App für sie anfühlt; ein stiller Hüter sollte für alle still sein.

Produkte im KI-Zeitalter menschlich halten

KI hat viel an diesem Produkt erst möglich gemacht. Sie hat das Gespräch mit den Menschen, die es nutzen, nicht ersetzt, und ich glaube, das sollte sie auch nicht. Effizienz lässt sich heute leicht kaufen; das Gefühl und Vertrauen zwischen einem Entwickler und seinen Nutzern muss man weiterhin Gespräch für Gespräch verdienen. Vielleicht bleibt so bei Produkten, die mit KI gebaut werden, die menschliche Wärme: Der Code kann generiert werden, die Beziehung nicht.

Dies ist mein erstes bezahltes Produkt, und manche dieser Entscheidungen können sich als falsch erweisen. Wenn Sie diesen Weg länger gegangen sind als ich und sehen, dass ich etwas Unkluges tue, würde ich das gern hören. Wie Mole überhaupt hierherkam, ist eine längere Geschichte, erzählt in Von einem 500-Zeilen-Shell-Skript zur Mac-App.