3 Einschränkungen, die man vor dem Bauen berücksichtigen sollte
(jordanlord.co.uk)- Bei Produktideen sollte man zuerst Einschränkungen festlegen, damit der Suchraum kleiner wird und das Ergebnis nicht zu komplex oder ohne klare Identität gerät
- Jede Idee sollte auf einer einzigen one pager zusammengefasst werden; passt sie nicht hinein, ist mehr Recherche, Planung und Prototyping nötig
- Zusätzlich zum Produkt selbst sollte man eine core tech aufbauen, die auch unabhängig vom Produkt überleben kann und selbst bei einem Richtungswechsel als kumulativer Vermögenswert erhalten bleibt
- Im Zentrum des Produkts sollte eine defining constraint stehen, die für Nutzer fortlaufend sichtbar ist; diese Einschränkung bestimmt auf natürliche Weise das Feel und die Identität des Produkts
- Wenn auch nur eines der drei Kriterien nicht erfüllt ist, sollte man es nicht bauen; diese Haltung ist wichtig für Scope-Kontrolle und langfristige Hebelwirkung
Drei Einschränkungen, die man vor dem Bauen setzt
- Wenn man vor dem Bau eines Produkts zuerst Einschränkungen festlegt, wird der Suchraum kleiner und man verhindert, dass das Ergebnis zu komplex oder identitätslos wird
- Über zehn Jahre und viele Produkte hinweg führten zu komplexe oder identitätslose Produkte zum Scheitern; aus diesen Erfahrungen wurden drei Kriterien verdichtet
-
Wenn es über eine Seite hinausgeht, wird es nicht gebaut
- Jede Idee muss in einer one pager zusammengefasst werden; dieses Dokument dient als North Star
- Die one pager muss nicht verhandelbar, präzise, ambitioniert und zugleich frei von Ballast sein
- Dasselbe Dokument kann für die Kommunikation mit Investoren, Mitwirkenden, Teammitgliedern, Freunden und Familie genutzt werden
- Wenn es in der Zusammenarbeit zu Konflikten kommt, ist alles, was nicht in der one pager steht, keinen Streit wert; ist es wirklich wichtig, muss das Dokument entsprechend geändert werden
- Wenn man eine Seite nicht füllen kann, sollte man den Inhalt nicht künstlich aufblasen, sondern davon ausgehen, dass man noch nicht bereit ist zu bauen
- In diesem Fall sollte man zuerst Recherche, Planung und Prototyping durchlaufen und die one pager danach neu schreiben
- Wenn es so viel ist, dass es über eine Seite hinausgeht, ist es zu komplex und wird nicht gebaut
-
Die Kerntechnologie muss vom Produkt getrennt sein
- Unabhängig vom Produkt selbst sollte man eine core tech aufbauen, die das Produkt trägt
- Die core tech kann eine Methodik, Technologie, ein Tool oder ein separates Produkt sein und sollte auch ohne das aktuelle Produkt überleben können
- Diese Trennung verhindert, dass man in einem einzigen Produkt gefangen bleibt, und sorgt dafür, dass sich Aufbauarbeit auch bei Richtungswechseln weiter ansammelt
- Produkte ändern oft die Richtung, aber core tech bleibt als dauerhafter und kumulativer Vermögenswert erhalten
- Langfristig kann diese kumulative Arbeit nichtlineare Gewinne erzeugen
- Als Beispiele werden Linus Torvalds’ git, HashiCorps HCL und Googles Kubernetes genannt
- Dafür braucht es nicht zwingend die Ressourcen eines Großkonzerns; auch eine aus einer Codebasis herausgelöste Library oder eine fortlaufend verfeinerte Methodik ist möglich
- Die core tech sollte unabhängig von der Produktrichtung sein, aber zur langfristigen Vision einer Person oder eines Unternehmens passen
- Wenn eine Idee keine core tech ermöglicht, bietet sie nicht genug Hebelwirkung
-
Eine einzige entscheidende Einschränkung muss das Produkt definieren
- Im Zentrum des Produkts sollte eine defining constraint stehen, die für Nutzer jederzeit sichtbar ist
- Diese Einschränkung sollte ein Element sein, dem Nutzer ständig begegnen und mit dem sie interagieren; sie formt die Identität des Produkts
- Eine gute Einschränkung erzeugt das Feel des Produkts und durchdringt die gesamte Nutzererfahrung
- Bei Minecraft besteht alles aus Blöcken, bei IKEA zeigt sich die Identität unmittelbar in flach verpackten Möbeln zur Selbstmontage
- Solche Einschränkungen verkleinern den Entscheidungsraum, begrenzen den Scope und helfen, sich auf die wirklich wichtigen Probleme zu konzentrieren
- Wenn man keine Einschränkung wählt oder die falsche wählt, entwickelt sich das Produkt zu einem aufgeblähten Alleskönner
- Wenn die Einschränkung gut gestaltet ist, folgt das Produktdesign ganz natürlich aus ihr
- Auch diese Einschränkung sollte ganz vorne auf der one pager stehen
Abschließendes Kriterium
- Wenn auch nur eine der drei Einschränkungen nicht erfüllt ist, wird nicht gebaut
2 Kommentare
Hacker-News-Kommentare
Ich habe so etwas bisher product primitives genannt
also Dinge wie Notions blocks, Telegrams messages/conversations, Figmas frames/layers, Twitters tweets, Excels cells/sheets, Photoshops tools/layers oder die commands einer CLI
Ich denke, gutes Produktdesign entsteht dann, wenn es nur sehr wenige solcher primitives gibt
Schlechte Produkte wissen entweder nicht, was ihre primitives sind, oder sie haben zu viele davon, sodass sich jedes Element im Produkt anfühlt, als würde es für sich allein stehen
Dann müssen Nutzer eine Menge unterschiedlicher Oberkonzepte lernen, was verwirrend und einschüchternd ist und sich auch schwer vermitteln lässt
Im Idealfall reichen ein, zwei oder drei zentrale primitives
Die Komplexität und Stärke einer App entsteht durch die Wahl von kombinierbaren, tiefen primitives
Mit kleinen Einheiten wie einem Notion block, einer Excel cell, einem CLI command oder einem Minecraft block sollte man viel machen können
Das wirkt ähnlich wie die Alexandrian Pattern Language, ist aber tatsächlich eher an dem dran, was Alexander später Centers nannte, als an patterns
So wie ich es verstehe, hat die Softwarebranche seine patterns stark aufgegriffen, aber Alexander sah in seinen späten Jahren die ultimative Grundeinheit eines Systems im Center
Dinge wie ein heller Innenhof, ein Sitzplatz am Fenster oder ein Kamin: lokale Brennpunkte von Nutzen und Kohärenz
Ein starkes center ist natürlicherweise kombinierbar, löst lokale Spannungen auf, besteht aus kleineren centers und dient als Baustein für größere centers
Wenn Produkte chaotisch und aufgebläht werden, liegt das meist nicht an schlechten Absichten
Nutzeranforderungen lassen sich empirisch oft ganz gut finden, aber die echte zentrale Struktur, die diese Anforderungen elegant aufnehmen könnte, ist sehr subtil und schwer zu entdecken
Deshalb ist es immer der einfachste Weg, für jede unmittelbare Anforderung eine eigene, starre Oberfläche anzubauen
Um die Kern-primitives zu finden, die solche Anforderungen natürlich aufnehmen, braucht es tiefe Architekturarbeit
Vielleicht baut man deshalb am Ende immer wieder faster horses
Früher habe ich das concept count genannt
Es ist meist besser, die Zahl der Kernkonzepte eines Produkts zu minimieren, und man hat das auch als die nouns and verbs des Produkts bezeichnet
Diese Philosophie scheint mir etwas übermäßig vereinfacht
Tana hat faktisch nur zwei primitives, bullets und supertags, und trotzdem ist es so komplex zu benutzen, dass man sich für selbst sehr einfache Aufgaben stundenlange Tutorials ansehen muss
Umgekehrt hat Google Maps ziemlich viele primitives, aber für 90 % der Anwendungsfälle ist die UX dennoch ziemlich solide
Ich habe ein ähnliches Kriterium auch bei Programmiersprachen verwendet
Selbst wenn eine Sprache groß ist, kann man sie nach dem Lernen gut nutzen, wenn sie konzeptionell klein ist, und der Rest kommt dann mit der Erfahrung dazu; bei konzeptionell großen Sprachen war die Einstiegshürde hoch
Das habe ich besonders stark bei perl empfunden
Es muss klein sein, aber nicht zu klein
Das klassische Beispiel ist shell scripting (POSIX shell, bash): Dort wollte man selbst Scripting noch über commands modellieren, um keine neuen Konzepte einzuführen, und das Ergebnis war bekanntlich ein heißes, langsames und chaotisches Gemisch
Alle drei Beschränkungen gefallen mir, aber ich denke, ein Ein-Seiten-Dokument sollte von der Projektkomplexität abhängen
Für kleine bis mittelgroße Projekte reicht eine Seite vermutlich aus, aber bei Flugsteuerungssoftware für eine Marsmission könnte man vor Beginn der Implementierung einen One-Pager brauchen, der auf zahlreiche Unterspezifikationen verlinkt
Die Trennung von Technologie und Produkt ist wirklich klug
Das Beispiel Skype zeigt es gut: Es gab die P2P-Kommunikationstechnologie im Backend und die Calling-App im Frontend, und die klugen Gründer haben beides in getrennte Firmen gepackt
So konnte nach dem Verkauf der Frontend-App Skype an Microsoft die Firma mit dem Kern-IP und der P2P-Backend-Technologie weiterhin separat gehalten werden
Eine Beschränkung ins Zentrum zu stellen ist ebenfalls nachvollziehbar, aber manchmal scheint mir ein Satz aus mehreren Beschränkungen oder eine priorisierte Liste besser zu sein
Wenn sich das oberste Prinzip schwer monetarisieren lässt, kann es das Unternehmen in Richtung Insolvenz treiben, wenn man es wie ein unverrückbares Dogma behandelt
Falls jemand im Team eine Idee hat, in eine deutlich leichter verkäufliche Richtung zu pivotieren, kann das selbst dann einen Ausweg eröffnen, wenn sie sich ziemlich stark vom Ursprünglichen entfernt
Auch Twitter wollte ursprünglich etwas anderes machen, und public status updates entstanden als Nebenprojekt
Dieser Artikel fasst wirklich gut zusammen, wie ich früher zusammen mit meinem Forschungsmentor Unternehmen aufgebaut habe
Wir haben zuerst die beiden hinteren Punkte festgelegt, also Kerntechnologie und Beschränkung
Die Kerntechnologie war ein sampler, der ein beliebiges hierarchisches Bayesian graph model für sparse data ermöglichte, und die Beschränkung war, dass es CPU-bound berechenbar sein musste
Am längsten hat es gedauert zu erkennen, dass das Endprodukt von der zugrunde liegenden Technologie getrennt sein musste
Ich hatte schon vor dem Start ähnliche Ratschläge von mehreren Leuten gehört, aber manche Lektionen bleiben erst hängen, wenn man sie selbst erlebt
Die Idee des One-Pagers ist wirklich gut
Wenn man sich nicht einmal die Zeit nehmen kann, die Beschränkungen klar auf einer Seite aufzuschreiben, wird man sie während der Umsetzung am Ende hektisch und verspätet entdecken
Und dann ist das kein Bug, sondern ein Defekt auf dem Niveau von wir haben das Falsche gebaut
Ich kann es nicht mit Daten belegen, aber meiner Erfahrung nach waren Projekte viel häufiger erfolgreich, wenn alle konzeptionell auf derselben Seite waren
Schon ein einseitiges High-Level-Dokument, das klar festhält, was wir tun und was wir nicht tun, hat große Wirkung
Umgekehrt enden improvisiert durchgedrückte Projekte damit, dass am Schluss sogar die Leute enttäuscht sind, die ihre Gedanken nie klar ausgesprochen hatten
Ich wünschte, der Autor hätte ein vollständiges Beispiel gezeigt, in dem die Beschränkungen tatsächlich funktionieren
Besonders beim dritten Punkt habe ich kein gutes Gefühl dafür, wie das in der Praxis aussieht
Am Ende muss man sich offenbar selbst etwas einfallen lassen
So eine Idee wie everything's a file unter Linux halte ich für gut
Mit einem einzigen starken Konzept kann man schon ziemlich weit kommen
Beschränkungen werden unterschätzt
Die elegantesten Lösungen entstehen meist nicht aus unendlicher Freiheit, sondern dann, wenn man mit klaren Beschränkungen baut
Und das hängt auch mit Punkt 1 zusammen
Schon der Prozess des Schreibens eines One-Pagers hilft dabei, diese Beschränkungen zu definieren
Dass Google Kubernetes hat, scheint vor allem dem Zweck zu dienen, Wettbewerber zu neutralisieren
Für ein solo SaaS würde ich noch die Beschränkung hinzufügen: Kann ich diese Woche einen Beta-Nutzer finden?
Selbst wenn Zeit, Umfang und Technologie auf dem One-Pager gut aussehen, stirbt das Projekt sofort, wenn niemand kommt
Deshalb habe ich von Anfang an eine Distributionsbeschränkung eingebaut, sodass ich die Zielgruppe validieren musste, bevor ich mich zu tief in Features eingegraben habe
Die Aussage Kerntechnologie sollte vom Produkt trennbar sein klingt für mich so, als könnte sie zu zu früher Abstraktion und übermäßigem Einsatz von Design Patterns verleiten
Natürlich ist die Trennung von Verantwortlichkeiten richtig, und man sollte die Business-Domain-Schicht sauber von Dingen wie Persistence, Network oder UI trennen
Trotzdem ist die Domain-Schicht am Ende zwangsläufig sehr stark an das Produkt gebunden
Ich glaube nicht, dass man das vermeiden kann
Vermutlich ist gemeint, dass es eine Außenhülle gibt, die Käufer anzieht, und dass das, was intern wirklich alles antreibt, nicht im Fokus der Käufer steht
Zwischen beiden Schichten kann es einige Konzepte als Schnittstelle geben, aber die Entwicklung des Innenlebens sollte von der äußeren Produktschicht getrennt sein
Ich plane gerade den Umbau meiner Küche und denke, dass diese drei Beschränkungen auch für allgemeinere Designarbeit als nur Software ziemlich nützlich sein könnten
Ich werde das direkt einmal ausprobieren
Vielleicht ist das zu simpel, aber wenn man es über Raum und Fluss betrachtet, wird es interessanter
Man kann an den Fluss von Menschen, Licht und Essen sowie an Übergänge denken, und das ist ziemlich spannend
Das passt wohl zu meinen Werten und meinem Geschmack, deshalb wirkt der Inhalt auf mich gut.
(Im Grunde nur als Merker)