Most product decisions hinge on a number someone has to look up — signups this week, retention for a cohort, which variant converted better. This path teaches exactly enough SQL for a PM to answer the simple versions of those questions directly, and to spot when a number someone hands you deserves a second look. It's deliberately narrower than the analyst or engineering paths — the goal is confident self-serve querying, not production-grade data engineering.

1

Why SQL for PMs — Self-Serve Basics
15 min

A SELECT statement asks a database a question in plain structure: which columns, from which table. Once you can read one, you can answer a surprising number of "can you quickly check..." Slack messages yourself, instead of waiting in an analyst's queue for a five-minute lookup.
```
SELECT name, signup_date, plan
FROM users
LIMIT 20;
```
LIMIT is your friend when exploring a table for the first time — preview a handful of rows before running anything against the full dataset.

Lesson: Introduction to SQL Lesson: SELECT Statements
2

Filtering & Segmenting Users
25 min

"How many premium users signed up this quarter?" is a WHERE clause with two conditions joined by AND. This one clause is behind almost every segment a PM ever asks for — the trick is being precise about exactly which rows you mean.
```
SELECT COUNT(*)
FROM users
WHERE plan = 'premium'
  AND signup_date >= '2026-01-01';
```
WHERE filters individual rows before any grouping happens; HAVING filters an already-grouped result — worth knowing the difference before asking for a filtered aggregate.

Lesson: WHERE Clause Blog: SELECT vs WHERE vs HAVING
3

Sorting, Grouping & Basic KPIs
25 min

GROUP BY turns a pile of individual rows into a number per segment — signups per day, average session length per plan. Pair it with ORDER BY to surface the highest or lowest values first, the ones a stakeholder will ask about.
```
SELECT plan, AVG(session_length) AS avg_session
FROM sessions
GROUP BY plan
ORDER BY avg_session DESC;
```
Before trusting a grouped number, sanity-check it against something you already know — a rough order of magnitude is often enough to catch an obviously wrong query.

Lesson: GROUP BY Lesson: ORDER BY
4

JOINs: Connecting Product Usage Data
30 min

User data and event data almost always live in separate tables. A JOIN connects them through a shared key like user_id — LEFT JOIN specifically, when you want every user included even the ones with zero product events yet.
```
SELECT u.name, u.plan, COUNT(e.id) AS events
FROM users u
LEFT JOIN product_events e ON e.user_id = u.id
GROUP BY u.name, u.plan;
```
You don't need to write every JOIN yourself to benefit from understanding them — it's exactly what lets you sanity-check a number a teammate hands you.

Lesson: JOINs Blog: INNER vs LEFT vs RIGHT JOIN
5

Common Pitfalls: Fan-Out JOINs & Double Counting
30 min

This is the module that saves you from shipping a wrong number in a deck. Joining users to a one-to-many events table without aggregating first can silently multiply a user with 500 events into 500 rows — quietly inflating any "total users" count pulled from that joined result.

COUNT(DISTINCT user_id) and plain COUNT(*) can give wildly different answers on a joined events table — know which one you actually mean before trusting the number.

Blog: Why SQL queries return different row counts Blog: Why SQL queries return unexpected results
6

CASE Statements for Quick Segmentation
20 min

PMs think in buckets — "power users," "at risk," "trial." CASE builds those labels directly in a query, and you can GROUP BY the label to get a rollup and a segment in a single step.
```
SELECT
    CASE
        WHEN sessions_last_30d >= 20 THEN 'power user'
        WHEN sessions_last_30d >= 5  THEN 'active'
        ELSE 'at risk'
    END AS segment,
    COUNT(*) AS users
FROM user_activity
GROUP BY 1;
```
Writing the segment definition as SQL, not a slide-deck description, forces the boundaries to be exact — no ambiguity about what "active" actually means.

Lesson: CASE Statements
7

Basic Funnel Queries (Conversion Steps)
30 min

"Of everyone who signed up, how many activated?" is a funnel question — counting users who cleared each step in an ordered sequence, then comparing step-to-step. It's conditional counting at heart, once you break it down.

A funnel is inherently sequential — before writing the query, be explicit about what each step actually means and in what order they're meant to happen.

Blog: SQL for funnel analysis
8

Reading & Writing Queries With Confidence
20 min

The real skill this path builds isn't memorizing syntax — it's knowing what to ask for precisely, spotting an obviously wrong number, and reading a query someone else wrote well enough to sanity-check its logic before you put it in a deck.

Before trusting a number, compare it against a reference point — a dashboard, a teammate's query, or a quick manual spot-check — the same habit that keeps analysts' numbers defensible.

Blog: When the dashboard number doesn't match the database Blog: NULL handling in SQL