"Can you pull the numbers on X" is the data-team equivalent of a PRD that just says "make it better." Here's the version that gets you a fast, correct answer.

Section	What goes in it
The precise question	The queryable version from Lesson 4.2, not the vague original
The decision it informs	What you'll do differently depending on the answer, so the analyst can flag if the analysis won't actually support that decision
Definitions	What counts as "active," "churned," or any other term that isn't self-evident
Time window and comparison	The exact range, and what it should be compared against
Segment or filter	Any breakdown you need (by plan, by platform, by geography)
Format	A single number, a trend over time, a table by segment. Say which.
Urgency and reason	Whether this is needed by end of day for a live decision, or can wait for the next sprint

A request built this way is frequently faster for the analyst to fulfill than a vague one, not slower, because it removes the back-and-forth clarifying questions that vague requests generate. It's the same discipline as a good API PRD's worked request and response examples: specificity up front saves everyone time later.

YOUR MOVE THIS WEEK

Take your next data request to an analyst and write it using this structure before you send it. Ask them, afterward, whether it was clearer or faster to work from than a typical request. The feedback loop on this is usually immediate and usually positive.

SQL for Product Managers

Module 1Why SQL Is a PM Skill

Module 2Core SQL Every PM Must Know

Module 3Building Real Product Analysis

Module 4Working With Data Like a PM, Not an Analyst

Module 5Advanced Concepts and Working Cross-Functionally

Module 6Write and Run a Real Product Metrics Query Set

Module 725 SQL and Data Interview Questions for Product Managers

Writing a Data Request an Analyst Can Actually Use