How I Use Linear, Codex, Claude Code, and GitHub to Ship Growth Experiments

A growth experiment usually dies in the space between a good idea and a clean handoff.

The idea starts sharp: change the onboarding question, test a new landing page promise, add a lifecycle nudge, tighten the demo flow. Then it gets copied into a doc, summarized in Slack, translated into tasks, split across design, data, engineering, and marketing, and slowly loses its shape. By the time the experiment ships, nobody is completely sure what the original hypothesis was.

This is where I use Linear, Codex, Claude Code, and GitHub together.

Linear is not where the agents do the work. Linear is where the work stays organized. I use it for task and project management: intake, scope, ownership, dependencies, acceptance criteria, and status.

The agents do the execution. Codex and Claude Code help code, review, test, and prepare changes. GitHub is where those changes become concrete: branches, pull requests, CI, review, and merge history.

The point is not "Linear agents run the experiment." The point is that Linear keeps the experiment legible while agents move the implementation through GitHub.

The Loop

My workflow has six stages:

1. Intake
2. Experiment brief
3. Task graph
4. Instrumentation
5. Launch QA
6. Postmortem

Linear's job is not to make the decision. It keeps the reasoning visible, exposes missing pieces, and keeps every artifact connected to the same hypothesis. The coding agents work from that structure instead of from loose prompts.

Stage 1: Intake

The loop starts with a single Linear issue:

Test whether adding a "sleep goal" question before the screener increases completion rate.

A weak system turns that into a task and loses the context.

A useful Linear issue turns it into questions:

• What segment is this for?
• What metric defines success?
• Is this a conversion test, a qualification test, or a learning test?
• What is the minimum detectable effect?
• What downstream metric could get worse?
• Who needs to approve the copy, event tracking, and launch?

The first output is not a task list. It is a sharper 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.

This already changes the quality of the work. The team is not debating a button or a field. It is debating a mechanism.

Stage 2: Experiment Brief

I create the brief inside Linear and link it to the original issue.

I keep the brief boring:

• Context
• Hypothesis
• Audience
• Primary metric
• Guardrail metrics
• Required events
• Variants
• Owner
• Reviewers
• Launch checklist
• Decision rule

Boring is good. Boring means reusable.

The trick is that the brief stays alive. If the variant changes, I want the issue to make the tradeoff visible: did the hypothesis change, or only the implementation? If a metric gets added, is it primary or a guardrail? If the copy changes, does the message still map to the mechanism?

The brief becomes the spine of the experiment.

Stage 3: Task Graph

Most experiment tracking breaks because the work is represented as a flat checklist.

Experiments are not flat. They are dependency graphs.

For this test, I create linked issues like:

• Write variant copy
• Design onboarding step
• Implement frontend variant
• Add analytics events
• Configure experiment in Statsig
• QA event firing
• Draft launch note
• Monitor first 24 hours
• Readout after sample threshold

Each issue carries the part of the brief it depends on.

The analytics issue has the event names. The design issue has the audience and hypothesis. The QA issue has the guardrail metrics. The readout issue has the decision rule.

That is the difference between project management and workflow memory.

How Codex, Claude Code, and GitHub Fit In

Linear is the project system. Codex, Claude Code, and GitHub are the execution loop around it.

I use Linear to define the work: the hypothesis, acceptance criteria, dependencies, event plan, QA checklist, and decision rule. That gives the coding agents a stable object to work against instead of a vague prompt.

Codex is where I run implementation lanes. For a larger experiment, I split the task graph into narrow Linear issues and let each lane work in its own branch or worktree. One lane might wire the frontend variant. Another might add event tracking. Another might tighten copy, tests, or documentation. The important part is that each lane reports back to the same Linear issue structure: what changed, what was validated, what is blocked, and what evidence exists.

Claude Code is useful when I want a second coding surface in the terminal: reviewing the shape of an implementation, exploring a repo, drafting a migration plan, or pressure-testing whether the code still matches the experiment brief. I do not treat it as a separate source of truth. It is another execution surface pointed back at the same Linear issue.

GitHub is where the work becomes reviewable and shippable. Pull requests attach the code diff, CI status, screenshots, and implementation discussion. Linear keeps the why. GitHub keeps the exact change. The loop works when the PR links back to the Linear issue and validation evidence comes back into Linear.

The workflow looks like this:

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

That is the part that makes the system durable. Linear does not replace GitHub. GitHub does not replace Linear. Codex and Claude Code do not replace judgment. Each tool owns a different part of the loop.

Stage 4: Instrumentation

Instrumentation is where good experiments quietly fail.

The Linear issue carries the event plan before implementation:

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

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

Then every implementation task can be checked against the plan:

• Was the event added?
• Is the naming consistent?
• Are properties available at the point of firing?
• Can the analyst segment by variant, market, and device?
• Does the dashboard match the decision rule?

This is not glamorous. It is exactly the kind of detail that determines whether the experiment creates knowledge or just activity.

Stage 5: Launch QA

Before launch, I keep a QA checklist that is specific to the experiment, not generic to the product.

For this test:

• Variant renders on mobile and desktop
• Goal selection is persisted through the screener
• Existing screener path still works
• Events fire in the right order
• Statsig bucketing is stable
• Dashboard has primary and guardrail metrics
• Rollback owner is assigned
• Support note is ready if users ask about the new step

The launch decision happens in the same place as the work. Not in a meeting note. Not in a Slack thread that will be impossible to find later.

Linear becomes the source of truth for the experiment's state.

Stage 6: Postmortem

The postmortem is where the full loop becomes most useful.

Most teams write readouts as one-off summaries:

Variant B improved completion by 8%, not statistically significant. No launch.

That is not enough.

A useful postmortem answers:

• What did we believe?
• What happened?
• What changed in our understanding of the user?
• What should we try next?
• Which issues, docs, events, screenshots, and dashboards support that conclusion?

The output becomes reusable memory:

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.

That learning does not disappear into a deck. It gets linked to the next backlog item.

What This Stack Is Good At

The best use of this stack is not "do my work."

It is:

• Keep context attached to tasks
• Turn vague ideas into structured briefs
• Identify missing instrumentation
• Create the right dependency graph
• Preserve decision rules
• Make postmortems reusable
• Keep the next experiment connected to the last learning
• Let agents code, review, and validate against a clear issue
• Let GitHub carry the exact diff, review, CI, and merge history

That is why Linear is interesting in an AI-native product development workflow. It already sits where the work is negotiated. The issue is where product, engineering, design, support, sales, and marketing all touch the same object.

If Codex and Claude Code work from that object, they can do more than generate code. They can help keep implementation aligned with the reason the work exists.

The Bigger Point

Growth teams do not need more experiment ideas. They need better experiment memory.

They need the hypothesis, tasks, events, QA, decision, and learning to survive the journey from idea to shipped work.

That is the loop I use Linear, coding agents, and GitHub to run.

Not a faster checklist.

A better memory for how the team learns.