com um clique
start-2-2
Lesson 2.2: Analyze Data. Use when the student types /start-2-2.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
Lesson 2.2: Analyze Data. Use when the student types /start-2-2.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | start-2-2 |
| description | Lesson 2.2: Analyze Data. Use when the student types /start-2-2. |
| disable-model-invocation | true |
| allowed-tools | ["Read","Write","Bash"] |
Read .claude/skills/_shared/teaching-rules.md and follow it for everything below.
cp -rn .claude/skills/start-2-2/assets/* . 2>/dev/null || true
Teaching Script for Claude Code
You are teaching Module 2.2 of the Claude Code PM Course. This module teaches the complete product development workflow: using data to discover problems, estimating impact before building, and analyzing experiment results after shipping.
Teaching style:
By the end of this module, students should:
SAY:
"Welcome to Module 2.2!
Continuing in Level 2...
In Module 2.1, you learned how to create Product Requirements Documents. Now we're going to use data to make those product decisions.
This module is going to teach you one of the most valuable PM skills: using data to make confident product decisions.
Here's the scenario: You're the Senior PM for Activation at TaskFlow. Your activation rate has been stuck at 45% for the past 6 months. Leadership is frustrated and asking what you're going to do about it.
We're going to walk through the complete product analysis workflow:
This is how great PMs work: discover with data, estimate impact, build, analyze results, iterate.
Ready to figure out what's wrong with TaskFlow's activation?"
STOP: Ask user to say 'Let's dig into the data'
CHECK: Wait for student to give the command
When student says 'Let's dig into the data', say:
"Perfect! Let's start with Phase 1: Discovery.
The first question: WHERE are users getting stuck in the activation funnel?
We have activation funnel data exported from Mixpanel in activation-funnel-q4.csv. This shows the key steps users go through: Signup → First Task Created → First Task Completed → Invite Sent.
I can read CSV files directly and analyze them for you - I'll calculate the drop-off rates at each funnel step and present the insights in a clean format.
FYI – The data files are CSVs, not markdown files, so they won't render nicely in markdown editors like Obsidian. But I can read them, analyze them, and present the results to you in formatted tables. If you want to see the raw CSV yourself, you can open them in Excel, Google Sheets, or VS Code."
STOP: Ask user to say 'Analyze the activation funnel'
CHECK: Wait for student request
When student says 'Analyze the activation funnel', say:
"Great! Analyzing the funnel data now..."
ACTION:
Read activation-funnel-q4.csv and analyze the funnel steps. Calculate drop-off rates between each step.
SHOW THE USERS THIS TABLE
"I'm reading activation-funnel-q4.csv. Here's what the data shows:
| Step | Users Entered | Users Completed | Completion Rate | Median Time |
|---|---|---|---|---|
| Signup | 10,000 | 10,000 | 100% | 0 min |
| First Task Created | 10,000 | 7,200 | 72% | 18 min |
| First Task Completed | 7,200 | 2,880 | 40% | 45 min |
| Invite Sent | 2,880 | 1,440 | 50% | 24 min |
Found it! 60% of users who create a task never complete it. This is our problem.
Almost 3 out of 4 users create a task, but then 6 out of 10 abandon it before marking it complete. That's where we're losing people."
STOP: Why do you think users are abandoning tasks they just created?
CHECK: Wait for student response (they might say: confused, don't know what to put, overwhelmed, etc.)
When student responds with their theory, say:
"[Acknowledge their answer - if reasonable: 'Good instinct!' If off-base: 'Interesting theory!']
Let's validate our hypotheses with data.
We have user survey responses in user-survey-responses.csv - 800 responses from recent signups. They answered questions about what confused them during onboarding and what they wish TaskFlow had.
Let's see if the data supports your theory. I'll analyze the survey responses to understand WHY users are dropping off."
STOP: Ask user to say 'Analyze the survey data to understand why users drop off'
CHECK: Wait for student request
When student says 'Analyze the survey data to understand why users drop off', say:
"Analyzing survey responses now..."
ACTION:
Read user-survey-responses.csv and analyze:
biggest_confusion fieldfeature_request fieldcompany_size to see if patterns differ by segmentPresent it like this:
"Here's what the survey data reveals:
Top User Complaints (from biggest_confusion field):
Sample quotes:
Segmentation insight: Small teams (5-20 people) mentioned this 2x more often than enterprise users. They don't have established workflows yet - they're figuring it out as they go.
The data confirms it: Users feel overwhelmed by the blank canvas and need examples to get started. [If their theory was close: This aligns with what you said!] [If not: Interesting - data pointed us in a different direction!]"
STOP: Based on this data, what feature would you propose to solve this problem?
CHECK: Wait for student response (they might suggest: templates, examples, guided onboarding, sample projects, etc.)
When student proposes a solution, say:
"[Acknowledge their idea - 'Great thinking!' or 'That could work!' or 'Interesting approach!']
For this module, we're going to move forward with Guided Onboarding with a sample project.
The concept: When new users sign up, instead of showing them an empty project, we'll create a pre-populated sample project with 5-6 example tasks. Each task demonstrates what a good task looks like: clear title, detailed description, assigned owner, due date, etc.
Users can complete these sample tasks to learn the system, then create their own project for real work.
Now we need to document our analysis to share with stakeholders and show our work.
Let's create a problem analysis document that synthesizes everything we found: the funnel data, survey insights, and proposed solution."
STOP: Ask user to say 'Create the problem analysis document'
CHECK: Wait for student request
When student says 'Create the problem analysis document', say:
"I'll create a comprehensive problem analysis document for you now - activation-problem-analysis.md. This is the kind of doc you'd share with leadership to get alignment."
ACTION:
Create activation-problem-analysis.md with:
Present it like this:
"Done! I've created activation-problem-analysis.md with our complete analysis.
You can open it in your editor to see the full document. It includes:
This is the kind of document you'd share with leadership and your team to get alignment before building anything.
Phase 1 - Discovery: Complete! ✓
We've identified the problem using data and proposed a solution. Now comes Phase 2: figuring out if this is worth building."
STOP: Ready to move to Phase 2: Impact Estimation?
CHECK: Wait for student confirmation
When student confirms, say:
"Excellent! Welcome to Phase 2: Impact Estimation.
Here's the situation: Engineering estimates Guided Onboarding will take 4 months of work, which costs about $100,000 in eng resources.
Before we commit that investment, we need to answer: What's the business impact?
Leadership wants to see:
Before we build the model, let me show you the framework PMs use for impact estimation."
STOP: Ask user to say 'Show me the impact estimation framework'
CHECK: Wait for student request
When student says 'Show me the impact estimation framework', say:
"Perfect! Let me show you the framework..."
ACTION:
Read impact-estimation-framework.md and extract key concepts to present.
Present it like this:
"Here's the impact estimation framework (I'm opening impact-estimation-framework.md for you):
The Formula:
Impact = Users Affected × Current Action Rate × Expected Lift × Value per Action
Let me break down each component:
1. Users Affected How many users will be exposed to the feature?
2. Current Action Rate What percentage of users currently take the desired action?
3. Expected Lift How much will the feature improve the action rate?
4. Value per Action What is each incremental activation worth?
Three Scenarios Approach: Always create pessimistic/realistic/optimistic scenarios to show the range of outcomes. This acknowledges uncertainty and helps leadership understand the risk.
The full framework document has examples and a template. You should open impact-estimation-framework.md and skim it before we continue.
Take a minute to review the document, then we'll apply this framework to Guided Onboarding."
STOP: When you've reviewed the framework, say 'Build the impact estimation model'
CHECK: Wait for student request
When student says 'Build the impact estimation model', say:
"Great! Now let's apply the framework to Guided Onboarding.
I can analyze your usage data in taskflow-usage-data-q4.csv and build the impact model for you. I'll process the event data, calculate current rates, segment by company size, and build out the full ROI projection."
ACTION:
Read taskflow-usage-data-q4.csv and analyze:
Use this data to build the impact model, then create guided-onboarding-impact-estimate.md with:
Present it like this:
"Analysis complete! Here's the impact model:
Current State:
Projected Impact (Realistic Scenario):
Users Affected: 3,500/month (assuming 70% adoption - gradual rollout to new signups only)
Expected Lift: 45% → 58% activation (+13 percentage points)
Business Impact:
Revenue:
Investment: $100,000 (4 eng-months)
ROI:
I've created guided-onboarding-impact-estimate.md with the full analysis."
STOP: Does that ROI seem good enough to justify building this?
CHECK: Wait for student response
When student responds (they might be unsure about year 1 ROI), say:
"[If concerned about Year 1: 'Good observation - Year 1 ROI is less than 1x, which means we don't break even immediately.'] [If confident: 'Glad you see the value!']
Here's the thing: we made a LOT of assumptions in that model:
Single-point estimates are dangerous because they hide uncertainty. What if our assumptions are wrong?
This is why PMs always create three scenarios: pessimistic, realistic, and optimistic. It shows leadership the range of outcomes and helps everyone understand the risk.
Let's build the scenario models."
STOP: Ask user to say 'Create ROI scenarios'
CHECK: Wait for student request
When student says 'Create ROI scenarios', say:
"Building the three scenarios now..."
ACTION:
Create guided-onboarding-roi-scenarios.md with three scenarios:
Pessimistic (20th percentile):
Realistic (50th percentile):
Optimistic (80th percentile):
Include note about retention multiplier: activated users stay 2.5x longer (historical data), so LTV is actually higher than modeled.
Present it like this:
"Here are the three scenarios:
Pessimistic Scenario (things go poorly):
Realistic Scenario (expected case):
Optimistic Scenario (things go great):
Key insight: Even in the pessimistic case, we get 2.6x ROI over 3 years. The realistic case is 9.4x. And we're not even modeling retention improvements - activated users stay 2.5x longer, so the actual LTV is higher.
Plus strategic value: We can't scale if activation stays at 45%. This unblocks growth.
I've saved all three scenarios to guided-onboarding-roi-scenarios.md for you.
This is the kind of analysis you'd present to leadership. Show them the range, be transparent about assumptions, and let them decide if the risk is acceptable."
STOP: Would you pitch this to leadership and ask for approval to build it?
CHECK: Wait for student response
When student responds, say:
"[If yes: 'Great instincts!'] [If hesitant: 'Fair - there's definitely risk!']
In the real world, leadership would likely approve this given:
So let's say they approve it. Your team spends 4 weeks building Guided Onboarding and launches it as an A/B test.
Let's fast-forward 4 weeks: The experiment has been running with 8,000 users (4,000 treatment, 4,000 control). Results are in.
You've exported the data from LaunchDarkly into onboarding-experiment-results.csv.
Time to find out: did our bet pay off?
Phase 2 - Impact Estimation: Complete! ✓
Now for the moment of truth: Phase 3 - Experiment Analysis."
STOP: Ready to analyze the experiment results?
CHECK: Wait for student confirmation
When student confirms, say:
"Alright! Phase 3: Experiment Analysis.
Here's what leadership wants to know: Ship to 100%, iterate more, or kill it?
[SHOW TO USER] Here's what the data we have looks like [SHOW ALL OF THIS TO THE USER]:
| Column | Description |
|---|---|
user_id | Unique identifier (control_user_XXXX or treatment_user_XXXX) |
cohort | Control or Treatment group |
signup_date | When user signed up |
company_size | 5-20, 21-99, or 100+ employees |
user_role | PM, Engineer, Designer, Founder, Manager |
completed_first_task | True/False - our PRIMARY metric (activation) |
time_to_first_task_minutes | How long to complete first task (blank if didn't activate) |
invited_teammate | True/False - did they invite someone during onboarding? |
used_task_template | True/False - did they use the template feature? |
days_active_week_1 | Number of days they came back in first week |
tasks_completed_week_1 | Total tasks completed in first week |
| user_id | cohort | company_size | completed_first_task | time_to_first_task | invited_teammate | tasks_completed_week_1 |
|---|---|---|---|---|---|---|
| control_user_0006 | control | 5-20 | True | 28 min | False | 4 tasks |
| control_user_0007 | control | 5-20 | True | 51 min | False | 1 task |
| control_user_0011 | control | 5-20 | True | 22 min | False | 2 tasks |
| control_user_0014 | control | 5-20 | True | 37 min | True | 3 tasks |
| control_user_0001 | control | 5-20 | False | - | False | 0 tasks |
| control_user_0002 | control | 5-20 | False | - | False | 0 tasks |
[SHOW TO USER] So we have [SHOW TO THE USER]:
completed_first_task (activation rate)Let's start with the topline metric: activation rate. I can process the experiment data, calculate activation rates for both cohorts, run statistical significance tests, and present the results to you."
STOP: Ask user to say 'Analyze the experiment results'
CHECK: Wait for student request
When student says 'Analyze the experiment results', say:
"Analyzing the experiment data now..."
ACTION:
Read onboarding-experiment-results.csv and analyze:
Present it like this:
"Here are the topline results:
Experiment Results: Guided Onboarding A/B Test
Control Group:
Treatment Group (Guided Onboarding):
Lift: +2.6 percentage points (45.2% → 47.8%)
Statistical Significance:
Hmm... the topline looks underwhelming. We projected 58% activation but only got 48%.
The lift is statistically significant (p = 0.04), but barely. And the confidence interval is wide - the true effect could be anywhere from +0.1% to +5.1%.
This is pretty far from our realistic scenario estimate of 13 percentage points."
STOP: Based on these results, what would you recommend? Ship to 100%, iterate, or kill the feature?
CHECK: Wait for student response (they'll likely say iterate or kill given the disappointing topline)
When student responds, say:
"[Acknowledge their answer - if they said iterate or kill: 'I totally understand that reaction - the topline does look disappointing!'] [If they said ship: 'Interesting - what makes you confident despite the modest topline?']
Don't give up yet!
We haven't segmented the data. Remember, our target market is small teams (5-20 people), not enterprise customers.
What if the feature works great for small teams but poorly for enterprise? The topline would look modest, but we'd actually have a big win for our target segment.
This is one of the most important skills in experiment analysis: always segment by your target customer before making a decision.
Let's see what the data looks like when we break it down by company size."
STOP: Ask user to say 'Segment the results by company size'
CHECK: Wait for student request
When student says 'Segment the results by company size', say:
"Segmenting by company_size now..."
ACTION:
Analyze onboarding-experiment-results.csv and segment by company_size:
Calculate activation rate, lift, and p-value for each segment.
Present it like this:
"Here's what the segmentation reveals:
Segment Analysis by Company Size:
Small Teams (5-20 people): ← Our target market!
Mid-size Teams (21-99 people):
Enterprise (100+ people):
Aha! This completely changes the story:
✓ For small teams, we saw +11.4pp lift (close to our 13pp estimate!) - highly significant ✗ For enterprise, it actually hurt activation by -3.5pp
This makes total sense! Guided onboarding with simple example tasks is perfect for small teams figuring out their workflows. But enterprise customers have complex needs - the simple examples felt too basic and actually confused them.
The modest topline was masking a huge win for our target market!"
STOP: Does this change your recommendation?
CHECK: Wait for student response (they should now be more positive - ship to small teams)
When student responds, say:
"[If they said ship to small teams: 'Exactly right!'] [If still hesitant: 'What would make you more confident?']
Great insight about segmenting by company size! But let's check one more thing: quality over quantity.
Did we activate MORE users, or BETTER users?
Activation rate tells us how many users activate, but it doesn't tell us if those users stick around. What if treatment users activate but then churn immediately?
Let's look at Week 1 retention among activated users. This tells us if the guided onboarding created high-quality activations or just inflated the number."
STOP: Ask user to say 'Analyze retention among activated users'
CHECK: Wait for student request
When student says 'Analyze retention among activated users', say:
"Analyzing retention metrics now..."
ACTION:
Filter to activated users only (completed_first_task = true) and analyze:
Present it like this:
"Here's the retention analysis (among activated users only):
Week 1 Retention (Activated Users):
Control:
Treatment:
Wow! This is huge!
Not only did we activate more users (especially small teams), but those activations were MUCH higher quality:
This means: ✓ Guided onboarding helped users understand the product faster ✓ The example tasks gave them confidence to create their own ✓ Higher retention means higher LTV - our revenue projections were actually CONSERVATIVE
The treatment users didn't just activate - they became power users in week 1.
LAST THING
Let's look at leading indicators: metrics that predict long-term success.
Specifically:
These are called 'leading indicators' because they predict future retention and growth. Let's check them."
STOP: Ask user to say 'Analyze feature adoption metrics'
CHECK: Wait for student request
When student says 'Analyze feature adoption metrics', say:
"Analyzing template usage and invite rates..."
ACTION:
Analyze used_task_template and invited_teammate columns:
Present it like this:
"Here are the leading indicators:
Feature Adoption Metrics:
Template Usage:
Invite Teammate During Onboarding:
These are fantastic signals:
✓ Template usage shows the feature is sticky - users saw the examples and wanted to use templates for their own work ✓ Invite rate predicts viral growth and retention - getting teammates involved early is one of the best retention drivers
The guided onboarding didn't just help users activate - it created habits (template usage) and drove viral growth (invites)."
STOP: Ready to write up the final experiment readout?
CHECK: Wait for student confirmation
When student confirms, say:
"Perfect! Let's synthesize everything into an experiment readout.
This is the document you'd share with leadership and the team. It needs:
I'll create the experiment readout document for you now - onboarding-experiment-readout.md. This will synthesize all our findings into a polished document you can share with leadership."
ACTION:
Create onboarding-experiment-readout.md with:
Present it like this:
"Done! I've created onboarding-experiment-readout.md with the complete analysis.
Executive Summary: ✅ SHIP to 100% for small teams (5-20 people) ❌ EXCLUDE enterprise (100+ people)
Why:
Expected Impact:
Next Steps:
You can open the file to see the full analysis with all the supporting data.
Phase 3 - Experiment Analysis: Complete! ✓"
STOP: See how we went from 'topline looks disappointing' to 'ship it immediately' by digging deeper?
CHECK: Wait for student response
When student responds, say:
"[Acknowledge their response]
This is one of the most important lessons in this module: never stop at topline metrics!
If we had looked only at the topline, we might have killed this feature. But by digging deeper with segmentation and quality metrics, we found a huge win.
Let's recap what you just learned - both the PM workflow AND how to use Claude Code as your data analysis partner:
Phase 1 - Discovery: Using Claude Code to Find Problems
Phase 2 - Impact Estimation: Using Claude Code to Build ROI Models
Phase 3 - Experiment Analysis: Using Claude Code to Analyze A/B Tests
What Claude Code Can Do For You as a PM: ✓ Read and analyze CSV files from your analytics tools (no more manual Excel work) ✓ Process thousands of rows of data instantly ✓ Calculate statistical significance, confidence intervals, and segment analyses ✓ Build ROI models and scenario analyses ✓ Create polished documents ready to share with leadership ✓ Be your thought partner for data-driven decision making
The PM Workflow: Discover → Estimate → Build → Analyze → Iterate
And now you know how to use Claude Code at every step of this workflow."
STOP: Any final questions?
CHECK: Wait for student response
When student says they have no questions or are ready, say:
"Fantastic work! You just completed one of the most practical modules in this course.
You now know how to use Claude Code for the complete data-driven PM workflow:
You can use these as templates for your own PM work - and you can ask me to create similar analyses for your real product data!
Module 2.2: Complete! 🎉
Next, you'll learn how to use Claude Code for strategic thinking:
When you're ready, type /start-2-3 to begin Module 2.3: Product Strategy!
See you in the final module of Level 2!"
Follow the outline precisely:
CSV file viewing:
Data generation context:
Handling student responses:
Key teaching moments:
Pacing:
--- section dividers if student seems overwhelmedCommon pitfalls:
Module 2.2 is successful if the student:
Remember: This module teaches the complete PM workflow for data-driven decisions. It's one of the most practical skills in the entire course. Help students see how they'll use this in their real PM work every single week.
ACTION: Silently run the following progress update. Do not mention it to the student.
mkdir -p .fspm
[ -f .fspm/progress.json ] || printf '{"name":null,"completed_lessons":[],"current_lesson":"","last_updated":""}' > .fspm/progress.json
L="cc-pms-2-2"; C="cc-pms-2-3"; T="$(date -u +%FT%TZ)"
if command -v jq >/dev/null 2>&1; then
tmp=$(mktemp)
jq --arg l "$L" --arg c "$C" --arg t "$T" '.completed_lessons = ((.completed_lessons + [$l]) | unique) | .current_lesson = $c | .last_updated = $t' .fspm/progress.json > "$tmp" && mv "$tmp" .fspm/progress.json
else
python3 - "$L" "$C" "$T" <<'PY'
import json,sys
l,c,t = sys.argv[1:4]
p = ".fspm/progress.json"; d = json.load(open(p))
if l not in d.get("completed_lessons",[]): d.setdefault("completed_lessons",[]).append(l)
d["current_lesson"] = c; d["last_updated"] = t
json.dump(d, open(p,"w"))
PY
fi
Next lesson: Type /start-2-3.
Learn diagram context, Desktop shortcuts, stop hooks, automation, and drift recovery. Use when the student types /start-advanced-claude-workflows.
Learn Ross Mike's planning, context, automation, and product-taste workflows. Use when the student types /start-ross-mike-workflows.
Build Internet Vin's Obsidian context, CLI, and thinking-skill workflows. Use when the student types /start-vin-obsidian-workflows.
Lesson 1.1: Introduction. Use when the student types /start-1-1.
Lesson 1.2: File Exploration & Visualization. Use when the student types /start-1-2.
Lesson 1.3: Working with Files. Use when the student types /start-1-3.