Business Investigation

Systematic root cause analysis for business problems. Engineering debugging adapted for CEO tasks.

Triggers: "why no signups", "why churn", "figure out why X", "what's wrong with Y", "investigate", "dig into"

Iron Law

DO NOT PROPOSE SOLUTIONS WITHOUT INVESTIGATING THE ROOT CAUSE.

• Not "let's redesign the landing page" -> first "WHY signups = 0?"
• Not "let's hire sales" -> first "WHY is the current approach not working?"
• Symptomatic treatment creates whack-a-mole debugging. Find the root cause.

Phase 1: Symptom Collection

1. Define the problem specifically: not "growth is slow", but "0 signups in 7 days with X visitors" or "3 out of 5 customers didn't complete onboarding"
2. Gather data:
   • PostHog: posthog__query-generate-hogql-from-question question="..." for quantitative data
   • MEMORY.md: what do we already know about this problem?
   • Daily logs: were there similar problems before? What was tried?
   • Hypotheses.json: are there related hypotheses?
3. Timeline: when did the problem start? What changed? Regression = cause is in the change.

Phase 2: Pattern Matching

Check typical startup patterns:

Funnel Problems

Structural Problems

Phase 3: Hypotheses (3-Strike Rule)

Formulate 1-3 root cause hypotheses. For each:

HYPOTHESIS: [specific statement]
  Evidence FOR: [what supports it]
  Evidence AGAINST: [what refutes it]
  How to test: [concrete action in 1-2 days]
  If true we'll see: [observable outcome]
  If false we'll see: [observable outcome]

3-Strike Rule: if 3 hypotheses turn out to be wrong -> STOP. The problem is likely architectural (wrong market, wrong product, wrong channel). Escalate:

3 hypotheses tested, none confirmed.
The problem may be deeper — not tactics, but strategy.

A) Continue investigation with a new hypothesis: [describe]
B) Launch strategic-review to reassess wedge/ICP
C) Talk to customers directly (CEO = best investigator)

Phase 4: Root Cause -> Recommendation

When root cause is identified:

1. Name the cause specifically. Not "bad marketing", but "positioning says 'AI platform' instead of a specific outcome we deliver for [your buyer]"
2. Minimal intervention. The smallest change that eliminates the cause.
3. Tie to constraint. Does the solution exploit the constraint (market learning speed) or not?
4. Kill signal. At what result do we abort the solution?

Phase 5: Report

INVESTIGATION REPORT
---
Symptom:        [what we observe]
Root cause:     [why this is happening]
Evidence:       [data confirming]
Recommendation: [what to do]
Metric:         [what to measure]
Kill signal:    [when to abort]
Status:         DONE / DONE_WITH_CONCERNS / BLOCKED
---

Log to memory/YYYY-MM-DD.md via structured-log.

Telegram Format

Investigation: [problem]

Root cause: [1-2 lines]
Evidence: [key proof]

Recommendation: [action]
Metric: [what to measure]

Status: [DONE/BLOCKED/NEEDS_CONTEXT]

Follow output preferences from USER.md (language, format, platform constraints).

Rules

• Data -> hypothesis -> test -> conclusion. Not the other way around.
• Don't say "should fix it". Show evidence.
• If you can't test — say NEEDS_CONTEXT and request specific data.
• Don't expand scope. Investigate one problem, don't switch.