- Viele Unternehmen werden durch komplexe Prozesse oder ausufernde Anforderungen ausgebremst, aber wirklich wichtig ist, schnell das „richtige Produkt“ zu bauen
- Entfernt man im Produktentwicklungsprozess unnötige Elemente, steigt die Entwicklungsgeschwindigkeit massiv. Das richtige Produkt zu bauen ist an sich ein schneller Prozess
- Was Produktteams verlangsamt, sind unnötige Elemente wie Prozesse, die Distanz zwischen Entscheidern und Ausführenden sowie übermäßige Spezifikationen
[Prinzipien für Product Velocity]
1. Weniger tun
- Im Allgemeinen gibt es einen Trade-off zwischen Geschwindigkeit und Qualität
- Die meisten Unternehmen legen Anforderungen und Fristen fest und behandeln Qualität als Ergebnis; wir gehen umgekehrt vor, setzen Qualitätsstandards und überlegen dann, was sich in 60 Tagen veröffentlichen lässt
- Wichtig ist nicht, alle Anforderungen erfüllen zu wollen, sondern das Wichtige schnell fertigzustellen
- Wenn man Anforderungen entfernt und nur das Nötige macht, lassen sich Geschwindigkeit und Qualität zugleich steigern
- Auch Elon Musk schlägt einen ähnlichen Ansatz vor und sagt: „Make your requirements less dumb first.“
2. Der „Idiot-Modus“ ist oft effektiv
- Das „midwit meme“ zeigt beispielhaft, dass kluge Menschen und Idioten einfachen Lösungen zustimmen, während durchschnittliche Menschen unnötig komplexe Probleme erzeugen
- Wir gehen Probleme oft im „Idiot-Modus“ an und versuchen, statt kompliziert zu denken, einfache Lösungen zu finden
- Wenn wir Fehler gemacht haben, lag es meist daran, dass wir zu viel nachgedacht haben; der einfache Weg funktioniert häufiger
- Wer sich fragt „Was würde ich tun, wenn ich ein Idiot wäre?“, kommt oft zu einer praktikablen Lösung
3. Nicht jedes Problem ist wichtig
- Nur wenige Probleme sind wirklich wichtig. Wichtige Themen wie Sicherheit müssen unbedingt gelöst werden, aber nicht jedes Problem muss behoben werden
- Zum Beispiel ist unsere mobile UI nicht gut, aber weil Kunden mobil kaum zugreifen, verbessern wir sie nicht
- Probleme, die Kunden kaum stören, kann man auf diese Weise ignorieren
4. Einfach bauen
- Wir haben keinen Prozess für die Produktentwicklung. Wir machen keine Figma-Mockups, keine PRDs, kein Design-System, kein Agile, keine OKRs, keine verlässliche Produkt-Roadmap, kein A/B-Testing und kein Growth Hacking
- Weil unsere Kunden Ingenieure sind, erwarten wir, dass unsere Ingenieure Produkt, Design und alles andere mit übernehmen können
- Wir bevorzugen es, Produkte schnell zu bauen und dann die Reaktion der Kunden zu beobachten
5. Umschreiben, wenn es nötig ist
- Unternehmen glauben oft, dass sie sich umso schneller bewegen, je länger sie technische Schulden hinauszögern; wir haben jedoch kein Problem damit, bei Bedarf größere Rewrites zu machen
- Manchmal ist der schnellste Weg, das Richtige zu bauen, zuerst das Falsche zu bauen, zu erkennen, dass es falsch ist, und es dann durch das Richtige zu ersetzen
- Wenn es sinnvoll erscheint, technische Schulden zu beseitigen, dann tun wir das
6. Wenn möglich auslagern
- Wenn möglich, kaufen wir Lösungen von externen Anbietern, statt sie intern zu bauen. Zum Beispiel generieren wir SDKs über einen Anbieter namens Fern
- Natürlich bringt die Nutzung eines Anbieters erhebliche Anfangskosten mit sich und schränkt die Flexibilität ein, ist aber meist die richtige Entscheidung
- Unsere Engineering-Ressourcen sind sehr begrenzt und teuer; eine Ingenieurswoche kostet etwa 5.000 Dollar. Berücksichtigt man die Opportunitätskosten, ist ihr Wert noch deutlich höher
- Es gibt relativ wenig, das es wirklich wert ist, selbst gebaut zu werden
7. Nicht einstellen
- Wir erwarten nicht, dass mehr Personal automatisch den Output des Teams erhöht. Recruiting ist langsam und schwierig, und Onboarding sowie Personalführung kosten Zeit
- Besonders schwer ist es, fähige Leute zu holen, die ohne viel Unterstützung sofort beitragen können
- Deshalb geben wir unser Bestes, klein zu bleiben, obwohl wir die Ressourcen hätten, ein großes Engineering-Team aufzubauen. Das macht das Leben deutlich einfacher
Abschließende Gedanken
- Wir haben erkannt, stärker als zuvor, dass Produktentwicklung eigentlich nicht so lange dauern sollte
- Wenn man weiß, was Kunden brauchen, ein starkes Team hat und unnötige Ablenkungen ausschließt, kann man Produkte mit hoher Geschwindigkeit entwickeln
10 Kommentare
Ich bin auch wieder vorbeigekommen. Bis zum nächsten Mal.
Auch nach mehrmaligem Lesen immer noch sehr gut.
?? Ziemlich idealistisch.
Die Managementkosten für Outsourcing und die dafür erforderlichen Ressourcen dürften nicht unerheblich sein ... trotzdem ist es insgesamt ein hervorragender Rat.
Es heißt immer, man solle Outsourcing nutzen. Aber ich habe kaum gesehen, wie man dabei konkret vorgehen sollte.
Wenn man ohne ein klares Bild des Services nur eine grobe Skizze übergibt, merkt man nicht, dass man am Ende etwas noch viel Schlimmeres bekommt, als man erwartet hat....
???: Bitte macht es schnell, aber nicht agil.
Ich denke, das ist möglich, wenn das Produkt klar ist.
Wenn klar ist, was zu tun ist, wirkt sich zusätzliche Planung darüber hinaus unnötig an.
„Macht zuerst die Anforderungen weniger dumm“
Wenn der Outsourcing-Dienstleister eines Tages verschwindet ... und nicht ans Telefon geht ;_;
Selbst wenn es interne Entwicklung ist, wäre die Situation nicht ähnlich, wenn eines Tages plötzlich alle kündigen würden..?