The Experiment Backlog for Solo Builders (That You Will Actually Run)

kate frese
May 24
3 min read

You don't have a product team. You have you—plus whatever time you can steal between support, shipping, and life.

So when someone tells you to 'build an experiment backlog,' it usually turns into a beautiful Notion board that never gets used, or a chaotic stream of random improvements that feel productive but don't compound.

This post is a solo-builder experiment backlog: hypothesis-driven, brutally constrained, and designed to produce real learning without a 12-person org.

What It Is (And Isn't)

It is: a short list of runnable bets tied to a measurable outcome, a way to turn ideas into learning, and a system that protects your time by forcing constraints. It is not a roadmap, a feature wish list, or a quarterly OKR ritual. A solo backlog exists for one reason: to help you run the next test without friction.

The Core Unit: A Hypothesis-Driven Bet

Every backlog item should be written like a bet you can win or lose:

Hypothesis: If we change X for Y users, then Z metric will improve because [reason]

Test: The smallest change that isolates X

Success metric: One metric and a baseline

Timebox: 2 to 6 hours to run

Example: If we add a 'Pick your goal' step during onboarding, activation will increase because users see a clearer first win. Test: one screen, 3 goal options. Success metric: activation rate. Timebox: 4 hours. If you can't write the hypothesis, you don't have an experiment—you have a vibe.

Rule 1: Cap the Backlog at 10 Items

You don't need 47 experiments. You need 10 good ones. The cap forces you to delete weak ideas, prevents the idea museum problem, and makes review fast. When you hit 10, you can only add a new item if you remove or merge an existing one. More than 10 and your backlog becomes a guilt machine. Guilt is not a strategy.

Rule 2: The 2 to 6 Hour Runnable Test Rule

If an experiment can't be run in 2 to 6 hours, it's not a backlog item yet—it's a project. What qualifies: changing onboarding copy on 3 screens, adding a first-win checklist, shipping a paywall timing adjustment, adding a 2-question in-app prompt. What doesn't: 'rebuild onboarding,' 'add referrals,' 'improve retention.' Shrink those until they're runnable.

Rule 3: One Metric, One Change

Solo builders lose weeks to multi-variable experiments that teach nothing. If you change five things at once, you can't attribute results. Pick one metric, make one change, record the result, decide what to do next. This is how a learning loop compounds.

A Simple Scoring Model

Score each experiment 1 to 5 on: Impact (does it materially move the metric?), Confidence (do you have evidence this is a real problem?), and Effort (can you run it in 2 to 6 hours?). Sort by high impact and low effort first. If two items tie, choose the one that improves activation first, then retention, then monetization.

The Weekly Cadence: 15 Minutes

Pick one experiment to run next (2 minutes)

Confirm it's runnable in 2 to 6 hours (2 minutes)

Confirm one metric and baseline (3 minutes)

Decide the ship window (2 minutes)

Review last week's result and write one sentence of learning (6 minutes)

How to Avoid Busywork

Tie experiments to a single theme for the week (Activation week, Trial-to-paid week, Reduce support load week). Don't run experiments when you're in a fire—your backlog is a tool, not a religion. Track learning not just wins. A failed experiment that rules out a bad path quickly is still valuable. Write one sentence: 'We learned users don't care about X—they care about Y.' That sentence is the compounding asset.

10 Starter Experiments (Solo-Friendly, 2 to 6 Hours Each)

Clarify your onboarding first win with one new screen

Add a recommended next action after the first task completion

Change your paywall timing—after value moment vs. before

Rewrite your pricing page with 3 clarity blocks: who it's for, what you get, what happens next

Add a 2-question in-app feedback prompt after session 2

Improve one high-friction error message (make it actionable and human)

Add a lightweight import sample data option

Update App Store screenshots to tell a 3-step story

Add one lifecycle message tied to a single action (Day 1 or Day 2)

Reduce a key flow from 5 steps to 3 by removing one screen

DISCLAIMER: This post is published by BlueVioletApps LLC, an independent veteran-owned software company. It is not affiliated with, endorsed by, or produced on behalf of any U.S. federal agency, the Department of Defense, or Google LLC. All content is educational and reflects the author's independent perspective.