The FIP Journal #8: Roadmap zu 2'000 Nutzern & JTBD-Priorisierung

Marc & Patrik
7 min read

Patrik

Kluge Worte der Woche

“Produktivität bedeutet nicht, mehr zu tun; es bedeutet, das zu tun, was zählt.”
— Angelehnt an Philosophien der kontinuierlichen Verbesserung (oder Senecas “Überall zu sein heisst, nirgends zu sein.”)

Journal

Nach ein paar Wochen mit Fehlerbehebungen und Kern-Refactorings ist es schön, wieder bei der Feature-Entwicklung zu sein.

Zu priorisieren, welche Features wir umsetzen, ist entscheidend, und wir haben zwei starke Strategien dafür.

Erstens, unsere eigene High-Level-Roadmap. Sie lässt uns Aufgaben sehr grob in Kategorien einteilen:

  • v0.7, funktioniert für 2 Nutzer: alle Features, die Marc und ich brauchen, um das Tool zu nutzen, mit Fokus auf die Berechnungs-Engine. Das UI war praktisch nicht vorhanden und bestand darin, die Resultate in ein Spreadsheet zu importieren, aber es hat unsere Fragen beantwortet und ein paar Hypothesen über das Produkt validiert.
  • v0.8, funktioniert für 20 Nutzer: das ist alles, was nötig ist, um 20 frühe Nutzer zu bedienen; viel Arbeit auf unserer Seite ist noch manuell, weil wir nichts bauen wollen, was niemand braucht. Wir haben Input und Output über das Spreadsheet mit Google Apps Script automatisiert. Doch wegen der Einschränkungen des Tools und weil es ein (Wegwerf-)Prototyp war, gab es immer noch viel manuelle Arbeit wegen fehlender Dokumentation und fehlender Features. Die manuelle Arbeit ist hier akzeptabel: Die Anzahl der Nutzer ist begrenzt, und wir brauchen den engen Kontakt, um so viel Feedback wie möglich zu sammeln.
  • v0.9, funktioniert für 200 Nutzer: beim Hochskalieren bedeutet das, dass die meisten Kern-Features implementiert und der grösste Teil des Workflows automatisiert ist. Die Kern-Features hier sind ein einfaches Web-UI statt eines Spreadsheets und die Automatisierung des Zahlungsflusses mit Stripe. Ein grosses Problem ist die fehlende Dokumentation, weil sie uns mit Support-Anfragen von Nutzern überschwemmt. Unsere Lösung hier: Ich beantworte die technischen Fragen; Marc sammelt die Antworten und nutzt sie, um die Dokumentation zu generieren.
  • v1.0, funktioniert für 2'000 Nutzer: vollständig skalierbarer Workflow ohne unsere Interaktion. Alle Kern-Features sind implementiert.

Wir sind aktuell bei v0.9.4. Ich arbeite an der 5. Iteration, die mehr Ereignisse (wie von unseren Nutzern gewünscht) enthalten, einige Reibungspunkte im Produkt beseitigen und mehr Automatisierung hinzufügen wird.

Die andere Strategie zur Priorisierung ist natürlich das Nutzer-Feedback. Es ist eine Mischung aus blockierenden Problemen, die behoben werden müssen, Features, die alle wollen, und Features, die offensichtlich umzusetzen sind, weil ich ohnehin schon an diesem Teil des Systems arbeite.

Und wie ich schon in FIP Journal #2 gesagt habe, schafft Knappheit Klarheit. Begrenzte Zeit erzwingt ganz natürlich eine gewisse Priorisierung. Unnötig zu erwähnen, dass alles mindestens doppelt so lange dauert wie geplant.

Wie habe ich AI diese Woche genutzt?

Diese Woche war reine Umsetzung, also nutze ich die Tools einfach so, wie ich es bereits beschrieben habe. Ich habe weiterhin intensiv Cursors Plan-Modus genutzt. Ich bin grösstenteils zufrieden damit, ich kann mehr Probleme im Plan erkennen, als ich später im Code beheben müsste.

Da die Pläne grösser werden, muss ich aufpassen, nicht zu selbstgefällig zu werden und nicht einfach alles durchzuwinken, was die AI vorschlägt, ohne es richtig zu prüfen, weil das später Probleme verursacht, wenn sie teurer zu beheben sind.

Ich habe bereits angefangen, zwei Ebenen von Reviews zu machen. Die Berechnungs-Engine ist mir wichtig, also überprüfe ich den Code besonders sorgfältig, bis hin zu den Coding-Idiomen, weil ich derjenige bin, der ihn pflegen muss. Beim Frontend bin ich viel entspannter, aus zwei Gründen: Dieser Code ist weniger kritisch, und das UI-Resultat scheint hier besser zu sein, aber ich denke auch, dass das Frontend wahrscheinlich kurzlebiger ist und wir nach v1.0 vermutlich radikale Verbesserungen am UI angehen werden. Ausserdem hat ein früheres Experiment gezeigt, dass ich die AI bitten kann, das komplette Frontend neu zu generieren, und es funktioniert tatsächlich.

Freunde und Kollegen streiten ständig darüber, welches Modell das beste ist, und ein vertrauenswürdiger Freund hat es so zusammengefasst: Claude ist aktuell am besten für Nicht-Ingenieure, während Codex besser für Leute mit einem Ingenieurs-Mindset geeignet ist. Oder Marc, der auf einen Podcast verweist, der argumentiert, dass HTML Markdown ablösen wird, weil es den Umgang mit Plänen einfacher macht. Aber das sind alles Probleme, um die ich mich nicht kümmern will: Ich will einfach nur mein Produkt ausliefern, und ich frage mich, warum das überhaupt ein Problem ist: AI ist super in der Klassifizierung, also wie kommt es, dass sie nicht für mich entscheiden kann, welches Modell das beste für meine Anfrage ist?


Marc

Produktseite

Jetzt, wo Patrik die AHV/AVS-Fixes und das Refactoring fertiggestellt hat, bin ich mit Volldampf zurück in die Discovery und das Onboarding der Wartelisten-Mitglieder gesprungen.

Discovery: wie in einer früheren Journal-Ausgabe besprochen, nutze ich für diesen Teil das Jobs-to-Be-Done-Framework (JTBD). Es hilft mir, die Kräfte hinter den Leuten zu verstehen, die FI Planner abonnieren, und hinter jenen, die zögern oder nichts tun.

Ich wollte unser finales Demo-Video verfügbar haben (schau hier auf der Startseite, falls du neugierig bist, es dauert etwa 1min) sowie die zuletzt entdeckten Bugs behoben, um einige Gespräche zu vertiefen. Tatsächlich sollten einige davon neue Kunden konvertieren. Was auch passiert ist, also bin ich froh, dass wir gewartet haben.

Die meisten Erkenntnisse, die wir rund um Produkt und Pricing gewonnen haben, waren nicht neu und haben bestätigt, was wir mit früheren Nutzern und Kunden gelernt haben. Ich werde diese Insights über die nächsten Monate weiter sammeln (und dabei sicherstellen, dass ich den Job to Be Done hinter der Anfrage vollständig verstehe), bevor ich auf Basis von nur 2-3 Nutzern zu schnell etwas ändere. Allerdings können wir dasselbe Feedback zu einem Feature oder Pricing bekommen, aber aus unterschiedlichen Gründen. Und solches Feedback kann von einem Power-User kommen oder von einem Nutzer, der gekündigt hat. Auch hier: unterschiedliche Motivationen.

Onboarding: wir haben am Mittwoch 21 neue Wartelisten-Mitglieder eingeladen. Zwei haben sich angemeldet (danke!), und wir warten aufs Wochenende, um zu sehen, ob noch mehr folgen. Wir wissen, was unser Preis ist und dass er eine Investition in die eigene FI-Reise ist.

Unser Plan ist jetzt, jeden Mittwoch 20 neue Wartelisten-Mitglieder zu onboarden, was es uns erlaubt, weiterhin 1-zu-1-Feedback zu sammeln und gleichzeitig eine Calm Company zu bleiben (sprich: nicht nachts und am Wochenende zu arbeiten!)

Wie immer: Wenn du wirklich Interesse hast, FI Planner zu nutzen, schick Patrik oder mir eine E-Mail, und wir rücken dich in der Liste nach oben.

Was mich beschäftigt

Da ich diese Woche mehr Zeit für FI Planner hatte, habe ich diesen Startup-Modus, den ich so liebe, voll gespürt… der aber gar nicht so einfach ist, wenn man mittendrin steckt.

Mein Hirn sah letzten Mittwoch so aus:

  • “OK, ich habe also etwa 20-30 E-Mails zu beantworten für unsere Discovery-Phase”…
  • “Aber ich muss auch 20 neue Wartelisten-Mitglieder onboarden…”
  • “Ah, und da ist diese neue Design-Idee, die ich bei den Simulations-Resultaten umsetzen will… naja, das sind was, 10min…? Hmm, aber sei ehrlich, Marc, du wirst auch mit den Superkräften von Claude Design tweaken/testen/iterieren wollen, also endet das in einer 4h-Session…”
  • “Mann, und ich wollte ein neues Pricing-Schema mit einem bestimmten potenziellen Kunden testen…”
  • “Und so weiter und so fort… argh!”
  • “Und wie spät ist es überhaupt? Ah… schon 18 Uhr, Zeit für die Kinder! ^^”
Startup-Leben laut Marc
Startup-Leben laut Marc

Notiz an einen Freund

Willst du Produktanfragen von Nutzern priorisieren? Dann nutze mein mentales Modell, das ungefähr so aussieht:

  1. Job, nicht Feature (sprich: nach dem Struggling Moment gruppieren, nicht nach der angefragten Lösung)
  2. Wer es sagt (sprich: nach Segment gruppieren)
  3. Verhalten > Aussage (sprich: beim Pricing nach einem echten Commitment fragen, bevor man dieses oder jenes neue Zahlungsschema umsetzt)
  4. Fehlerkosten (sprich: wenn wir es jetzt umsetzen würden, ist es reversibel oder nicht? Falls nicht, mehr Feedback sammeln. Falls ja, und es schlau erscheint, ausprobieren)

Tool der Woche

Ich bin ein grosser Fan von Produktivitäts-Tools und -Frameworks. Denk an GTD oder Things oder Bullet Journal.

Aber heutzutage, mit AI, habe ich das Gefühl, ich könnte das alles + meine E-Mails + meinen Kalender -> in ein einziges System zusammenführen. Und ich habe 1-2 “Kurse” gefunden, die das anbieten.

Ich weiss, es ist vielleicht das “neue schicke System”, das mich reizt, aber nachdem ich mich reingegraben habe, könnte es die Art (und die Zeit!), wie ich priorisiere und meine Todos pflege, revolutionieren.

Nur habe ich gerade nicht die Zeit dafür, und ich fürchte, es muss bis zum Sommer warten, wenn ich mehr Freizeit / Ferien habe, um damit zu spielen. Geduld!

Grösser anzeigen