PM Mapped — AI for SQL Fundamentals for PMs

1How to use AI for this

A step-by-step way to work

Describe your tables first

Before asking for a query, tell the AI what data you have: the table names, the key columns, and what each row represents (e.g. 'an events table where each row is one user action, with user_id, event_name, and created_at'). AI guesses badly when it's guessing your schema.

Ask your question in plain English

State exactly what you want to know — 'how many users completed onboarding last week, by signup source'. Be specific about the time window, the grouping, and what counts. Vague questions get vague (or wrong) SQL.

Read the query before you run it

Ask the AI to explain what the query does in plain English, line by line. This is where you catch wrong joins, missing filters, or double-counting — before a wrong number reaches a decision.

Run it, then sanity-check the result

Compare the answer against something you already know to be roughly true. If 'active users last week' comes back as 4 or as 4 million, the query is wrong, not your business.

Iterate in conversation

If the result looks off, tell the AI what's wrong ('this is double-counting users who did the action twice') and ask it to fix the query. Treat it as a pairing session, not a one-shot.

2Worked examples

Real prompts, and what good output looks like

Turning a plain-English question into SQL

Your prompt

I have an `events` table (one row per user action: user_id, event_name, created_at) and a `users` table (user_id, signup_source, created_at). Write me a query for: how many distinct users triggered the 'onboarding_complete' event in the last 7 days, broken down by their signup_source.

What good output looks like

SELECT u.signup_source,
       COUNT(DISTINCT e.user_id) AS users_completed
FROM events e
JOIN users u ON u.user_id = e.user_id
WHERE e.event_name = 'onboarding_complete'
  AND e.created_at >= CURRENT_DATE - INTERVAL '7 days'
GROUP BY u.signup_source
ORDER BY users_completed DESC;

Notice: it used COUNT(DISTINCT user_id), not COUNT(*) — so a user who completes onboarding twice is counted once. That's the kind of thing to verify: ask it why it chose DISTINCT, and confirm that matches what you meant.

Asking it to explain a query you inherited

Your prompt

Explain what this query does, in plain English, and flag anything that might be a mistake: SELECT date_trunc('week', created_at) AS wk, COUNT(*) FROM orders WHERE status = 'completed' GROUP BY 1 ORDER BY 1;

What good output looks like

This groups completed orders into weekly buckets and counts how many there are per week, oldest week first.

One thing to watch: it counts every completed order row. If a single order can appear as more than one row (e.g. one row per line-item), this over-counts orders — you'd want COUNT(DISTINCT order_id) instead. Worth checking how your orders table is structured.

This is the highest-value use: AI as a translator for SQL you didn't write, including spotting the double-counting trap before you trust the number.

3Copy-paste template

A prompt you can reuse

Fill in the highlighted parts and paste it into your AI tool of choice. Edit the output — it's a starting point, not a finished answer.

Reusable prompt

I'm a product manager and I want to answer a data question with SQL. I am not a SQL expert, so please write the query, then explain it in plain English so I can check it.

My data:
- Table [table name]: one row per [what each row represents], with columns [key columns].
- (Add any other tables and how they join, e.g. "users joins events on user_id".)

The question I want answered:
[your question in plain English — include the time window, any grouping, and what counts]

Please:
1. Write the SQL query (assume [your database, e.g. PostgreSQL / BigQuery] syntax).
2. Explain in plain English what it does, line by line.
3. Flag any assumptions you made, and anything that could double-count or miss rows.

4Common pitfalls

What AI gets wrong here

Wrong joins that silently change the count

AI may join tables in a way that duplicates rows (a one-to-many join), inflating your numbers without any error message.

Do this instead: Ask it to explain the join and whether it could create duplicate rows. Sanity-check the total against a number you already know.

Counting rows when you meant users

COUNT(*) counts rows; if a user has many rows, that's not 'number of users'. AI doesn't always know which you meant.

Do this instead: Be explicit: 'count distinct users, not rows'. Verify it used COUNT(DISTINCT …) where you expected.

Confident SQL against a schema it's guessing

If you didn't describe your tables, AI invents plausible column names that may not exist — the query looks right and fails, or worse, runs on the wrong column.

Do this instead: Always describe your real tables and columns first. Don't run a query that references columns you can't confirm exist.

Timezone and date-boundary errors

'Last 7 days' can mean slightly different things depending on timezone and whether today is included — a common source of off-by-a-bit numbers.

Do this instead: Tell it your timezone and whether the current day should be included, and check the date range the query actually covers.

The judgment that stays yours

AI writes the SQL; you own whether the number is true. It will produce confident, well-formatted queries against tables it doesn't really understand — wrong joins, double-counts, silent filters — and none of those raise an error. The skill AI hasn't replaced is knowing your data well enough to smell when a result is wrong, and understanding the query well enough to trust it before it informs a decision. Use AI to go from question to query in minutes; never let it go from query to decision without your eyes on both.