I am a product manager, not an analyst. I can read SQL well enough to know when a result looks wrong, and I know exactly what question I want answered. What I could never do reliably was write the query from scratch — anything with a window function or a self-join sent me straight to our data engineer, Priya, who would sigh politely and write it in ninety seconds while I watched. The query took her two minutes. Explaining the query to me took fifteen. I was the bottleneck, and I was the one creating the bottleneck, which is the most annoying kind of bottleneck to be.
The breaking point was a Tuesday in March. I needed one number for a stakeholder call in twenty minutes: how many users finished onboarding in the last 30 days, broken down by acquisition channel, who had NOT yet upgraded to a paid plan. Priya was heads-down on a pipeline migration with her headphones on and the particular hunched posture that means do not talk to me. I did not want to be the person who tapped her shoulder for a COUNT. So for the first time, I decided to just try to get the number myself.
The thing I actually did instead
I keep our three core tables — users, events, subscriptions — pasted in a note as CREATE TABLE statements, mostly so I do not have to look up column names every time. I dropped that whole block into the schema field, set the dialect to PostgreSQL 15, and typed my question in plain English using the Write a SQL Query from a Plain-English Business Question prompt. Claude Opus 4.8 came back with a clean CTE-based query that joined users to events filtered on the onboarding_complete event type, left-joined subscriptions to isolate the people who had NOT converted, and grouped the result by acquisition_channel. I copied it into our query tool, hit run, and it returned exactly the right shape on the first try. I had my number with twelve minutes to spare, and I spent those twelve minutes being smug.
Why the explanation block is the real product
Here is the part I did not expect to matter as much as it does. The prompt returns a plain-English explanation of the query alongside the SQL, and that explanation is how I catch my own mistakes before they become wrong slides. I read what the query says it does, compare it to what I actually wanted, and any mismatch jumps out immediately without me having to parse the joins. The very first time I ran it, I had accidentally asked for 'upgraded users' when I meant 'NOT upgraded.' The explanation said, in plain words, 'returns users who currently have an active subscription.' I read that, went 'wait, that's backwards,' and fixed my question — not the SQL. The model did exactly what I asked; I had asked for the wrong thing, and the explanation is what surfaced it.
That is a subtle but huge shift. I am no longer trusting code I cannot fully read. I am trusting a prose description I can absolutely read, and using it to verify intent. For a non-engineer running queries against production data, that verification step is the difference between confidence and recklessness.
- The explanation lets me verify intent without reading the SQL line by line — I check the prose against my goal, not the joins against a mental model I do not have.
- The index note once flagged that I was filtering on an unindexed timestamp column; I mentioned it to Priya and she added the index in five minutes flat.
- The 'state your assumption' rule caught a 'last month' ambiguity — previous calendar month versus rolling 30 days — before it shipped a quietly-wrong number to leadership.
- It names a missing column instead of inventing one, which is the exact failure mode that used to give me confidently-wrong results from other tools.
The number that actually changed
I went from roughly three ad-hoc query requests a week to about one. And the one that remains is genuinely hard — a cohort retention curve, a funnel with three weird edge cases, the stuff Priya should be doing anyway because it requires actual judgment about our data model. She told me last month, unprompted, that she wished the whole product team used this, because she got her afternoons back and stopped context-switching every twenty minutes. We both came out ahead, which almost never happens when one team automates part of another team's job.
When I want to learn a pattern instead of just shipping a number, I pair it with my Explain a Slow Query and Suggest an Index Strategy prompt and read both explanations side by side — one tells me what the query does, the other tells me why it is fast or slow. If you are the person who keeps tapping someone's shoulder for SQL, this is the fix. Grab the Write a SQL Query from a Plain-English Business Question prompt on Prompt Dock, paste in your own schema, and ask it the question you were about to file a ticket for. Worst case, you read the explanation and learn something. Best case, you never interrupt your data engineer for a COUNT again.