Every product manager has been there. You need to know how many users completed the onboarding flow last week. Or which features power users interact with most before they churn. Or what percentage of trial accounts converted after seeing the new pricing page. These aren't hard questions. But getting answers takes writing a Jira ticket, waiting for an engineer to have a spare hour, and hoping the query they write matches what you actually meant.

The result: PMs make decisions with stale data, rely on pre-built dashboards that don't answer the question they're actually asking, or learn just enough SQL to be dangerous. None of these are good options.

This guide covers how product managers can get direct access to the metrics they need from their product database—without writing SQL and without needing an engineer every time.

Why Product Data Lives in the Database, Not Your Analytics Tool

Most product teams use tools like Mixpanel, Amplitude, or Google Analytics for event-level tracking. These are great for funnel analysis on instrumented events. But they don't have the full picture.

Your database contains the ground truth:

Exact user records, with all their attributes and account history

Subscription states, plan changes, and billing events

Feature usage data that wasn't instrumented as an analytics event

Support tickets, onboarding steps, and custom fields your product team set up

The relationship between users and accounts, teams, or organizations

When you want to know "how many enterprise accounts have fewer than 3 users active this month?" — that's a database question, not a Mixpanel question. Your analytics tool doesn't have the account-level subscription data. Your database does.

The Typical PM Data Workflow (and Why It's Broken)

The standard workflow at most companies goes like this:

PM identifies a metric they need

PM writes a Jira ticket or sends a Slack message to engineering

Engineer eventually picks it up, writes a query

PM reviews the result, realizes it's slightly off ("I meant monthly active, not weekly")

Engineer revises, sends another result

PM has their number, 3-5 days after needing it

This process is fine for one-off analyses. It breaks down when you need to:

Monitor a metric regularly (e.g., daily active users on a new feature)

Explore data iteratively (each answer generates three more questions)

Get numbers fast for a meeting happening in two hours

Engineers aren't the bottleneck because they're slow—they're the bottleneck because they have a job to do, and "run a quick query for the PM" is low on the priority stack compared to shipping features.

What Natural Language Database Access Looks Like in Practice

Tools like AI for Database let you connect your product database and ask questions in plain English. The tool translates your question into SQL, runs it, and returns the result as a table or chart.

Here's what that looks like for a few common PM workflows:

Retention analysis: "What percentage of users who signed up in January are still active today?"

Behind the scenes, this becomes a query that finds users with created_at in January, then checks their last_active_at or session records against the current date. You get a percentage back in seconds.

Feature adoption: "How many users have used the export feature at least once in the last 30 days?"

This queries your events or feature_usage table for feature_name = 'export' within the date range, distinct user count. No SQL required from you.

Activation funnel: "Of users who signed up last month, how many completed onboarding step 3?"

This typically requires a JOIN between your users table and an onboarding_events table. AI for Database handles the JOIN automatically based on the foreign key relationship in your schema.

The actual SQL for that last one might look like:

SELECT
  COUNT(DISTINCT u.id) AS total_signups,
  COUNT(DISTINCT o.user_id) AS completed_step_3,
  ROUND(
    100.0 * COUNT(DISTINCT o.user_id) / COUNT(DISTINCT u.id),
    1
  ) AS completion_rate
FROM users u
LEFT JOIN onboarding_events o
  ON u.id = o.user_id
  AND o.step = 3
WHERE u.created_at >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')
  AND u.created_at < DATE_TRUNC('month', CURRENT_DATE);

You didn't have to write that. You asked a question in English and got a completion percentage back.

Building a PM Dashboard That Refreshes Itself

One of the most useful features for product managers isn't a one-off query — it's a dashboard that stays current without anyone maintaining it.

Here's a realistic PM metrics dashboard using AI for Database:

Daily active users (DAU) — Users with at least one session in the last 24 hours

7-day feature adoption — Percentage of active users who used Feature X

Trial-to-paid conversion this month — Count of accounts that upgraded from trial

Onboarding completion rate — Percentage of new signups who hit the activation milestone

Churn at-risk accounts — Accounts that haven't been active in 14+ days but are still paid

Each of these starts as a plain-English question. AI for Database turns it into a saved query on your dashboard. You set it to refresh daily (or hourly, if the metric is time-sensitive), and every morning when you open your laptop, the numbers are current.

No CSV exports. No pinging an engineer. No wondering if the number is from yesterday or last week.

Common Product Metrics and How to Ask for Them

Here are specific questions you can ask AI for Database to get common PM metrics, assuming a fairly standard SaaS database schema:

Daily/Weekly/Monthly Active Users:

"How many unique users had at least one session in the last 7 days?"

"What is the DAU/MAU ratio for this month?"

Feature Engagement:

"Which 5 features have the highest number of unique users this month?"

"What is the 30-day retention rate for users who used the collaboration feature in their first week?"

Funnel Metrics:

"Of users who signed up this quarter, how many completed each step of the onboarding flow?"

"What is the average time from signup to first meaningful action?"

Subscription and Revenue:

"How many accounts upgraded from free to paid in the last 30 days?"

"What is the average number of users per paid account?"

"Which plan has the highest average number of sessions per user?"

Churn and Health:

"How many paid accounts have had zero sessions in the last 14 days?"

"What percentage of churned accounts last month had never completed onboarding?"

These are the kinds of questions that previously required an engineering ticket. With a natural language interface to your database, they take seconds.

Working With Imperfect Data

Real product databases aren't textbook-clean. Here are a few practical things to know when using natural language queries against a production database:

Column names matter. If your sessions table has a column called ts instead of created_at, tell the AI what that column represents when you ask your first question: "our sessions table has a column called ts which is the session timestamp." After that, it'll use the right column.

Define your activation metric explicitly. "Active user" means different things in different products. When you first set up AI for Database, define it: "an active user is someone who has at least one session row in the past 30 days." You can store this definition as a saved context so every query about active users uses the same definition.

Start with questions you can verify. Before relying on a metric in a presentation, check it against a number you already know. If you know you had approximately 240 paid accounts last month, ask for the paid account count and see if it matches. Building trust in the tool with known quantities helps you know when to rely on it for unknowns.

Use the SQL view for important numbers. AI for Database shows you the generated SQL for every query. For a number you're presenting to leadership, spend 10 seconds looking at the WHERE clause to confirm the date range is what you intended.

What You Can Do Today Without Engineering Support

To give you a concrete picture of what's possible, here's what a PM can set up independently in an afternoon:

Connect your database — PostgreSQL, MySQL, MongoDB, Supabase, and others are supported. This is usually a 5-minute setup with your database credentials.

Ask your first 10 questions — Start with things you already know the answer to, so you can verify the tool is querying correctly.

Save the queries that matter — Turn your most useful questions into saved queries on a dashboard.

Set a refresh schedule — Pick daily or weekly for each metric depending on how often it changes.

Share with your team — Your engineering manager and CEO can see the same live numbers without asking you to pull them.

The whole thing can be done without writing a single line of SQL and without creating a single Jira ticket.

Getting Your Team to Actually Use the Data

The biggest barrier to data-driven product decisions isn't technical—it's habitual. Teams that wait for engineering to pull data develop a habit of making decisions without data, because asking costs too much friction.

Removing that friction changes behavior. When you can answer "how many users tried this feature" in 30 seconds, you start asking it before making decisions instead of after. That's the practical shift that matters.

Try AI for Database free at aifordatabase.com and connect your first database in under five minutes.

Product Analytics Without SQL: A Practical Guide for Product Managers