Turn solved problems into institutional knowledge

What you'll get

A knowledge base that grows every time you solve something hard, so the second time a problem appears it costs minutes rather than the afternoon the first one took. Most companies pay this tax over and over: the fix lives in one person's head, that person is on leave when it recurs, and someone reinvents the wheel from zero. Compounding is the small habit that ends that cycle.

The steps

1. Capture right after the solve.

/marg:compound

Run it while the details are still warm, ideally in the same session where the problem fell, because the specifics fade fast. If Marg just coordinated the fix across teams, it pulls the facts straight from the session rather than making you retell them.

2. Confirm the five facts. A useful entry answers five questions: the exact problem in one sentence, the root cause rather than the symptom, the fix as concrete steps, how you verified it actually worked, and the conditions it applies under, your stack, stage, or market. Marg drafts these from context and asks you only for what it genuinely cannot infer.

3. Let it file. The entry lands in a solutions folder as a structured, searchable document with category tags. This is the part that separates it from session memory. Memory belongs to one working folder, while a compounded solution is written to be found later by anyone, including teams that never saw the original incident.

4. Reap on the second occurrence. When a similar problem turns up, the relevant teams check the knowledge base before they start from scratch, and you can search it yourself just by describing the problem.

What comes back

Immediately, a confirmation with the entry's location and tags. The real return is deferred and larger: it arrives months later as an answer that opens with "this happened before, and here is exactly what fixed it," instead of a blank page.

What deserves compounding

Not everything, and being selective is what keeps the base searchable. A one-time typo fix is noise. Anything you would sit a new hire down and explain is signal: the churn spike that turned out to be a broken billing webhook, the ad account structure that finally cleared review, the onboarding email that doubled activation. The test is simple. Could this problem plausibly come back in a different month wearing different clothes? If yes, compound it.

Variations

• Decisions compound as well as fixes. A rationale document earns its place here too. Capturing why you chose usage-based pricing, with the evidence you had at the time, saves the next pricing debate from starting at zero.
• The heartbeat surfaces candidates. If you run /marg:heartbeat (chapter 8), it flags recurring patterns worth compounding, so the habit half-maintains itself on the days you forget.

If something goes wrong

• The entry came out vague: the root-cause line is almost always the culprit. Rerun and push past the symptom ("conversion dropped") to the mechanism ("the trial email sequence silently stopped sending"), because the future version of you will search by mechanism, not symptom.
• You compounded something wrong: fix it like any document. Tell Marg what changed, and the entry is revised with the corrected understanding rather than left to mislead.
• Nothing ever gets found: entries written without their conditions match nothing later. Always include stage and stack when you capture, because a line like "applies to self-serve SaaS under 1M ARR" is what makes the search land.