Lesson 71.1 mapped your flywheel and rated each arrow. At least one is weak or broken — every young flywheel has one. The temptation is to push everywhere: more content, more invites, more channels, more AI. That guarantees you learn nothing. This lesson fixes one arrow with one measured experiment, using leading metrics you can read weekly and lagging metrics you respect quarterly.

Leading versus lagging: steer by the near lights

Lagging metrics record outcomes after they happen: total members, monthly search visits, published assets, revenue attributed to community. They matter — they are the scoreboard — but they move slowly and explain nothing. Leading metrics predict and can be acted on this week: number of first-time posters, median time to first reply, share of threads with a peer-to-peer answer, contributions meeting the card format, digest open-to-click rate, asset drafts clearing the gate.

Map a few per arrow:

• Content → discovery: lagging — search visits; leading — pages indexed, internal click-through to join links.
• Discovery → participation: lagging — new members per month; leading — first-week posts per newcomer, invite-to-first-post rate.
• Participation → contribution: lagging — monthly archived contributions; leading — card-format compliance rate, median feedback time.
• Contribution → assets: lagging — published assets; leading — nominations per month, gate pass rate, review turnaround.
• Assets → discovery: lagging — returning search share; leading — new threads citing an asset, inbound links.

When an arrow breaks, its leading metrics break first. If discovery-to-participation fails, you will see newcomers who never post before you see flat member counts. Read the near lights weekly; check the scoreboard monthly. AI trend-watching from Lesson 70.2 can draft the weekly readout, but a human decides what it means.

One arrow, one change, one decision

Pick the single weakest arrow from your map — the constraint. Design exactly one change aimed at it, leaving everything else steady:

1. Baseline. Record the leading metric for two to four weeks. "First-week posts per newcomer: 0.3." No baseline, no experiment — only vibes.

2. Change. One intervention, sized to the arrow. Weak participation? Add a newcomer onboarding thread with a ten-minute first task and a guaranteed reply within a day. Weak contribution? Simplify the card format or guarantee Friday highlighting. Weak assets? Run a monthly nomination hour. Resist bundles — "new onboarding plus new rewards plus new channel" teaches nothing when numbers move.

3. Decision rule, written first. "If first-week posts per newcomer reach 1.0 within four weeks, keep the onboarding thread and test reply speed next. If not, interview five silent newcomers." Pre-commitment defeats the two classic failures: declaring victory on noise, and moving goalposts when the pet idea flops.

4. Run and read. Hold the change steady for the full window. Log confounds (a holiday, a viral post). At the end, apply the rule. Either promote the change to standard practice and pick the next weakest arrow, or kill it and record why.

A research-builders example: participation-to-contribution is broken — lots of chatter, few card-format teardowns. Baseline: 2 teardowns per month. Change: office-hours thread every Wednesday where the founder live-reviews one draft teardown. Decision rule: 6+ teardowns in the next month keeps it; fewer triggers five member interviews on what blocks them. One arrow, one change, one verdict.

Interview the silence when numbers cannot explain it. Metrics tell you which arrow broke; five short conversations tell you why. Ask silent newcomers what almost got them to post, ask one-time contributors what stopped the second one, and ask lurkers what they read faithfully but never touch. Log answers verbatim-ish, look for the repeated phrase, and let the next experiment target that phrase rather than your theory. Founders routinely guess "people need more incentives" when members say "I did not know my draft was good enough to post" — a wording fix on the card, not a rewards program. Five conversations beat five dashboards for diagnosis.

What not to do

Do not optimize a strong arrow while the constraint starves — doubling discovery into a room where newcomers never post just doubles disappointment. Do not run overlapping experiments on adjacent arrows; you will not know what worked. And do not let AI "fix engagement" with synthetic activity, auto-DMs, or gamified spam. The flywheel runs on genuine repeated interaction (Lesson 69.1). Anything that fakes it mortgages trust for a metric bump.

Exercise: write the experiment

Create FLYWHEEL-EXPERIMENT.md with a one-row diagnosis table plus the experiment record:

Then add: weakest arrow and evidence, chosen leading metric plus baseline, one change (what, who runs it, for how long), decision rule (keep/kill thresholds), decision date, and confound log. Run it. At the window's end, append the verdict in plain language.

Finish line: a one-page FLYWHEEL-EXPERIMENT.md with the diagnosis table, a pre-written decision rule, and a decision date — plus, after the window, a verdict.

Verify quickly: ask "if the number lands exactly on target, do I know what to do Monday?" If not, sharpen the rule.

Common failure mode: three simultaneous changes and a post-hoc story. Discipline here is the whole lesson.

Check your understanding

1. Why are leading metrics better for weekly steering than lagging ones? 2. What are the four parts of a single-arrow experiment? 3. Why must the decision rule be written before the experiment runs?

Next

Experiments repair arrows. Lesson 71.3 keeps the wheel greased permanently — return loops across software, media, utility, and community, designed to be helpful rather than spammy.