Ich habe vor Kurzem zusammen mit einem Co-Autor ein Buch geschrieben: Kill the HiPPO. Darin gehen wir der Frage nach, wie kleine, eigenfinanzierte Software-Unternehmen entscheiden, welches Feature sie als Nächstes bauen.
Zu diesem Thema gibt es bereits jede Menge Material – allerdings mit einem starken Bias: Das meiste richtet sich an Teams in großen Organisationen mit üppigen Ressourcen und oft auch VC-Funding. Dabei wird der Großteil aller Software von kleinen, eigenfinanzierten Teams entwickelt. Und diese Teams arbeiten unter völlig anderen Voraussetzungen. Im Grunde haben sie von allem weniger: weniger Daten, weniger Zeit, weniger Ressourcen und weniger Leute. Trotzdem müssen sie kritische Produktentscheidungen treffen.
Die Unternehmen, die mein Co-Autor und ich für das Buch interviewt haben, sind allesamt eigenfinanziert, stabil aufgestellt, gut geführt, etabliert und profitabel – mit jeweils etwa 10 bis 35 Mitarbeitenden. Wir haben die Gründer*innen und erfahrenen Führungskräfte jedes Unternehmens gefragt, wie sie in der Anfangszeit entschieden haben, was entwickelt wird, wie sich die Vorgehensweise im Laufe der Zeit verändert hat und wie sie es heute machen. Die Geschichten, die wir gehört haben, waren erhellend.
Einige Themen tauchten immer wieder auf:
- Der Feature-Overload in der Anfangszeit – und die spätere Reue
- Die Schwierigkeit, konsequent „Nein“ zu sagen
- Die Bedeutung einer starken Vision – und der Disziplin, an ihr festzuhalten
- Der ewige Kampf mit Technical Debt und UX Debt
Aber wir haben auch einige ungewöhnliche Ansätze entdeckt, die Teams entwickelt haben, um dieses Problem anzugehen. Hier sind fünf gekürzte Geschichten aus unserem Buch, die einige dieser Ansätze zeigen.
Löst es ein „Wow“ aus?
James Kennedy von ProcurementExpress.com hat gelernt, „Wow“ als Faktor für die Entscheidung heranzuziehen, was als Nächstes gebaut wird. James hat über 100 Wettbewerber – alle mit mehr oder weniger der gleichen Software und den gleichen Features. Da herauszustechen, ist wirklich schwer. Wenn James entscheidet, was als Nächstes gebaut wird, schaut er sich seine Liste der meistgewünschten Ideen an und wählt eine aus, von der er glaubt, dass sein Produktteam sie so umsetzen kann, dass sie ein „Wow“ auslöst. Das heißt konkret: Wenn James mit einer potenziellen Kundin telefoniert – oder auch mit einem bestehenden Kunden – will er hören: „Wow, das wird meinen Job so viel einfacher machen“ oder „Wow, ich wusste gar nicht, dass Procurement-Software das kann“ oder „Wow, das wird mir eine Menge Zeit sparen.“
James zeichnet diese Gespräche auf und spielt Ausschnitte davon seinem gesamten Produktteam vor – damit das ganze Team erleben kann, wie ihre Arbeit dieses Wow auslöst.
Bauen für „Simon aus Kanada“
Bridget Harris hat uns eine faszinierende Geschichte aus der Anfangszeit ihres Unternehmens YouCanBookMe erzählt – darüber, wie sie ihr Produkt zumindest teilweise für und mit einer Person entwickelt haben, die wir hier „Simon aus Kanada“ nennen. Simon war Massagetherapeut und einer der ersten Kunden – und er ist eine reale Person. Entscheidend war: Er entsprach exakt der Zielkundin von YouCanBookMe – ein echtes Beispiel ihres Ideal Customer Profile.
Simon war freundlich, großzügig mit seiner Zeit und bereit, sich wöchentlich mit Keith (Bridgets Mitgründer) zusammenzuschalten, um über das Feature zu sprechen, welches als Nächstes gebaut werden sollte. Simon half Keith und Bridget dabei herauszufinden, ob das geplante Feature ihm tatsächlich bei seiner Arbeit helfen würde. Außerdem gab er sein Feedback zu kleinen Details kürzlich ausgelieferter Features, sodass Bridget und Keith diese noch feinjustieren konnten.
Ich mag diese Geschichte aus mehreren Gründen. Erstens: Ich habe in meinem eigenen Unternehmen genau dasselbe gemacht – mir war es nur nicht bewusst, bis Bridget mir davon erzählt hat. Zweitens: In diesen frühen Tagen, in denen so viel Unsicherheit herrscht, hat man nie genug Zeit für all die Dinge, die man eigentlich tun müsste – zum Beispiel regelmäßig mit vielen Kund*innen zu sprechen. Wenn du deinen eigenen „Simon aus Kanada“ findest, erhöhst du die Wahrscheinlichkeit dramatisch, dass du ein Produkt baust, das die Leute gerne nutzen.
Alles hat seine Saison
Das Führungsteam von Balsamiq hat uns von ihrem „Seasons“-Ansatz erzählt. Jedes Produkt hat ein Backlog, der so lang ist, dass wir ihn nicht abarbeiten könnten, selbst wenn wir 10 Jahre nichts anderes tun würden. Das Problem dabei: Ganze Kategorien von Backlog-Items gehen komplett verschüttet.
Balsamiqs Ansatz dagegen: Sie legen fest, dass die nächsten sechs (oder vielleicht zwölf Wochen) die Saison für eine bestimmte Art von Arbeit sind. Für die Dauer der Saison machen sie ausschließlich das. Vielleicht ist es die Saison für Bugfixes – also werden nur Bugs gefixt. Oder es ist die Saison, um wenig genutzte, verwirrende Features rauszuwerfen. Vielleicht ist es die Saison für ein Design-Refresh oder auch die Saison für kleine Quality-of-Life-Verbesserungen. Das Schöne an diesem Ansatz: Jedes Backlog-Item bekommt, egal in welche Kategorie es gehört, von Zeit zu Zeit die Chance, berücksichtigt zu werden.
Cupholders vs. CarPlay
Tyler King von Less Annoying CRM hat gelernt, potenzielle Features gedanklich in zwei Kategorien einzuteilen: „Cupholder“-Features und „CarPlay“-Features.
Wenn du in den letzten Jahren versucht hast, ein Auto zu kaufen, standen CarPlay (oder das Android-Pendant) vermutlich weit oben auf deiner Must-have-Liste. Erstaunlicherweise existierte CarPlay vor gar nicht so langer Zeit noch nicht einmal.
Tyler ist überzeugt, dass er über mehrere Jahre hinweg einen entscheidenden Fehler gemacht hat: Er hat ausschließlich auf das gehört, was seine bestehenden Kund*innen sich gewünscht haben. Diese fragen tendenziell nach kleinen, inkrementellen Verbesserungen – dem Äquivalent von mehr Getränkehaltern oder besseren Getränkehaltern.
In der Zwischenzeit hatte sich die Wettbewerbslandschaft verändert. Seine größten Konkurrenten hatten neue Innovationen eingeführt, die zu „CarPlay“-artigen Must-haves für Leute geworden waren, die sich nach Alternativen umsahen. Tyler hatte nicht bemerkt, dass das passiert war. Er war abgehängt worden, und es gab einiges aufzuholen. Tyler hat daraus gelernt, dass er die Arbeit an „Cupholder“-Features (um bestehende Kund*innen zufrieden zu halten) mit der Arbeit an diesen großen, neuen „CarPlay“-artigen Must-have-Features ausbalancieren muss, die potenzielle Neukund*innen auf ihrer Checkliste haben. Keine der beiden Feature-Kategorien darf vernachlässigt werden.
Die Kraft der Einschränkungen
Anthony Eden von DNSimple ist ein reflektierter Mensch. Er denkt intensiv darüber nach, wie er sein Unternehmen führt – auch über das Problem, was als Nächstes gebaut werden soll. Anthony hatte sein eigenes Framework entwickelt: ein umfassendes, gut dokumentiertes System mit mehreren Backlogs, Input von wichtigen Stakeholdern und einer richtig komplizierten, gewichteten Formel. Die sollte Anthony und seinem Team sagen, was sie als Nächstes bauen sollten.
Es gab nur ein Problem: das Framework funktionierte nicht wirklich. Anthonys Team schaffte es nicht, Features mit irgendeiner nennenswerten Geschwindigkeit zu liefern.
Anthony war klug genug zu erkennen, dass er mit diesem Problem nicht allein war. Vor ein paar Jahren suchte er nach Hilfe und stieß auf das „Shape Up„-Framework von Basecamp. Er probierte es ein paar Monate lang aus, aber es gab ein paar Dinge daran, die nicht zur Kultur seines Teams passten. Statt es komplett zu verwerfen, nahm er Anpassungen vor und modifizierte das Framework so, dass es für sein Team funktionierte. Die Ergebnisse waren phänomenal.
Das „Shape Up„-Framework hat eine strikte Regel: Features müssen in Sechs-Wochen-Zyklen geliefert werden. Genau diese strikte Regel hatte den größten Einfluss auf Anthonys Team. Wenn ein Feature voraussichtlich länger als sechs Wochen braucht, muss es in kleinere Features aufgeteilt werden. Wenn das Team sich für ein Feature entscheidet, bekommt es sechs Wochen – und nicht mehr – um etwas zu liefern. Diese harte Einschränkung zwingt Anthony, bei Entscheidungen über den Scope eines Features konsequent zu sein. Die Sechs-Wochen-Einschränkung war der Durchbruch, den Anthonys Team brauchte, um in einem guten Tempo zu liefern.
In Anthonys eigenen Worten:
„Zeitliche Einschränkungen für alles zu setzen – das war der entscheidende Hebel, um unseren Entwicklungsprozess effektiver zu machen.“
Fazit
Ich hoffe, diese kleinen Einblicke in das, was wir aus unseren Interviews mit eigenfinanzierten Gründer*innen gelernt haben, hat dir gefallen – und vielleicht den einen oder anderen Denkanstoß geliefert.
Was mich bei all diesen Geschichten am meisten beeindruckt hat: Keine der Lösungen erfordert große Budgets, ausgefeilte Tools oder riesige Teams. Ein „Wow“ als Entscheidungskriterium, ein einzelner engagierter Kunde als Sparringspartner, saisonale Fokussierung, die bewusste Balance zwischen kleinen und großen Features oder strikte Zeitvorgaben – all das sind Ansätze, die jedes Team ab morgen ausprobieren kann.
Gleichzeitig zeigen die Geschichten auch: Es gibt keine universelle Formel. Jedes dieser Unternehmen hat seinen eigenen Weg gefunden – oft erst nach Umwegen und Fehlern. Das Gemeinsame ist eher die Haltung: ehrlich reflektieren, was funktioniert und was nicht, und den Mut haben, den eigenen Prozess anzupassen.
In unserem Buch Kill the HiPPO findest du mehr dieser Geschichten – und in deutlich mehr Tiefe. Mein eigenes Produkt, Feature Upvote, hat davon profitiert, die Erkenntnisse aus dem Schreiben des Buches anzuwenden. Und wenn du das Buch liest, profitiert hoffentlich auch dein Produkt davon.
Was sind deine Erfahrungen? Wie entscheidest du in deinem Team, was als Nächstes gebaut wird? Ich bin gespannt auf deine Perspektive – schreib es in die Kommentare!
