Decision Log für Startups
Startups treffen hunderte Entscheidungen pro Woche. Die meisten verschwinden in Slack-Threads. So baust du ein Decision Log, das hält.
By Ellis Keane · 2026-03-16
1986 zerbrach die Raumfähre Challenger 73 Sekunden nach dem Start. Die nachfolgende Untersuchung ergab, dass Ingenieure bei Morton Thiokol am Vorabend Bedenken wegen der O-Ring-Dichtungen geäußert hatten – das kalte Wetter mache einen Start unsicher, argumentierten sie. Das Management überstimmte sie. Die Entscheidung fiel in einer Telefonkonferenz, und obwohl Diagramme und Aussagen vorlagen, war die kritische Begründung hinter der Überstimmung auf die Teilnehmer verteilt und nie zuverlässig nach oben weitergegeben worden.
Ich vergleiche die Produktentscheidungen eures Startups nicht mit einer Shuttle-Katastrophe (na ja, nicht die meisten davon). Aber das zugrunde liegende Fehlermuster ist dasselbe, das ich jede Woche bei Startups beobachte – nur mit geringerem Einsatz: Eine Entscheidung wird getroffen, die Begründung dahinter lebt im Kopf von jemandem oder in einem Slack-Thread, der gerade aus dem Sichtfeld scrollt, und drei Monate später kann niemand mehr rekonstruieren, warum wir Ansatz A gegenüber Ansatz B gewählt haben. Nicht weil die Entscheidung falsch war – manchmal war sie großartig –, sondern weil der Kontext, der sie richtig machte, verflogen ist.
"Eine Entscheidung wird getroffen, die Begründung dahinter lebt im Kopf von jemandem oder in einem Slack-Thread, der gerade aus dem Sichtfeld scrollt, und drei Monate später kann niemand mehr rekonstruieren, warum wir Ansatz A gegenüber Ansatz B gewählt haben." – Ellis Keane
Ein Decision Log für Startups ist keine bürokratische Übung. Es ist der Unterschied zwischen „Das haben wir versucht, und es hat nicht funktioniert" (nützlich) und „Ich glaube, wir haben darüber irgendwann mal gesprochen?" (nutzlos).
Die Anatomie einer verlorenen Entscheidung
Lass mich eine konkrete Entscheidung durch ihren Lebenszyklus verfolgen, denn die abstrakte Version dieses Problems ist weniger überzeugend als die konkrete.
Es ist ein Dienstag im Februar. Dein Head of Engineering und dein PM diskutieren in einem Slack-Thread, ob sie ein eigenes Benachrichtigungssystem bauen oder einen Drittanbieter nutzen sollen. Der Thread hat 47 Nachrichten (ich weiß, aber so läuft das eben), und bei Nachricht 38 haben sie sich für den Drittanbieter entschieden, weil der eigene Aufbau drei Sprints dauern würde und die Launch-Deadline in zwei Wochen liegt.
Der PM erstellt ein Linear-Issue: „[Service X] für Benachrichtigungen integrieren." Ein Ingenieur nimmt es auf und beginnt mit der Entwicklung. Der Slack-Thread ist technisch gesehen noch vorhanden, aber niemand setzt ein Lesezeichen oder verlinkt ihn im Linear-Issue.
Schnitt zu Mai. Der Drittanbieter hat ein Zuverlässigkeitsproblem. Jemand fragt: „Warum haben wir das nicht selbst gebaut?" Der PM erinnert sich an das Gespräch, aber nicht an die Details. Der Head of Engineering ist in Elternzeit. Der Slack-Thread befindet sich irgendwo im #engineering-Kanal vom Februar, aber niemand erinnert sich an das genaue Datum, und die Slack-Suche liefert 200 Ergebnisse für „Benachrichtigung" – denn natürlich diskutiert jedes Team ständig über Benachrichtigungen.
Das Team verbringt 45 Minuten in einem Meeting damit, die ursprüngliche Begründung zu rekonstruieren. Letztlich kommen sie zur gleichen Schlussfolgerung – die Zeitbeschränkung galt immer noch –, aber die 45 Minuten sind weg, und der Zweifel bleibt. Multipliziere das mit den Dutzenden von Entscheidungen, die ein Startup jeden Monat trifft, und du hast eine beachtliche Menge Zeit, die damit verbracht wird, bereits durchdacht getroffene Entscheidungen erneut zu debattieren.
Warum Startups besonders schlecht darin sind
Große Unternehmen (trotz all ihrer Fehler, und es gibt viele) tendieren dazu, institutionelles Gedächtnis in Prozessen zu verankern: Architecture Decision Records, RFCs, Design-Dokumente, die formale Review-Zyklen durchlaufen. Die Entscheidungen sind vielleicht in Confluence vergraben, aber sie sind zumindest irgendwo auffindbar aufgeschrieben.
Startups haben diese Infrastruktur nicht, und sie aufzubauen fühlt sich genau wie der Overhead an, den man vermeiden soll, wenn man klein und schnell ist. Es gibt ein vernünftiges Argument dafür, dass „wir erinnern uns einfach" bei vier Personen funktioniert – und das tut es auch –, bis Mitarbeiter Nummer fünf dazukommt und keinen Kontext hat, warum irgendetwas so ist, wie es ist.
Das andere, was das Nachverfolgen von Entscheidungen bei Startups besonders schwierig macht, ist die Tool-Fragmentierung. Entscheidungen fallen überall: Slack-Threads, Zoom-Calls, Notion-Kommentare, Linear-Diskussionen, GitHub-PR-Reviews und – zunehmend – in DMs, die nie in einen gemeinsamen Kanal gelangen. Jedes Tool erfasst einen Teil der Entscheidung, aber keines erfasst das Ganze, und die Verbindungen zwischen ihnen werden durch menschliche Erinnerung aufrechterhalten, die – liebevoll gesagt – die unzuverlässigste Datenbank ist, auf die wir Zugriff haben.
Was ein Decision Log wirklich braucht
Es gibt die Versuchung, das zu überentwickeln. Ich habe Teams gesehen, die aufwendige Notion-Datenbanken mit 15 Eigenschaften pro Eintrag erstellt haben – Entscheidungstyp, Auswirkungsebene, Review-Status, Stakeholder, zugehörige OKRs – und sie dann nie genutzt haben, weil der Aufwand, all diese Felder für jede Entscheidung auszufüllen, höher ist als der wahrgenommene Nutzen.
Ein Decision Log für Startups muss so leichtgewichtig sein, dass die Leute es tatsächlich nutzen. Das ist wichtig:
Die Entscheidung selbst. Ein Satz. „Wir verwenden Service X für Benachrichtigungen, anstatt selbst zu entwickeln." Kein Absatz – ein Satz.
Wer sie getroffen hat und wann. Name und Datum. Das klingt offensichtlich, aber es ist der Teil, der am wichtigsten ist, wenn jemand die Entscheidung sechs Monate später in Frage stellt. Es geht nicht um Schuld (nun ja, meistens nicht) – es geht darum zu wissen, wen man nach der ursprünglichen Begründung fragen kann.
Welche Alternativen erwogen wurden. Zwei oder drei Aufzählungspunkte. „Eigene Entwicklung erwogen (3-Sprint-Schätzung, Deadline zu eng)" und „Service Y erwogen (Preisgestaltung skaliert nicht über 10.000 Nutzer)." Das ist der Teil, der erneute Debatten verhindert – wenn die Alternativen und ihre Kompromisse dokumentiert sind, muss das Team sie nicht neu entdecken.
Wo die Diskussion stattfand. Ein Link zum Slack-Thread, dem Linear-Issue, dem Notion-Kommentar – wo immer die eigentliche Debatte stattfand. Das ist das am meisten unterschätzte Feld. Ohne es ist der Log-Eintrag eine Behauptung ohne Beweis. Mit ihm kann jeder, der den vollen Kontext möchte, die ursprüngliche Konversation nachlesen.
Was die Entscheidung ändern würde. Das ist optional, aber unglaublich nützlich für Startups, bei denen sich der Kontext schnell verändert. „Wir würden das überdenken, wenn sich die Launch-Deadline um mehr als vier Wochen verschiebt" oder „Das setzt voraus, dass wir unter 10.000 monatlichen Benachrichtigungen bleiben." Es verwandelt ein statisches Protokoll in ein lebendiges.
Das beste Decision Log für Startups ist das, das dein Team tatsächlich ausfüllt. Fünf Felder, je ein Satz. Wenn es mehr als 90 Sekunden dauert, eine Entscheidung zu protokollieren, wird das System innerhalb eines Monats sterben.
Wo es ablegen?
Ich habe Teams gesehen, die drei Ansätze ausprobiert haben – alle haben Kompromisse.
Eine Notion-Datenbank. Das ist der häufigste Ansatz und funktioniert einigermaßen gut. Erstelle eine Datenbank mit den fünf Feldern oben, füge eine Vorlage hinzu, damit das Ausfüllen schnell geht, und verlinke jeden Eintrag mit der entsprechenden Projektseite. Der Nachteil: Notion ist der Ort, wo Spezifikationen leben, nicht wo Entscheidungen getroffen werden – du verlässt dich also darauf, dass jemand nach der Entscheidung extra zu Notion geht. Dieser „Nachher"-Schritt ist der Punkt, an dem die Nutzung einbricht.
Direkt in Slack. Einige Teams verwenden einen dedizierten #decisions-Kanal und posten für jede Entscheidung eine formatierte Nachricht. Das ist weniger reibungsbehaftet (die Entscheidung wurde wahrscheinlich sowieso in Slack getroffen), aber die Slack-Suche macht es schwer, Entscheidungen nach Projekt oder Datumsbereich zu finden, und das Fehlen strukturierter Felder bedeutet, dass die Konsistenz im Laufe der Zeit nachlässt.
Direkt in Linear. Wenn die Entscheidung sich auf einen bestimmten Workflow bezieht, hält das Protokollieren als Kommentar im entsprechenden Linear-Issue die Entscheidung nah an der Arbeit, die sie betrifft. Der Nachteil: Entscheidungen, die mehrere Issues oder Projekte umfassen, haben keinen natürlichen Platz.
Keiner davon ist großartig, wenn ich ehrlich bin. Das grundlegende Problem ist, dass Entscheidungen über Tools hinweg getroffen werden, aber Protokolle in einem Tool leben – es gibt also immer einen manuellen Schritt, um die Lücke zu überbrücken. Dieser manuelle Schritt ist der einzige Fehlerpunkt bei jedem Decision Log, das ich gesehen habe.
Was wir bei Sugarbug aufbauen
Der Ansatz, den wir mit Sugarbug verfolgen, besteht darin, Entscheidungen zu erkennen, während sie über verschiedene Tools hinweg getroffen werden – anstatt jemanden zu bitten, sie manuell zu protokollieren.
Wenn ein Slack-Thread zu einem Ergebnis kommt („OK, wir nehmen Service X"), wenn eine Linear-Issue-Diskussion abgeschlossen wird, wenn ein GitHub-PR-Review mit einer Genehmigung endet – das sind alles Signale, dass eine Entscheidung getroffen wurde. Sugarbug nimmt diese Signale auf, klassifiziert sie und verknüpft sie mit den relevanten Aufgaben und Personen im Wissensgraph. Das „Decision Log" ist keine separate Datenbank, die jemand pflegen muss – es ist eine Übersicht über die Entscheidungen, die bereits in deinen bestehenden Tools eingebettet sind.
Wir arbeiten noch an der Klassifizierungsgenauigkeit (herauszufinden, was der Unterschied zwischen „einer Entscheidung" und „nur einem Gespräch" ist, ist schwieriger als es klingt), aber die Richtungswette ist, dass das Erfassen von Entscheidungen an der Quelle – wo sie tatsächlich passieren – zuverlässiger ist als Menschen zu bitten, sie in ein separates System zu duplizieren.
Falls dich das interessiert, findest du auf sugarbug.ai mehr Details. Aber das oben beschriebene manuelle System wird den meisten Startups gut dienen, bis das Team groß genug ist, dass die Ausfallrate beim manuellen Protokollieren zu einem echten Problem wird – in unserer Erfahrung in der Regel irgendwo zwischen 8 und 12 Personen.
Hör auf, Entscheidungen durch Slack-Scrollen zu verlieren. Sugarbug erfasst sie automatisch aus den Tools, in denen sie tatsächlich passieren.
Q: Was sollte ein Startup-Decision-Log enthalten? A: Mindestens: die Entscheidung selbst (ein Satz), wer sie getroffen hat, wann, welche Alternativen erwogen wurden und wo die Diskussion stattfand. Das letzte Feld ist am wichtigsten – ohne einen Link zur ursprünglichen Konversation wird der Log-Eintrag zu einer Behauptung ohne Beweis, und wenn jemand sechs Monate später Fragen stellt, bist du wieder damit beschäftigt, aus dem Gedächtnis zu rekonstruieren.
Q: Erstellt Sugarbug automatisch ein Decision Log aus bestehenden Tools? A: Das ist die Richtung, in die wir uns bewegen. Sugarbug nimmt Signale von Slack, Linear, GitHub, Notion und anderen Tools auf und klassifiziert sie in einem Wissensgraph. Wenn es eine Entscheidung erkennt – einen genehmigten PR, eine abgeschlossene Linear-Diskussion, einen Slack-Thread, der mit einem klaren nächsten Schritt endet –, verknüpft es diese Entscheidung automatisch mit der relevanten Aufgabe und den beteiligten Personen. Wir verfeinern noch die Klassifizierung (die Unterscheidung von „Entscheidung" und „Gespräch" ist echte Detektivarbeit), aber die Signal-Aufnahme und -Verknüpfung funktionieren.
Q: Wie oft sollte ein Startup sein Decision Log aktualisieren? A: Idealerweise werden Entscheidungen protokolliert, sobald sie getroffen werden – nicht gebündelt wöchentlich. Bis Freitag ist die Begründung hinter der Entscheidung vom Dienstag bereits verschwommen, und die Chance, dass jemand das Feld „berücksichtigte Alternativen" korrekt ausfüllt, sinkt schnell. Bei manuellem Protokollieren: mach es zur 90-Sekunden-Gewohnheit unmittelbar nach der Entscheidung. Bei einem Tool wie Sugarbug ist das Ziel die Erfassung in Echtzeit aus den Tools, in denen Entscheidungen tatsächlich getroffen werden.
Q: Kann Sugarbug Entscheidungen über Slack, Linear und GitHub hinweg verfolgen? A: Sugarbug verbindet sich mit allen dreien (und Notion und Figma) und pflegt einen Wissensgraph der Beziehungen zwischen Konversationen, Aufgaben und Code-Änderungen. Wenn eine Entscheidung in einem Slack-Thread auftaucht, zu einem Linear-Issue führt und einen GitHub-PR erzeugt, verknüpft Sugarbug die gesamte Kette – sodass du die Entscheidung vom Ursprung bis zur Implementierung nachverfolgen kannst, ohne dass jemand diese Links manuell erstellen muss.
Q: Was ist der Unterschied zwischen einem Decision Log und einem Architecture Decision Record (ADR)? A: ADRs sind typischerweise formelle Dokumente für bedeutende technische Entscheidungen – „Wir verwenden PostgreSQL statt MongoDB" – mit strukturierten Abschnitten für Kontext, Entscheidung und Konsequenzen. Ein Decision Log für Startups ist breiter und leichtgewichtiger: Es erfasst die täglichen operativen Entscheidungen (welcher Anbieter, welche Deadline, welche Funktion zu kürzen), die ADRs für zu klein zum Dokumentieren halten würden. Beide sind wertvoll; das Decision Log deckt die 95 % der Entscheidungen ab, die keinen formalen ADR rechtfertigen, aber dennoch nachverfolgbar sein müssen.