Wähle langweilige Lösungen

Einer meiner liebsten Blogposts überhaupt ist Choose Boring Technology von Dan McKinley. In diesem Beitrag erklärt Dan, warum es wichtig ist, die Anzahl der Unbekannten zu begrenzen, mit denen sich ein Team zu einem beliebigen Zeitpunkt auseinandersetzen muss.

Er führt das Konzept der Innovationstoken ein – eine einfache Möglichkeit, die Einführung unvertrauter Technologien oder Architekturen zu verfolgen und zu begrenzen. Ein Innovationstoken wird jedes Mal verbraucht, wenn du eine neue Technologie oder ein neues Konzept nutzt, das eine erhebliche Lernkurve erfordert, und zu Beginn deiner Reise stehen dir nur 3 Innovationstoken zur Verfügung.

Das Ziel ist es, einen Stack zu schaffen, bei dem die meisten Teile langweilig sind – das heißt, das Team kann sie leicht verstehen und umsetzen. Die Idee ist nicht, schlechte Technologie zu wählen, sondern vielmehr die Zeit zu minimieren, die man mit dem Verstehen der Funktionsweise verbringt, und die Zeit zu maximieren, die man damit verbringt zu verstehen, was die Nutzer wollen.

Ein neues Startup muss zum Beispiel nicht mit Kubernetes anfangen, vor allem wenn es noch keinen Product-Market-Fit gefunden hat. Und selbst ein etabliertes Unternehmen muss seinen kritischen Abrechnungsdienst nicht in Rust neu schreiben, wenn das Team zum ersten Mal mit dieser Sprache in Berührung kommt.

Es gibt viele großartige Technologien da draußen. Aber die meisten Unternehmen brauchen sie nicht, um ihre Nutzer glücklich zu machen und ihr Geschäft wachsen zu lassen.

Innovation muss stattfinden, ja, aber immer nur 3 Token auf einmal.

Langweilig gilt auch für die Strategie

Dans Beitrag konzentrierte sich hauptsächlich auf Engineering, aber das Prinzip lässt sich sehr gut auf die Strategie übertragen. Du legst deine OKRs fest und überlegst dir dann die beste Roadmap und Taktik, um die neu festgelegten Ziele zu erreichen.

Aber das Problem mit Strategie ist, dass es wirklich schwer vorherzusagen ist, was funktionieren wird. Die meisten Experimente scheitern, und es ist sehr wahrscheinlich, dass 25 % (oder mehr!) deiner Projekte nicht die erwarteten Ergebnisse liefern. Deshalb solltest du Projekte wie Wetten behandeln. Manche Wetten gehen auf, und du setzt dann verstärkt auf sie. Aber andere Wetten verfehlen das Ziel, und es sollte leicht sein, sie fallen zu lassen.

Die Frage lautet also:

Was ist der schnellste Weg, um herauszufinden, was funktioniert und was nicht?"

Ähnlich wie beim Tech-Problem sollte dein Ziel sein, die Zeit für die Umsetzung von Wetten zu minimieren und die Zeit zu maximieren, die du damit verbringst, von deinen Kunden zu lernen.

Und eine Möglichkeit, das zu erleichtern, ist die Wahl langweiliger Lösungen.

Nochmal: Langweilig bedeutet nicht schlecht. Es bedeutet nur, dass wir Ansätze wählen sollten, die wir kennen oder die leicht zu erlernen sind, damit wir schnell an den Punkt kommen, an dem wir unsere Ideen testen. Es bedeutet auch, Dinge zu tun, die nicht skalieren, bevor man die automatisierte Version davon baut. Je komplexer wir unsere Lösungen machen, egal wie innovativ, desto mehr Zeit vergeht, bevor wir echtes Feedback und echte Daten bekommen können.

Ich erinnere mich genau an das Beispiel eines Online-Einzelhändlers, der einen neuen Ansatz für Rücksendungen testete, indem Entwickler für eine Gruppe von Nutzern manuell QR-Codes ausdruckten. Sie lernten schnell, dass ihre vorgeschlagene Lösung nicht funktionieren würde, selbst wenn sie automatisiert wäre. Sie sparten 3 Monate Arbeit, indem sie einen langweiligen Weg wählten, um ihre Wette zu testen, und verlagerten dann schnell ihren Fokus auf andere Möglichkeiten, sobald ihnen klar wurde, dass es keine gute Idee war.

Bei Tability haben wir kürzlich eine Liste von Aufgabenstatus hinzugefügt, um mehr Flexibilität zu bieten als nur "offen"/"geschlossen" (z. B.: geplant, in Bearbeitung, in Prüfung, erledigt...). Wir wissen, dass die beste Lösung darin bestünde, die Liste anpassbar zu machen, aber wir haben uns entschieden, als MVP eine einfachere statische Liste auszuliefern. Die Nutzung von Aufgaben stieg dadurch um 20 %, und wir können jetzt an einer ausgefeilteren Lösung arbeiten.

Einige weitere Beispiele:

• Eine bewährte E-Mail-Marketing-Lösung kaufen, statt einen eigenen Newsletter-Dienst aufzubauen.
• Qwilr oder Canva nutzen, um schnell ein Sales-Deck zu testen, statt mehrere Wochen auf ein individuelles Design zu warten.

Mit Langweiligem validieren, skalieren wenn das Vertrauen wächst

Unser Gehirn liebt Neues. Es gibt etwas ziemlich Aufregendes daran, neue Technologien zu erkunden, und es ist schwer, der Versuchung zu widerstehen, innovative Lösungen auf komplexe Probleme anzuwenden.

Aber wir sollten immer auf die Time-to-Feedback optimieren. Also darauf, wie viel Zeit vergeht, bevor du echtes Feedback vom Markt bekommst. Je mehr wir akzeptieren, dass wir falsch liegen können, desto leichter fällt es, klein anzufangen.

Du kannst dann iterieren, wenn dein Vertrauen wächst.

• Starte mit einem langweiligen MVP: das ist der nicht skalierbare Ansatz, den du innerhalb weniger Wochen liefern können solltest. Er deckt vielleicht nicht alle Anwendungsfälle ab, und der zugrunde liegende Ansatz ist vielleicht nicht besonders elegant. Aber es ist ein einfacher Weg, deine Wette zu validieren und zu bestätigen, dass du auf dem richtigen Weg bist.
• Dann ein Upgrade auf eine langweilige Lösung: die langweilige Lösung wird weiterhin mit einfachen Tools und Methoden gebaut. Aber jetzt schließt du einige der Randfälle und automatisierst die manuellen Aufgaben.
• Schließlich mit Innovation optimieren: sobald du dir ziemlich sicher bist, dass du es geschafft hast, und du auch das Bedürfnis verspürst zu skalieren, dann kannst du dir innovative Ansätze für dein Problem ansehen. Aber das sollte selten sein. Eine langweilige Lösung reicht in den meisten Fällen völlig aus.

Ein letzter Gedanke, bevor wir Schluss machen. Eine langweilige Lösung sollte nicht zu einer sch**ßigen Nutzererfahrung führen (pardon my French).

Die Mindestschwelle für UX ist "Gut". Es gibt einen großen Unterschied zwischen einem einfachen Weg, etwas Gutes zu liefern, und dem Senken deiner Standards, um ein Projekt schneller zu liefern.

Du kannst den Umfang deiner Projekte verkleinern, aber du kannst nicht die Qualität deiner Ergebnisse mindern.

--

Nutzt du OKRs? Wir haben einen "langweiligen" Weg, das Tracking zu vereinfachen, statt dir deine eigene Tabelle zu basteln → Schau dir Tability an.