How Anthropic's Product Managers Use Claude

1. The data bottleneck that slows every product team

Product managers live and die by data. Is the new onboarding funnel converting better than the old one? Which customer segment has the highest retention? Did that pricing experiment lift revenue or cannibalize free-tier usage? These questions arise constantly, and the answers exist in the data warehouse — but accessing them requires writing SQL, and most PMs do not write SQL.

The traditional workaround is submitting a data request to the data science or analytics engineering team. In theory this is a clean division of labor. In practice it introduces delays of days or even weeks per question, and it changes the nature of the questions PMs ask. When every question costs a multi-day wait, you become conservative about which questions to ask. You stop exploring. You make decisions based on the data that is already in your dashboard rather than the data you would actually need to be confident. And when the answer comes back and you realize you needed a slightly different cut of the data, you submit another request and wait again.

Lisa Crofoot, a PM at Anthropic, describes this as the core problem she wanted to solve. The issue is not a lack of skill on the part of the data team — it is that the latency between question and answer is so high that it breaks the product development feedback loop. Decisions get made on instinct because waiting for data is too slow, or they get delayed waiting for data because the stakes feel too high to decide on instinct. Neither is good.

2. Self-service analytics with Claude

The breakthrough that Lisa describes is using Claude to translate plain-language product questions into SQL queries, then iterating on those queries conversationally. You do not need to know SQL to do this — you need to know your product and your data schema.

The workflow starts with giving Claude context about your database schema. This is a one-time setup: you paste the relevant table definitions, column names, and any business logic that is encoded in the data (for example, “users with plan_type = ‘pro’ who have been active in the last 30 days are our core segment”). With that context loaded, you can ask questions in plain English.

A typical session might look like this: “How many users who signed up in March completed their first meaningful action within 7 days?” Claude generates a SQL query, explains what it does, and if you have access to a SQL console you run it. If the answer raises more questions — as it usually does — you continue: “Now break that down by acquisition channel.” Or “Show me how that number changed month over month for the past year.” Each follow-up question is natural language, and each response is a new or modified query explained in plain terms.

The key insight is that understanding the output matters more than writing the query. A data engineer can write SQL fluently but might not know that the cohort you are looking at is too small to draw conclusions from, or that the metric you chose conflates two different user behaviors. Claude can flag those issues too — not just generating the query but also interpreting the results and pointing out where the analysis might be misleading.

3. Building evals with Claude’s help

One of the more surprising use cases Lisa describes is using Claude to build evaluation frameworks — a task that sounds technical but turns out to be highly suited to PM skills. Evals, short for evaluations, are test suites that measure whether an AI feature is performing well. If your product includes an AI-powered feature (a writing assistant, a summarization tool, a recommendation engine), you need a way to measure whether it is working correctly and improving over time.

The traditional way to build evals requires working with engineers: define metrics, write test cases, create a harness to run them. Lisa describes a different approach: she describes to Claude what “good” looks like for a feature in plain language — what should the AI output when a user asks X, what behaviors are wrong, what edge cases matter — and Claude helps generate a set of concrete test cases from that description.

This is an area where the PM is genuinely the expert. You know the user intent better than an engineer writing a test case from a spec. You know the edge cases that come up in user interviews. You know the tone that feels right versus the tone that feels off. Claude helps you translate that tacit product knowledge into structured test cases that engineers can actually run. The resulting eval suite is more realistic because it was designed by someone who thinks about users rather than someone who thinks about code paths.

4. Spec writing and the PM’s most time-consuming output

Product requirement documents, or PRDs, are the highest-leverage written output a PM produces — and often the most time-consuming. A good PRD needs to translate user needs, business goals, and technical constraints into a document that engineers, designers, and stakeholders can all work from. Getting from rough notes to a polished PRD typically takes a senior PM several hours of focused writing.

Lisa describes using Claude to compress this process dramatically. The raw material is already there: meeting notes, user interview transcripts, Slack threads with stakeholders, competitive analysis. The problem is synthesizing it into a structured document. Claude is exceptionally good at this synthesis task. You paste in the raw material, describe the format you want, and ask Claude to produce a first draft. The resulting document is not final — it needs your judgment, your edits, your knowledge of what is politically important to emphasize — but it is a serious first draft that cuts the time to completion by 60-70%.

More importantly, Claude can help you find gaps. After generating the draft, ask it: “What questions does this spec leave unanswered that an engineer would need to know?” or “What edge cases have I not accounted for?” These are the blind spots that cause rework later, and surfacing them at the spec stage is vastly cheaper than discovering them mid-sprint.

5. The 10x productivity lever for product teams

When you add up the compounding effects — data questions answered in minutes, PRDs drafted in an hour instead of a day, eval frameworks built without engineering support — the picture is not just “PMs do the same work faster.” It is “PMs make more decisions, better informed, earlier in the process.”

Lisa describes the most significant shift as qualitative: when the cost of asking a data question is low, you ask more questions. When you ask more questions, you build stronger conviction about what to build and why. That conviction makes you a better partner to engineers (clearer requirements), a better advocate in planning meetings (data-backed priorities), and a faster decision-maker when unexpected user feedback comes in mid-sprint.

The 10x productivity framing is appealing but incomplete. The real multiplier is not that one PM does ten PMs’ worth of work in terms of volume — it is that one PM makes decisions that are ten times better informed, and the downstream quality improvement in what gets built compounds across every subsequent product cycle.

Database: [your product's data warehouse or database name]

Key tables:
- users: one row per user. Columns: id, email, plan_type (free|pro|enterprise),
  created_at, last_active_at, acquisition_channel
- events: one row per user action. Columns: user_id, event_name, occurred_at,
  properties (JSON)
- subscriptions: one row per subscription period. Columns: user_id, started_at,
  ended_at, mrr_usd, plan_type

Business logic:
- "Active user" means last_active_at within the past 30 days
- "Core segment" is plan_type = 'pro' with mrr_usd > 50
- Churned users have ended_at < today with no active subscription row

[paste data-context.txt here]

Question: How many users who signed up in Q1 2026 completed their first
meaningful action (any event) within 7 days of signup?

Now break that down by acquisition_channel.

Show me how the 7-day activation rate changed each month over the past year.

Is the sample size large enough to draw conclusions from? Are there any
concerns with this analysis?

This returned 12,000 users but I expected around 20,000. What might explain
the discrepancy?

I'm writing a PRD for [feature name]. Here are my raw materials:

User interviews: [paste key quotes or notes]
Business goal: [1-2 sentences]
Constraints: [technical, legal, or timeline constraints]

Please draft a PRD with the following sections:
- Problem statement (2 paragraphs)
- User stories (3-5 in standard format)
- Success metrics (measurable, with baseline and target)
- Out of scope (what this feature will NOT do)
- Open questions

After the draft, list three questions this spec leaves unanswered
that an engineer would need resolved before starting implementation.