App Growth Investigator

Use this skill to investigate an app or site like a sharp product operator, not a dashboard tourist. Find the behavior that explains why users get value, fail to get value, come back, convert, or disappear, then turn that into specific product questions and experiments.

Core Mindset

Think in funnels. Find the constrained step before debating everything else.
Treat timing as signal. Ask when a behavior happens, not just how often.
Segment aggressively. Aggregates hide the actual mechanism.
Look for value failure, not just "traffic" or "churn."
Care about product-business-model fit. Sometimes the product is working but the packaging is wrong.
Turn every finding into a lever, not just an observation.

Workflow

Frame the business question.
- Examples:
- "Why are new signups failing to activate?"
- "Where is the biggest conversion leak?"
- "Did the March 1 onboarding change improve first-week retention?"
- "Are users getting one-off value without becoming retained users?"
Pick source authority before drawing conclusions.
- Use the rules below.
- Read references/source-patterns.md for common stack combinations.
Get release context before forming hypotheses.
- Check recent pushes, experiments, pricing changes, copy changes, and untouched surfaces.
- Prefer pre/post analysis by exact rollout or change date when the question is about impact.
Choose one funnel family for the job-to-be-done.
- Read references/funnel-patterns.md.
- Define one funnel for the specific user job, not one giant master funnel.
Identify the bottleneck.
- Measure conversion rate, absolute user loss, and delay at each step.
- Spend most of the analysis on the step with the strongest combination of volume loss, delay, and strategic importance to value realization.
Segment before concluding anything.
- At minimum consider real vs test vs uncertain, new vs returning, signed-in vs anonymous when relevant, build or rollout cohorts, and acquisition or entry path when available.
Look for timing cliffs and "done in one sitting" behavior.
- Ask where drop-off is concentrated: same session, same hour, day 0, day 1, day 7, or first billing cycle.
- Check whether users appear to complete the job once and have no reason to return.
End with levers.
- Every finding should suggest a messaging, onboarding, pricing, packaging, adoption, instrumentation, or release follow-up.

Source Rules

Assign authority by claim:
- product database or warehouse for entity truth
- analytics events for interaction paths and timing
- billing system for monetization truth
- release or experiment history for rollout context
- support feedback or surveys for qualitative evidence
- logs when instrumentation is missing
When sources disagree, do not average them together. Quantify the gap and explain what each source can and cannot prove.
Exclude internal, test, bot, and automation traffic by default when possible.
Keep an uncertain bucket when attribution is incomplete instead of hiding ambiguity.
Always show denominators, time windows, and exclusion rules.
If a metric depends on a proxy, say so plainly.

Output Shape

Return a short report with:

Release context
- What changed recently
- What important surfaces have not changed
Funnel and bottleneck
- Funnel definition
- Biggest drop-off or delay
- Magnitude of the loss
Key findings
- 3-7 concrete insights with exact percentages, counts, and time windows
Interpretation
- What the findings likely mean
- Whether they point to friction, weak value, wrong packaging, traffic mix, or instrumentation debt
Recommended next checks
- The next cuts or queries that would confirm or falsify the hypothesis
Product levers
- Specific messaging, onboarding, pricing, packaging, feature, or instrumentation changes worth testing

Reference Guide