Drei Einschränkungen, die man vor dem Bauen bedenken sollte

 (jordanlord.co.uk)
45 Punkte von GN⁺ 2 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Bei Produktideen sollte man zuerst Einschränkungen festlegen: Das verkleinert den Suchraum und verhindert, dass das Ergebnis zu komplex wird oder ohne klare Identität bleibt.
  • Jede Idee sollte auf einer einzigen One-Pager-Seite zusammengefasst werden; passt sie nicht darauf, braucht es noch mehr Recherche, Planung und Prototyping.
  • Zusätzlich zum Produkt sollte man eine Core Tech aufbauen, die auch unabhängig vom Produkt bestehen kann und selbst bei Kurswechseln als kumulativer Vermögenswert erhalten bleibt.
  • Im Zentrum des Produkts sollte eine für Nutzer ständig sichtbare defining constraint stehen, die das feel und die Identität des Produkts auf natürliche Weise festlegt.
  • 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 langfristigen Leverage.

Drei Einschränkungen, die man vor dem Bauen festlegt

  • Wenn man vor dem Bau eines Produkts zuerst Einschränkungen setzt, verkleinert sich der Suchraum, und man verhindert, dass das Ergebnis in etwas Komplexes oder Identitätsloses abgleitet.
  • In zehn Jahren mit vielen Produkten haben sich übermäßig komplexe oder identitätslose Produkte immer wieder als Misserfolg erwiesen; nach diesen Versuch-und-Irrtum-Erfahrungen wurden die Lehren auf drei Kriterien verdichtet.

  • Wenn es mehr als eine Seite braucht, wird es nicht gebaut

    • Jede Idee muss in einem One Pager zusammengefasst werden, und dieses Dokument dient als North Star.
    • Der One Pager muss nicht verhandelbar, präzise, ambitioniert und zugleich frei von Ballast sein.
    • Dasselbe Dokument kann für die Kommunikation mit Investor:innen, Mitwirkenden, Teammitgliedern, Freund:innen und Familie verwendet werden.
    • Wenn es in der Zusammenarbeit zu Konflikten kommt, lohnt es sich nicht, über Dinge zu streiten, die nicht im One Pager stehen; wenn etwas wirklich wichtig ist, muss das Dokument entsprechend angepasst werden.
    • Wenn man nicht einmal eine Seite füllen kann, sollte man den Inhalt nicht künstlich aufblasen, sondern erkennen, dass man noch nicht bereit ist, es zu bauen.
    • In diesem Fall sollte man zuerst Recherche, Planung und Prototyping durchführen und den One Pager danach neu schreiben.
    • Wenn der Inhalt über eine Seite hinausgeht, ist es zu komplex und wird nicht gebaut.

  • Die Kerntechnologie muss vom Produkt getrennt sein

    • Unabhängig vom eigentlichen Produkt sollte man eine Core Tech entwickeln, die das Produkt trägt.
    • Core Tech kann eine Methodik, eine Technologie, ein Tool oder ein separates Produkt sein und muss auch ohne das aktuelle Produkt überlebensfähig sein.
    • Diese Trennung verhindert, dass man in einem einzigen Produkt gefangen bleibt, und sorgt dafür, dass sich Fortschritt auch bei Richtungswechseln weiter ansammelt.
    • Produkte ändern häufig ihre Richtung, aber Core Tech bleibt als dauerhafter und kumulativer Vermögenswert erhalten.
    • Langfristig kann eine solche kumulative Arbeit nichtlineare Gewinne erzeugen.
    • Als Beispiele werden Linus Torvalds’ git, HashiCorps HCL und Googles Kubernetes genannt.
    • Dafür braucht es nicht zwingend Ressourcen auf dem Niveau eines Großunternehmens; auch eine aus der Codebasis ausgegliederte Library oder eine fortlaufend verfeinerte Methodik ist möglich.
    • Core Tech sollte zwar 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 Leverage.

  • Eine einzige entscheidende Einschränkung muss das Produkt definieren

    • Im Zentrum des Produkts sollte eine defining constraint stehen, die für Nutzer immer sichtbar ist.
    • Diese Einschränkung muss ein Element sein, dem Nutzer fortlaufend begegnen und mit dem sie interagieren; dadurch entsteht die Identität des Produkts.
    • Eine gute Einschränkung formt das feel des Produkts und durchdringt das gesamte Nutzererlebnis.
    • Bei Minecraft zeigt sich die Identität direkt daraus, dass alles aus Blöcken besteht; bei IKEA daraus, dass es sich um flat-pack-Möbel zur Selbstmontage handelt.
    • Solche Einschränkungen verkleinern den Entscheidungsraum, begrenzen den Umfang und helfen, sich auf die wirklich wichtigen Probleme zu konzentrieren.
    • Wenn man keine Einschränkung wählt oder eine schlechte wählt, driftet das Produkt zu einem aufgeblähten „Allesmacher“ ab.
    • Mit einer gut gestalteten Einschränkung folgt das Produktdesign ganz natürlich aus dieser Vorgabe.
    • Auch diese Einschränkung sollte prominent auf dem One Pager stehen.

Abschließendes Kriterium

  • Wenn auch nur eine der drei Einschränkungen nicht erfüllt ist, wird es nicht gebaut.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 일 전
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

    • Gemeint ist tenets, nicht tenants

  • 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

    • Es wirkt auch ein bisschen wie ein konstruierter hook
      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

    • Streng genommen wirkt das eher wie ein Ziel oder eine Metrik als wie eine Beschränkung

  • 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

    • Man könnte es vielleicht als everything's a space formulieren, also Menschenraum, Stauraum und Arbeitsraum
      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