Product Managers work with data constantly. We look at conversion rates, activation, retention, feature adoption and dozens of other metrics to understand what is happening in a product and decide what to do next.
A dashboard’s numbers depend on stored records, transformations and metric definitions. SQL makes those steps easier to examine: which records were included, how tables were combined and whether the calculation matches the product question.
The starting point is the data model: what each record represents, which identifiers connect it to other records and which limitations affect interpretation.
What is SQL?
SQL — Structured Query Language — is a language used to interact with relational databases. It allows you to ask questions about the information stored there, retrieve specific records and combine or summarise data in different ways.
With customer and order records, SQL can count customers who purchased this month, calculate average order value or identify accounts with no completed purchase. Each question selects a different population and calculation from the same underlying data.
The database contains the underlying records, while SQL provides a way to query those records and turn them into useful information. For Product Managers, that’s usually the most helpful way to think about SQL: it’s a way of asking structured questions about the data your product generates.
Why should Product Managers understand SQL?
Dashboards are useful when the question you want to answer has already been anticipated. If your analytics dashboard contains activation rate by platform, you can simply open it and look at the number.
Product work, however, tends to generate new questions. Perhaps activation suddenly falls and you want to know whether the change affects all users or only Android customers. Maybe a feature is performing well overall but you suspect that new users behave differently from existing ones. Or perhaps a stakeholder asks a question that nobody has thought to add to a dashboard.
Knowing the structure of the data helps specify a question before anyone writes the query. A change in activation needs a defined cohort, a qualifying action and a period in which that action could occur.
For a fall in activation, the investigation can begin by separating eligible new users by platform and checking which step changed. That turns a broad symptom into several comparisons the data can support.
When did it change? Which users are affected? Does it vary by platform, country, acquisition channel or app version? That shift from a vague question to a testable data question is often more valuable than knowing SQL syntax by heart.
Tables, rows and columns
Relational databases commonly organise information into tables. Each table usually represents a type of entity or information, such as customers, orders, subscriptions or products.
Imagine a simple customers table:
| customer_id | name | country |
|---|---|---|
| 101 | Anna | Spain |
| 102 | David | France |
| 103 | Sara | Spain |
Each row represents a record — in this case, a customer — while each column represents a particular attribute, such as the customer’s name or country.
An orders table might contain different information:
| order_id | customer_id | amount |
|---|---|---|
| 5001 | 101 | 49.99 |
| 5002 | 102 | 89.00 |
| 5003 | 101 | 25.50 |
Notice that both tables contain customer_id. That shared identifier allows us to connect a customer with their orders, which becomes particularly important when we start combining information from different tables.
Each row represents a record with attributes, and identifiers connect related records. Before combining tables, check whether a relationship can produce several rows for the same customer.
SELECT: retrieving data
One of the most basic SQL operations is SELECT, which is used to retrieve information from a table.
For example:
SELECT *
FROM customers;
This query retrieves the columns from the customers table. The result still needs interpretation in the context of what each customer record represents.
The * represents all available columns. If you only wanted specific information, you could request individual fields instead:
SELECT customer_id, country
FROM customers;
The query identifies both the requested columns and the table that contains them. In a production analysis, selecting the required columns explicitly makes the result easier to review.
WHERE: filtering data
Most product questions aren’t about every record in a database. Usually, we want to focus on a particular group.
The WHERE clause allows us to filter the data.
For example:
SELECT *
FROM customers
WHERE country = 'Spain';
Instead of returning every customer, this query only returns those whose country is Spain. Filtering defines the population being analysed. Android users, customers in Germany or accounts created last month are different subsets, with different implications for the denominator of a metric.
The syntax may change depending on the question, but the underlying thinking remains the same: which users or records should be included in this analysis?
COUNT: how many?
COUNT calculates the number of records or values matching a query. The following example counts customers whose stored country is Spain:
SELECT COUNT(*)
FROM customers
WHERE country = 'Spain';
The result counts the selected customer records. If the intended question concerns paying customers, the query also needs a condition establishing that they have completed a purchase. Counts appear everywhere in Product Management: registered users, completed orders, activated accounts, failed payments, support requests or people who used a particular feature.
But even a simple count requires a precise definition. Are we counting customers, accounts, sessions or events? Can the same user appear more than once? Are deleted accounts included? The query can calculate the number perfectly while still answering the wrong product question if the underlying definition isn’t clear.
Aggregations
SQL can also summarise many records into useful statistics using aggregation functions.
Common examples include:
COUNT— how many records?SUM— what is the total?AVG— what is the average?MIN— what is the smallest value?MAX— what is the largest value?
Imagine an orders table containing thousands of transactions. Instead of inspecting each order individually, you might calculate:
SELECT AVG(amount)
FROM orders;
This gives you the average order value across the selected records. Aggregations are powerful because they turn large datasets into understandable numbers. They are also where context starts to matter enormously. An average can hide very different behaviours within the population, which is why Product Managers often need to go one step further and segment the result.
GROUP BY: comparing groups
An illustrative average order value of €65 describes the selected orders as a whole. A breakdown by country can show whether the overall figure conceals differences between markets. GROUP BY calculates an aggregate separately for each group. The following example groups customer counts by country:
SELECT country, COUNT(*)
FROM customers
GROUP BY country;
Instead of producing one overall customer count, the result might look like:
| country | customers |
|---|---|
| Spain | 4,820 |
| France | 3,410 |
| Germany | 2,950 |
Grouping makes differences between populations visible. Activation by platform, market or acquisition channel can reveal a pattern hidden by the overall rate. Breaking an aggregate into groups can reveal patterns that disappear completely when everything is combined into a single average.
JOIN: connecting information
Product data is rarely stored in one giant table. Customer information may live in one table, orders in another and subscription information somewhere else.
A JOIN allows data from related tables to be combined.
Remember our two tables:
Customers
| customer_id | name | country |
|---|---|---|
| 101 | Anna | Spain |
| 102 | David | France |
Orders
| order_id | customer_id | amount |
|---|---|---|
| 5001 | 101 | 49.99 |
| 5002 | 102 | 89.00 |
Because both contain customer_id, we can connect each order with the customer who placed it.
Conceptually:
Customers + customer_id + Orders
This could allow us to answer questions such as:
What is the average order value by customer country?
That question requires information from both tables: the order amount comes from the orders table, while the country comes from the customer record. Combining tables introduces a counting risk: a customer with several orders appears several times in an order-level result. The unit being counted must remain consistent with the question.
Identifiers
Identifiers are what allow systems to distinguish one record from another and often provide the connection between different datasets. A user may have a user_id, an order an order_id and a subscription a subscription_id. A related table can store one of those identifiers to associate its records with the corresponding entity.
These identifiers become particularly important when combining data. Names and email addresses can change or may not be unique, while an internal identifier is usually designed to refer to one specific record.
For Product Managers, this becomes relevant when discussing questions such as whether data from two systems can be connected. If your analytics platform uses one identifier and the billing system uses another, the team needs some way to reliably map the same customer across both systems.
NULL: missing isn’t always zero
One concept that frequently causes confusion in data analysis is NULL. NULL generally represents the absence of a value. It doesn’t necessarily mean zero, false or an empty string.
Imagine a table containing:
| customer | purchases |
|---|---|
| Anna | 3 |
| David | 0 |
| Sara | NULL |
David has made zero purchases. Sara’s value, however, is missing. Perhaps her data hasn’t been imported, the field wasn’t tracked when she registered or the information isn’t available for some other reason.
Treating NULL as zero would therefore change the meaning of the data. This is a small technical distinction with potentially large analytical consequences. Before interpreting a metric, it is worth understanding what missing data means in that particular dataset.
Dates and time zones
Time sounds simple until you start analysing data across systems, countries and time zones. Imagine someone asks:
“How many orders did we receive yesterday?”
Before answering, you may need to define what “yesterday” means. Yesterday in Spain? UTC? The customer’s local time? The timezone configured in the analytics platform? An order placed at 00:30 in Madrid may still belong to the previous calendar day in another timezone. This becomes particularly important when comparing reports generated by different systems, because they may not use the same time conventions.
Dates can also be stored in different formats or represent different moments: when an order was created, when payment was confirmed, when it was shipped or when it was completed.
So whenever a product question depends on time, make sure you understand which timestamp is being used and in which timezone it is interpreted.
Data quality
Having data doesn’t automatically mean having trustworthy data. Tracking can break. Events can be sent twice. A field may stop being populated after a release. Historical data may use a different definition from current data, or one platform may behave differently from another.
Imagine your dashboard shows that activation has suddenly fallen by 20%. That could mean user behaviour has genuinely changed, but it could also mean that an event used to calculate activation is no longer being tracked correctly.
Before reacting to a surprising number, it is worth asking whether the data itself is healthy. Useful checks might include whether tracking changed recently, whether the movement affects all platforms, whether another data source shows the same pattern and whether the metric definition has remained consistent.
Before relying on a result, check that the events were collected as intended and that the definition still matches the product behaviour. A tracking failure can resemble a fall in usage.
SQL vs analytics tools
Product Managers often work with tools that make analysis possible without writing SQL. Dashboards, product analytics platforms and business intelligence tools can provide answers much faster than querying a database directly.
That doesn’t make SQL irrelevant. Analytics tools usually present data according to models, events and metrics that someone has already defined. SQL can become useful when the question falls outside those predefined views or when you need to investigate the underlying data more directly.
The two approaches aren’t competitors. A dashboard may be the fastest way to monitor activation every week, while a SQL query might help investigate why activation changed for one specific group of users.
The best tool depends on the question you’re trying to answer.
Translating a product question into a data question
One of the most valuable data skills for a Product Manager is learning to turn a broad business question into something measurable. For a redesigned onboarding, “better” needs an explicit outcome. Completion rate describes how many people finish; time to completion measures the duration; activation examines whether participants subsequently reach the intended milestone. These measures can move in different directions, so the team should select the outcome before inspecting the results.
You may then need to define the population, time period and comparison: New users exposed to onboarding B during the last four weeks vs users exposed to onboarding A during the previous four weeks.
At that point, the original vague question has become something an analyst, a dashboard or a SQL query can actually investigate. Defining the outcome, population and observation window gives the query a clear target. The same discipline applies whether a PM, an analyst or an engineer writes it.
Questions Product Managers should ask about data
When looking at a metric or requesting an analysis, it helps to clarify a few things before jumping to conclusions. Start with the definition. What exactly are we measuring? If we’re talking about an activated user, what needs to happen for someone to count as activated?
Then look at the population. Which users are included or excluded? Are we looking at all registered users, paying customers, new accounts or only people who reached a certain point in the journey?
Time matters too. Which period are we analysing, which timestamp is being used and what are we comparing it with? It’s also worth understanding the source of the information. Does it come from analytics events, a production database, a CRM or another system? Is the tracking complete and reliable?
Segmentation can reveal whether an overall movement is hiding something more specific. Does the pattern change by platform, market, acquisition channel, customer type or app version? Finally, keep the decision in mind. What are we trying to learn, and what would we do differently depending on the answer? Data analysis is much more useful when it is connected to a product decision rather than performed simply because the information is available.
Do Product Managers need to know SQL?
Not every Product Manager needs to write SQL regularly. The answer depends on the company, the product and how easily data can be accessed through other tools. In some organisations, PMs are expected to query data themselves. In others, analysts or data teams handle most of the SQL work. Many companies sit somewhere in between.
Tables, filters, aggregations and joins provide a vocabulary for reviewing an analysis with Data and Engineering. They also make assumptions about missing records or duplicate users easier to identify. With access to an appropriate analysis environment, simple queries can answer routine questions directly. Complex definitions or unfamiliar datasets still benefit from a review with the team responsible for the data.
How much SQL does a Product Manager need?
A practical foundation includes retrieval, filtering, aggregation and the relationships between tables. Understanding SELECT, WHERE, COUNT, basic aggregations, GROUP BY and JOINs already allows you to follow a large proportion of everyday product analysis. Just as importantly, you should understand concepts such as identifiers, NULL values, dates, segmentation and data quality, because those are often where analytical mistakes happen.
For each analysis, record the question and the evidence that would change a decision. That provides a basis for checking whether the query answers what the team intended.
Go deeper: SQL for Product Managers
The SQL examples for product analytics apply these concepts to activation, funnels and retention, with the data definitions needed to interpret each calculation.
SQL becomes much more powerful when it’s connected to the wider product context. Understanding databases helps you make sense of software architecture, while knowing how to query and segment information gives you a stronger foundation for working with product metrics.
Continue with the Technical Product Management learning path to explore APIs, software architecture, product metrics, observability, security and CI/CD.
Explore the book → SQL for Product Managers
Continue learning Technical Product Management
Explore the Technical Product Management learning hub