Wie ich Linear, Codex, Claude Code und GitHub nutze, um Growth Experiments zu shippen

Ein Growth Experiment stirbt meistens in dem Raum zwischen einer guten Idee und einer sauberen Übergabe.

Die Idee startet scharf: Ändere die Onboarding-Frage, teste ein neues Landingpage-Versprechen, füge einen Lifecycle-Nudge hinzu, straffe den Demo-Flow. Dann wird sie in ein Doc kopiert, in Slack zusammengefasst, in Tasks übersetzt, über Design, Data, Engineering und Marketing verteilt und verliert langsam ihre Form. Bis das Experiment shippt, ist niemand mehr ganz sicher, was die ursprüngliche Hypothese war.

Genau hier nutze ich Linear, Codex, Claude Code und GitHub zusammen.

Linear ist nicht der Ort, an dem die Agents die Arbeit machen. Linear ist der Ort, an dem die Arbeit organisiert bleibt. Ich nutze es für Task- und Projektmanagement: Intake, Scope, Ownership, Abhängigkeiten, Acceptance Criteria und Status.

Die Agents übernehmen die Ausführung. Codex und Claude Code helfen beim Coden, Reviewen, Testen und Vorbereiten von Änderungen. GitHub ist der Ort, an dem diese Änderungen konkret werden: Branches, Pull Requests, CI, Review und Merge-History.

Der Punkt ist nicht "Linear-Agents führen das Experiment aus." Der Punkt ist, dass Linear das Experiment lesbar hält, während die Agents die Implementierung durch GitHub bewegen.

Der Loop

Mein Workflow hat sechs Stages:

1. Intake
2. Experiment-Brief
3. Task Graph
4. Instrumentierung
5. Launch QA
6. Postmortem

Linears Aufgabe ist nicht, die Entscheidung zu treffen. Es hält die Begründung sichtbar, legt fehlende Teile offen und hält jedes Artefakt mit derselben Hypothese verbunden. Die Coding-Agents arbeiten aus dieser Struktur heraus statt aus losen Prompts.

Stage 1: Intake

Der Loop startet mit einem einzigen Linear-Issue:

Teste, ob eine "Schlafziel"-Frage vor dem Screener die Completion Rate erhöht.

Ein schwaches System macht daraus einen Task und verliert den Kontext.

Ein nützliches Linear-Issue macht daraus Fragen:

• Für welches Segment ist das?
• Welche Metrik definiert Erfolg?
• Ist das ein Conversion-Test, ein Qualifizierungs-Test oder ein Learning-Test?
• Was ist der Minimum Detectable Effect?
• Welche nachgelagerte Metrik könnte sich verschlechtern?
• Wer muss Copy, Event-Tracking und Launch freigeben?

Das erste Ergebnis ist keine Task-Liste. Es ist ein schärferes Problem-Statement.

Hypothesis:
If we ask users to choose their sleep goal before the screener, completion rate will increase because the flow starts with user motivation instead of clinical qualification.

Primary metric:
Screener completion rate

Guardrail:
Qualified lead rate should not decrease by more than 5%

Decision rule:
Ship if completion improves by 10%+ and guardrail holds.

Das verändert bereits die Qualität der Arbeit. Das Team diskutiert nicht über einen Button oder ein Feld. Es diskutiert über einen Mechanismus.

Stage 2: Experiment-Brief

Ich erstelle den Brief in Linear und verlinke ihn mit dem ursprünglichen Issue.

Ich halte den Brief langweilig:

• Kontext
• Hypothese
• Zielgruppe
• Primäre Metrik
• Guardrail-Metriken
• Erforderliche Events
• Varianten
• Owner
• Reviewer
• Launch-Checkliste
• Decision Rule

Langweilig ist gut. Langweilig heißt wiederverwendbar.

Der Trick ist, dass der Brief lebendig bleibt. Wenn sich die Variante ändert, soll das Issue den Tradeoff sichtbar machen: Hat sich die Hypothese geändert oder nur die Implementierung? Wenn eine Metrik dazukommt, ist sie primär oder ein Guardrail? Wenn sich die Copy ändert, passt die Botschaft noch zum Mechanismus?

Der Brief wird zum Rückgrat des Experiments.

Stage 3: Task Graph

Das meiste Experiment-Tracking bricht zusammen, weil die Arbeit als flache Checkliste dargestellt wird.

Experimente sind nicht flach. Sie sind Dependency Graphs.

Für diesen Test erstelle ich verlinkte Issues wie:

• Variant-Copy schreiben
• Onboarding-Step designen
• Frontend-Variante implementieren
• Analytics-Events hinzufügen
• Experiment in Statsig konfigurieren
• Event Firing per QA prüfen
• Launch-Note entwerfen
• Erste 24 Stunden monitoren
• Readout nach Sample-Schwelle

Jedes Issue trägt den Teil des Briefs, von dem es abhängt.

Das Analytics-Issue hat die Event-Namen. Das Design-Issue hat die Zielgruppe und die Hypothese. Das QA-Issue hat die Guardrail-Metriken. Das Readout-Issue hat die Decision Rule.

Das ist der Unterschied zwischen Projektmanagement und Workflow-Gedächtnis.

Wie Codex, Claude Code und GitHub reinpassen

Linear ist das Projektsystem. Codex, Claude Code und GitHub sind der Ausführungs-Loop darum herum.

Ich nutze Linear, um die Arbeit zu definieren: die Hypothese, die Acceptance Criteria, die Abhängigkeiten, den Event-Plan, die QA-Checkliste und die Decision Rule. Das gibt den Coding-Agents ein stabiles Objekt, gegen das sie arbeiten, statt eines vagen Prompts.

In Codex fahre ich die Implementierungs-Spuren. Für ein größeres Experiment teile ich den Task Graph in enge Linear-Issues auf und lasse jede Spur in ihrem eigenen Branch oder Worktree arbeiten. Eine Spur verdrahtet vielleicht die Frontend-Variante. Eine andere fügt Event-Tracking hinzu. Eine andere strafft Copy, Tests oder Dokumentation. Das Wichtige ist, dass jede Spur an dieselbe Linear-Issue-Struktur zurückmeldet: was sich geändert hat, was validiert wurde, was blockiert ist und welche Belege existieren.

Claude Code ist nützlich, wenn ich eine zweite Coding-Oberfläche im Terminal will: die Form einer Implementierung reviewen, ein Repo erkunden, einen Migrationsplan entwerfen oder unter Druck testen, ob der Code noch zum Experiment-Brief passt. Ich behandle es nicht als separate Source of Truth. Es ist eine weitere Ausführungsoberfläche, die auf dasselbe Linear-Issue zurückzeigt.

GitHub ist der Ort, an dem die Arbeit reviewbar und ship-bar wird. Pull Requests hängen das Code-Diff, den CI-Status, Screenshots und die Implementierungsdiskussion an. Linear hält das Warum. GitHub hält die exakte Änderung. Der Loop funktioniert, wenn der PR auf das Linear-Issue zurückverlinkt und die Validierungsbelege nach Linear zurückkommen.

Der Workflow sieht so aus:

Linear issue -> Codex / Claude Code implementation -> GitHub PR -> review + CI -> Linear readout

Das ist der Teil, der das System dauerhaft macht. Linear ersetzt GitHub nicht. GitHub ersetzt Linear nicht. Codex und Claude Code ersetzen das Urteil nicht. Jedes Tool besitzt einen anderen Teil des Loops.

Stage 4: Instrumentierung

Instrumentierung ist der Ort, an dem gute Experimente still scheitern.

Das Linear-Issue trägt den Event-Plan vor der Implementierung:

Events:
- sleep_goal_step_viewed
- sleep_goal_selected
- screener_started
- screener_completed
- lead_qualified

Properties:
- variant_id
- sleep_goal
- traffic_source
- device_type
- market

Dann lässt sich jeder Implementierungs-Task gegen den Plan prüfen:

• Wurde das Event hinzugefügt?
• Ist die Benennung konsistent?
• Sind die Properties zum Zeitpunkt des Firing verfügbar?
• Kann der Analyst nach Variante, Markt und Gerät segmentieren?
• Passt das Dashboard zur Decision Rule?

Das ist nicht glamourös. Es ist genau die Art von Detail, die entscheidet, ob das Experiment Wissen schafft oder nur Aktivität.

Stage 5: Launch QA

Vor dem Launch führe ich eine QA-Checkliste, die spezifisch für das Experiment ist, nicht generisch für das Produkt.

Für diesen Test:

• Variante rendert auf Mobile und Desktop
• Zielauswahl bleibt durch den Screener hindurch erhalten
• Bestehender Screener-Pfad funktioniert weiterhin
• Events feuern in der richtigen Reihenfolge
• Statsig-Bucketing ist stabil
• Dashboard hat primäre und Guardrail-Metriken
• Rollback-Owner ist zugewiesen
• Support-Note ist bereit, falls Nutzer nach dem neuen Step fragen

Die Launch-Entscheidung passiert am selben Ort wie die Arbeit. Nicht in einer Meeting-Notiz. Nicht in einem Slack-Thread, der später unmöglich zu finden ist.

Linear wird zur Source of Truth für den Zustand des Experiments.

Stage 6: Postmortem

Das Postmortem ist der Ort, an dem der gesamte Loop am nützlichsten wird.

Die meisten Teams schreiben Readouts als einmalige Zusammenfassungen:

Variante B verbesserte die Completion um 8%, nicht statistisch signifikant. Kein Launch.

Das reicht nicht.

Ein nützliches Postmortem beantwortet:

• Was haben wir geglaubt?
• Was ist passiert?
• Was hat sich an unserem Verständnis des Nutzers geändert?
• Was sollten wir als Nächstes versuchen?
• Welche Issues, Docs, Events, Screenshots und Dashboards stützen diese Schlussfolgerung?

Das Ergebnis wird zu wiederverwendbarem Gedächtnis:

Learning:
Motivation-first onboarding increased early engagement but did not improve qualified completions. Users selected goals, but the added step created drop-off before clinical questions.

Next test:
Move goal selection after screener completion and use it to personalize follow-up copy.

Dieses Learning verschwindet nicht in einem Deck. Es wird mit dem nächsten Backlog-Item verlinkt.

Worin dieser Stack gut ist

Der beste Einsatz dieses Stacks ist nicht "mach meine Arbeit."

Es ist:

• Kontext an Tasks gekoppelt halten
• Vage Ideen in strukturierte Briefs verwandeln
• Fehlende Instrumentierung erkennen
• Den richtigen Dependency Graph erstellen
• Decision Rules bewahren
• Postmortems wiederverwendbar machen
• Das nächste Experiment mit dem letzten Learning verbunden halten
• Agents gegen ein klares Issue coden, reviewen und validieren lassen
• GitHub das exakte Diff, Review, CI und die Merge-History tragen lassen

Deshalb ist Linear in einem KI-nativen Produktentwicklungs-Workflow interessant. Es sitzt bereits dort, wo die Arbeit ausgehandelt wird. Das Issue ist der Ort, an dem Produkt, Engineering, Design, Support, Sales und Marketing alle dasselbe Objekt berühren.

Wenn Codex und Claude Code aus diesem Objekt heraus arbeiten, können sie mehr tun, als Code zu generieren. Sie können helfen, die Implementierung mit dem Grund, warum die Arbeit existiert, im Einklang zu halten.

Der größere Punkt

Growth-Teams brauchen nicht mehr Experiment-Ideen. Sie brauchen besseres Experiment-Gedächtnis.

Sie brauchen, dass Hypothese, Tasks, Events, QA, Entscheidung und Learning die Reise von der Idee zur geshippten Arbeit überstehen.

Das ist der Loop, den ich mit Linear, Coding-Agents und GitHub fahre.

Keine schnellere Checkliste.

Ein besseres Gedächtnis dafür, wie das Team lernt.