Lesson 2.2 · Module 2, PM work
Analyse a messy export honestly
Getting a real answer out of a real CSV, and the discipline that stops a confident summary of bad data reaching a leadership deck.
Real exports are dirty. Duplicate rows, three date formats, a free-text field where someone typed “n/a”, “N/A” and “-”, and a column whose name nobody can explain. An agent will happily summarise all of it and give you a number with two decimal places.
The method below produces a number you can defend. It is slower. That is the point.
Step 1 — Describe before analysing
Read @research/support-export.csv. Do not analyse it. Tell me: how
many rows, what each column appears to contain, which columns have missing values and how
many, which have inconsistent formatting, and which rows look like duplicates. Where you
are guessing what a column means, say so.
Read this properly. Nine times out of ten there is something here that changes the question — a date range that does not cover what you thought, a category that accounts for 60% of rows and means “other”.
Step 2 — Agree the cleaning out loud
Propose how to handle each problem you found. For each: what you would do, and what it would hide. Do not do it yet.
“What it would hide” is the whole step. Dropping rows with missing timestamps is reasonable, unless the missing timestamps are all from the mobile client, in which case you have just deleted your finding.
Step 3 — Ask a question that has a wrong answer
Vague questions get vague answers that cannot be checked. Compare:
| Weak | Answerable |
|---|---|
| What are the main themes? | Which three ticket categories account for the most tickets in the first seven days after signup, and what share is each? |
| Are users struggling with onboarding? | What proportion of accounts created in March filed a ticket before completing their first task? |
| Summarise sentiment | How many tickets contain an explicit request for a feature that already exists? Quote five. |
Step 4 — Make it show the working
Give me the answer, and separately: the exact filter you applied, how many rows survived it, and five raw rows I can check by hand.
Check the five. This is the same spot-check habit as lesson 1.3 and it catches the same class of error: an answer computed over a subset you did not intend.
Step 5 — Write the caveats before the summary
Before summarising, list every reason this analysis might be wrong or misleading — data quality, sample, time range, anything you had to assume. Then write a summary of no more than 150 words that a director could read, with the two most important caveats stated in it rather than in a footnote.
Exercise
Use any export you have — support tickets, a survey dump, a signup log. Run all five steps. Then do the honest check: give the same file and the same question to the agent with no method at all, and compare the two answers. They will usually agree on the headline and disagree on everything that would have made you act differently.
Do not paste customer personal data into a practice workspace. Aggregate it, redact it, or use synthetic data. “It was only for analysis” is not a defence anyone accepts, and this is the most likely way a PM creates a genuine problem with a tool like this.
Independent and unofficial. This site is published by readers of Antigravity, not by Google. It is not affiliated with, endorsed by or connected to Google LLC. Nothing is hosted here — no software is mirrored, repackaged or distributed, and no installer, licence key, sign-in or payment is ever requested. Antigravity itself is downloaded only from Google, at antigravity.google. Never enter a Google password, a payment card or an API key on this site — nothing here needs one.