50 Lektionen aus dem Bau erfolgreicher Produkte [Übersetzung]

1. Kleine Teams (mit höchstens 6 Personen) können großartige Produkte bauen, aber nur, wenn sie volle Autonomie erhalten – bei der Zielsetzung, der Priorisierung der Roadmap, der Auswahl von Metriken, der Kommunikation mit Nutzern und dem schnellen Ausrollen von Code.

2. Der Erfolg eines Produkts hängt von den Menschen ab, die es bauen. Entscheidend ist ein hoher Einstellungsmaßstab, denn die Fähigkeiten von Talenten summieren sich. Eine Fehlbesetzung verlangsamt ein Team stärker als jeder andere Faktor.

3. Vertrauen ist unverzichtbar, um großartige Produkte zu bauen. Mangelndes Vertrauen ist einer der größten Engpässe in Teams – meist das Ergebnis davon, dass man mittelmäßige Leute eingestellt oder ihnen kein richtiges Feedback zur Verbesserung gegeben hat.

4. Vertrauen entsteht auch durch Transparenz. Arbeite offen, führe Diskussionen in öffentlichen Räumen und dokumentiere die Arbeit. So teilen alle den nötigen Kontext, und politische Reibereien, wie sie in vielen Firmen entstehen, lassen sich vermeiden.

5. Verlasse dich nicht auf Prozesse, sondern auf Vertrauen und Feedback. Das ist einer unserer Kernwerte. Produkte zu bauen und wachsen zu lassen, die Menschen wirklich wollen, ist ein feines, nuanciertes Problem – deshalb vertrauen wir auf das Urteilsvermögen der Mitarbeitenden. Wenn etwas schiefläuft, geben wir direktes Feedback.

6. Die Geschäftsführung teilt die Unternehmensziele, und die Produktteams (Ingenieure) entscheiden, was gebaut werden muss, um sie zu erreichen, sowie ihre eigenen Ziele. Beide Seiten sollten die tatsächliche Wirkung anhand von Metriken und Nutzerfeedback prüfen.

7. Ein Produkt ist dem ideal customer profile (ICP) untergeordnet. Für dieses ICP wird gebaut, und es ist der wichtigste Faktor bei der Entscheidung, was gebaut wird. Ein präzises ICP definiert nicht nur die Zielkunden, sondern jeden Aspekt des Produkts und der Go-to-Market-Strategie.

8. Um dein ICP zu finden, stelle zuerst Vermutungen auf und teste sie. Stelle Fragen bei der Anmeldung, vergleiche Retention, identifiziere Power-User und führe NPS-Umfragen durch. Wenn Informationen und Sicherheit zunehmen, arbeite die Details weiter aus.

9. Formuliere Produktprinzipien. Unsere lauten: „alle Werkzeuge bereitstellen, die zur Bewertung von Erfolg nötig sind, First-Mover sein und als Single Source of Truth für Kunden- und Produktdaten dienen“. Das schafft eine gemeinsame Sprache für Ideendiskussionen und Entscheidungen.

10. Bilde alles ab, was Nutzer sich wünschen könnten. Das ist nötig, wenn du die Roadmap priorisierst. So verpasst du keine großartigen Ideen jenseits des Horizonts.

11. Ein Produkt ist mehr als nur eine Funktion. Es ist die Marke und die Produkterfahrung, die es anderen vermittelt. Wie stark du in einzelne Funktionen investierst, wen du einstellst, welche Build-Entscheidungen du triffst, welche Leitfunktionen du setzt, wie du mit Kunden kommunizierst und wie du Preise gestaltest – all das erzeugt Einzigartigkeit.

12. Die Website ist der erste Eindruck des Produkts. Eine langweilige, nach Vorlage wirkende Seite sendet das Signal, dass auch das dahinterstehende Produkt und Team schwach sind. Eine eigene, unverwechselbare Seite, zugeschnitten auf das ideal customer profile, verhindert das und fördert die Nutzergewinnung.

13. Manchmal ist es kein Produktproblem, sondern ein Marktproblem. Als etwa Tom Blomfield, Monzo-Gründer und YC-Partner, einen Dienst zur Rechnungsaufteilung für College-Freunde baute, bekam er den Rat, mit dem Bauen aufzuhören und sich auf Nutzergewinnung zu konzentrieren. Als er nach vier Wochen Cold Calling genau einen Nutzer gewonnen hatte, wusste er, dass es Zeit für einen Pivot war.

14. Wenn du pivotierst, dann radikal. Stewart Butterfield verwandelte zwei Spielefirmen in Flickr und Slack. LinkedIn-Mitgründer Reid Hoffman sagt, dass Startup-Gründer beim Pivot von Misserfolg zu Erfolg den Rest des Geschäfts „slash and burn“ behandeln müssen. Wenn es noch ähnlich aussieht, geh noch weiter.

15. Wie Jason Fried von 37signals sagt: „Man kann eine Idee nicht validieren. Sie existiert nicht, also muss man sie tatsächlich bauen. Der Markt wird sie validieren.“

16. Pläne sind nützlich, aber nicht zum starren Befolgen da. Gute Ausführung heißt nicht, einen bestimmten Plan umzusetzen, sondern immer wieder an den wichtigsten Dingen zu arbeiten. Beurteile Menschen nicht danach, ob sie „dem Plan gefolgt“ sind, sondern nach dem, was sie ausgeliefert haben, wie oft sie ausgeliefert haben und welche Wirkung das hatte.

17. Etwas „noch eine Woche“ zu verschieben, ist fast immer eine schlechte Idee. Wenn sich diese Haltung über Monate ansammelt, sinkt der Schwung massiv. Je schneller etwas in die Hände der Nutzer kommt, desto schneller lernst du seinen Wert kennen und kannst es verbessern.

18. Reduziere Work in Progress. PRs sollten innerhalb eines Tages abgeschlossen sein, beginne den Tag mit Antworten auf Review-Anfragen anderer, merge jederzeit, rolle hinter Feature Flags aus und teste in Production. All das reduziert die Last des Arbeitskontexts.

19. Schnelles Deployment ist zentral für unsere Philosophie der Produktentwicklung, bringt aber Trade-offs mit sich. Technische Beschaffung, Planungsmeetings, agile Rituale und Metrik-Reviews treten in den Hintergrund. Asynchrones Arbeiten macht das noch leichter möglich.

20. Führe neue Technologien im Produkt nur dann ein, wenn dringende Probleme wie überhöhte Kosten, Skalierungsprobleme oder Kundenanforderungen es nötig machen. Die passende Lösungstechnologie findest du, indem du fragst, wie dein Team oder andere Teams ähnliche Probleme selbst gelöst haben.

21. Künstliche Deadlines machen Teams nicht schneller. Stattdessen erzeugen sie einen Teufelskreis aus Bergen technischer Schulden und Burnout. Entferne Prozesse, die Teams verlangsamen, und gib kleinen Teams die Autonomie, schnell auszurollen.

22. Ein weiterer Weg zu schnellerem Deployment ist, auf grundlegendes Design zu verzichten. Sobald ein Design-System steht, lass Ingenieure bauen. Wenn nötig, verfeinere bereits ausgelieferte Dinge per Design-Review.

23. Feature Flags ermöglichen es Produktingenieuren, Änderungen schnell auszurollen, in Production zu testen und echtes Nutzerfeedback einzuholen. Wenn etwas nicht wie erwartet funktioniert, dienen sie außerdem als Kill Switch und senken das Risiko.

24. Bei PostHog ist Pull Request die beste Form der Kommunikation. Anders als Nachrichten oder Issues verwandelt er Feedback sofort in Wirkung. Das passt zu einer handlungsorientierten Kultur und schafft engere Feedback-Loops.

25. Sorge für klare Ownership. Das macht Entscheidungen darüber, was gebaut werden soll, deutlich klarer und schneller. Teams, die Ownership vermeiden, verschwenden Zeit mit Planung, Brainstorming, Meetings und Projektmanagement statt mit dem Ausrollen.

26. Ingenieure sind in der Lage, zu entscheiden, was gebaut werden soll. Sie verstehen technische Einschränkungen, erkennen Muster in Funktionen und wissen, wie Probleme gelöst werden. Ein möglicher Engpass ist allerdings der Zugang zu Informationen über Nutzerbedürfnisse.

27. Statt Ingenieure zu kontrollieren, sollten Produktmanager dem Produktteam Kontext liefern – etwa durch Produktanalysen, Nutzerforschung und Wettbewerbsrecherche.

28. Die meisten Menschen sind nicht Steve Jobs. Sie haben nicht von Anfang an die Vision, einfach „instinktiv“ das Richtige zu bauen, und zeichnen auch nicht das große Gesamtbild. Stattdessen liefern sie aus, geben Dinge an Nutzer, sammeln Feedback und wiederholen den Zyklus. Je schneller dieses Tempo ist, desto besser wird das Produkt.

29. Stelle Produktingenieure ein und verlasse dich auf sie. Sie vereinen die Full-Stack-Fähigkeiten und die Kundenobsession, die man zum Bauen von Produkten braucht. Sie sollten mit Nutzern sprechen, Interviews führen, Tester für neue Funktionen rekrutieren, Feedback sammeln, Support übernehmen und auf Incidents reagieren.

30. Lies The Mom Test. Es zeigt dir, wie man über Probleme potenzieller Nutzer spricht. Entscheidend sind zwei Arten von Nutzerinterviews: Problem Exploration und Solution Validation. Ersteres hilft bei künftigen Produktentscheidungen, Letzteres bei der Verbesserung laufender Arbeit.

31. Um aus Nutzerinterviews den größten Nutzen zu ziehen, solltest du vorher verstehen, wer deine Nutzer (ICP) sind, wie sie das Produkt verwenden und was als Nächstes gebaut werden soll. So helfen Interviews, den Fokus auf die nächsten Schritte zu schärfen, statt Verwirrung zu stiften.

32. Unter den möglichen Dingen, die gebaut werden könnten, sind Support-Anfragen am „realsten“. Ein konkreter Nutzer hat ein konkretes Problem – wenn du es löst, verbessert sich das Produkt sofort. Andere Änderungen sind selten so unmittelbar.

33. Wenn Ingenieure Support übernehmen, fördert das Ownership über den gesamten Produktlebenszyklus hinweg – von der Ideenfindung über die Umsetzung bis zur dauerhaften Pflege. Jede Phase baut auf realen Customer Pain Points und auf dem Code-Kontext hinter den Issues auf und verbindet sich so mit den anderen.

34. Wenn Ingenieure Supportfälle bearbeiten, verkürzt sich der Loop zwischen Nutzerproblem und ausgeliefertem Fix. Support-Personal, Produktmanager und Planungsprozesse stehen nicht dazwischen. Bonus: Nutzer lieben das.

35. Dogfooding hilft dabei, schneller auszurollen, Probleme abzufangen, bevor sie Nutzer erreichen, das Produkt tief zu verstehen und Empathie für Nutzer aufzubauen. Es ersetzt jedoch nicht Gespräche mit Nutzern, echtes Feedback oder das Tracking von Usage-Metriken.

36. So wie unser Produktteam mit einem Interview-Popup seine eigenen Bedürfnisse gelöst hat, ist das Lösen eigener Bedürfnisse ein wirksamer Weg, Use Cases zu validieren. Wenn du dein eigenes Produkt eigentlich verwenden solltest, es aber nicht tust, ist das ein Signal, dass etwas nicht stimmt – also behebe es.

37. Großartige Produktbauer prototypen und experimentieren ständig. Sie müssen darin geübt sein, MVPs und Proofs of Concept zu bauen, unfertige Arbeit auszurollen, Feedback zu sammeln und bei Misserfolg zu pivotieren. Außerdem brauchen sie alle Fähigkeiten, um von null an zu bauen – von Infrastruktur bis Design.

38. Erfolgreiche A/B-Tests brauchen eine gute Hypothese, die erklärt, was getestet wird und warum. Sie sollte den Testkontext, die Änderungen, die Metriken und die erwarteten Ergebnisse enthalten.

39. Bei Produktexperimenten solltest du davon ausgehen, dass sie scheitern und wieder entfernt werden können. Richte sie mit Feature Flags so ein, dass sie leicht entfernt werden können, und liefere eine „gut genug“-Version aus statt einer perfekt wartbaren und skalierbaren Version. Wenn es erfolgreich ist, kannst du später verbessern.

40. Produktexperimente dürfen viel „dümmer“ sein, als man denkt. Statt eine ganze Funktion zu bauen, probiere einen Fake-Door-Test aus – also eine Option oder einen Button hinzuzufügen, hinter dem noch nichts steckt, um zu sehen, ob Nutzer klicken.

41. Das Scheitern von Produktexperimenten ist nicht das Ende der Welt. Bei Google „scheitern“ 80–90 % der Experimente. Das kann wie Zeitverschwendung wirken, aber im großen Maßstab gleichen die 10 % Erfolge alle Fehlschläge aus – etwa wie beim A/B-Test von Bing zur Anzeige von Headlines, der den Umsatz um 12 % (mehr als 100 Millionen Dollar) steigerte.

42. Wenn du dich auf Wachstum konzentrierst, denke und priorisiere wie ein Growth Engineer. Identifiziere den Zielbereich, wähle eine repräsentative Metrik, stelle Verbesserungshypothesen auf und implementiere Tests als kleinstmögliche Experimente.

43. Für Analytics ist es fast nie zu früh. Für Produkte vor dem Launch ist das angemessen, aber mit „es ist noch zu früh“ ohne Analytics zu launchen, ist falsche Sparsamkeit. Nach dem Launch verschiebt sich die Priorität von maximaler Deployment-Geschwindigkeit zu maximaler Geschwindigkeit beim Deployment der richtigen Dinge.

44. Starte klein, wenn du mit Analytics beginnst. Wähle ein bestimmtes Produkt oder eine Funktion, erfasse die Nutzung per autocapture, visualisiere sie mit Trend- und Retention-Grafen und versuche dann, Funktionen auszurollen, die diese Werte verbessern. Der „modern data stack industrial complex“ lässt das komplizierter erscheinen, als es ist.

45. Wenn du keine Startmetrik kennst, empfehlen wir Activation. Sie steht über vielen anderen Metriken, Ingenieure können sie direkt beeinflussen und sie ist für die gesamte Organisation nützlich.

46. Neben Activation ist Retention eine weitere zentrale Metrik, um die Wirkung dessen zu verstehen, was du baust. Wenn du wöchentliche Veränderungen verfolgst, kannst du einschätzen, ob Änderungen dazu beitragen, Nutzer zu halten.

47. Wenn du Product-Market-Fit messen willst, prüfe, ob die Nutzerbeteiligung exponentiell schneller wächst als das Nutzerwachstum und ob sich die Retention abflacht (über 0 %). Sieh dir danach an, ob die Retention bei ICP-Nutzern stark ist und ob zahlende Kunden zu diesem ICP gehören.

48. Growth Reviews prüfen, ob das, was das Team baut, Einfluss auf wichtige Metriken wie Umsatz, Produktanalysen und Nutzerfeedback hat. Bei PostHog ist das eine Hauptverantwortung der Produktmanager.

49. Wenn du mehrere Produkte baust, behandle jedes davon wie ein Mini-Startup – mit eigenen Produktentscheidungen, Preisen, Umsätzen, Kosten und Abstimmung mit kundennahen Teams.

50. Halte an interessanten Produkten fest. Wie PostHog-Mitgründer James in seinem Leitfaden zu Product-Market-Fit schrieb: „Wenn es dich nicht interessiert, pivotiere. Das ist alles. Man erzielt mehr, wenn man an etwas arbeitet, das sich nach dem Eigenen anfühlt.“