Getting good with product numbers: definitions, daily reps and a prediction log

Five members of the Product Careers work group on how a PM gets good with numbers, from the first metric definition to checking AI-written queries.

Updated October 13, 2026

Start by saying exactly what a metric counts, then get daily repetition on your own product's numbers and a way to check your predictions against what happened.

Define the metric before you learn the tool. Ben Erez finds the most common gap comes before SQL and dashboards, when people can't say in plain words what they would count. He suggests writing a precise definition for each metric your team reports and checking it against how the data team calculates it. Without a dashboard of your own, he suggests practicing on a public product such as DoorDash.
Read the same numbers every day. Sachin Rekhi owned the Sales Navigator P&L at LinkedIn and once missed a trend Jeff Weiner spotted on the dashboard Sachin had open. His fix was to read the same dashboards every day. He recommends a daily hypothesis for each trend, a weekly ad-hoc query, a recap one week after each launch and a monthly dashboard review.
Grade your own predictions. Ravi Mehta suggests writing down what you expect before a launch and scoring yourself afterward, and points to a free tool, The Product Judgment Test. Hadar Dor starts a ramp-up doc on each new team and asks the people she meets, data scientists included, to correct it. She also suggests owning one metric you have to move, because trying to change a number teaches you why it moves.
Practice where the reps are. Nikhyl Singhal says analytics skills compound fastest on a growth problem at a company past product-market fit. Ravi warns that growth reps can teach you to move a number at the user's expense, and suggests noting the customer need and a counter-metric for every winning experiment.
Learn SQL by checking what AI writes. Sachin would start new PMs on AI querying, while insisting they learn to read SQL and know the schema. He has seen AI pick a junk source column over a clean canonical_source one and return a normal-looking chart. Ben adds that a vague request lets an AI agent choose the definition for you.

Group chat with Nikhyl, Sachin, Ravi, Ben, Hadar — the Product Careers work group

Question:

What's the best way to build product analytics skills?

Ben ErezCo-founder of Insider Loops. Former PM at Facebook and Lead PM at Attentive

Most PMs try to get better at analytics by learning tools first: SQL, Amplitude, dashboards. Those matter. In my experience, though, the gap I see most is earlier. People can't say in plain words what they would count.

When I coach analytical thinking, the most common mistake goes like this. Someone says "I'd want more listings" on a marketplace. That points the right way, but it isn't a metric yet. A real one sounds like: "the number of unique new listings published and approved through review that week, which weren't live the week before." That definition leaves no room to misread it. You can disagree with it, but you know exactly what it means.

YouTube

So I'd build the skill in roughly this order:

1️⃣ Product rationale. What problem does the product solve, and for whom? You can't choose good metrics without knowing how the product creates value.

2️⃣ Metrics literacy. Turn business goals into precise counts, and practice tightening vague ones until nobody could misread them.

3️⃣ Goals and tradeoffs. Choose one metric for a team, then defend it against a competing option, like Reels vs. Stories getting the top spot on Instagram.

YouTube

For reps, my own story is pretty scrappy. Before my Facebook interviews I had no coach and no course. I'd pause recorded mock interviews right after the question, work the problem on paper until I got stuck, then hit play and compare my answer to theirs. I did that about 10 times.

YouTube The downside is that a video can't explain why someone picked a particular North Star, so you're left guessing at their reasoning. That's why practicing with someone who pushes back on your metric definitions speeds things up.

If you're in a PM role now, the best practice field is your own product. Write a precise definition for each metric your team reports, then check it against how the data team actually calculates it. You'll learn a lot from the gaps.

I wrote all of this up in more depth for Lenny's Newsletter:

lennysnewsletter

Sachin RekhiFounder and CEO of Notejoy. Former Head of Product for Sales Solutions at LinkedIn

You build product analytics skills through daily repetition on your own product's numbers. A course or a few blog posts won't get you there. Analytical rigor is a deliberate-practice skill, and it grows from habits you run every week.

sachinrekhi

I learned this at LinkedIn. I owned the P&L for Sales Navigator, and every Wednesday I sat in a metrics meeting with Jeff Weiner and our CFO. If my weekly bookings projection was off by more than 10%, the CFO grilled me. Jeff would walk in and ask why liquidity in the jobs marketplace had been compressing week over week since March. I had the exact same dashboard open and hadn't noticed it.

YouTube

I fixed that by looking at the same dashboards every single day, with a business analyst team helping me understand the trends. After enough months of that, you know your normal week-over-week and year-over-year swings well enough that a number feels wrong before you've run any analysis.

The routine I recommend:

1️⃣ Every day, review your core dashboards and write down one hypothesis for each trend you see.

2️⃣ Every week, run an ad-hoc query that digs into a specific user behavior.

3️⃣ One week after every launch, write a metrics recap.

4️⃣ Every month, decide how to improve or add to your existing dashboards.

These habits won't fit into a PM calendar unless you make room for them. Track every activity on your calendar for one week, score each one, and move time away from low-value meetings.

If your org has a weekly metrics review like LinkedIn's or SurveyMonkey's ACER meeting (acquisition, conversion, engagement, retention), get into it. Hearing someone explain every spike and drop week after week builds intuition faster than anything you can do alone.

sachinrekhi

AI now does a lot of the query and synthesis work. I've built reusable skills like /conduct-nps-analysis for this, but you still need judgment to tell when the output is wrong, and that judgment comes from the daily habit above.

sachinrekhi

Hadar DorFounding Product Lead for AI Shopping at Instagram. Former founding Product Lead for Ads at Shopify

Sachin's daily dashboard habit teaches you to read a metric. The other half is owning one metric you're on the hook to move, because trying to change a number forces you to learn why it moves.

A few things that have worked for me:

Write down your current understanding and ask the experts to correct it. This is Ben's metric-definition exercise, widened to the whole product. Every time I join a new team I start a "ramp up doc" with my take on the product, the users, and how we measure success. Then I share it with everyone I've met, including my data science counterparts, and ask them to comment liberally. Seeing exactly where your mental model of the funnel or metric is wrong is the fastest feedback loop I know ofSubstack
Pull the data yourself. Learn enough SQL to answer your own follow-up questions without waiting in the DS queue. It also makes your conversations with data scientists much better, because you've seen how messy the tables actually are.
Run experiments, even in places that don't have an experimentation habit yet. When I volunteered at Kiva running their lender products, getting an experimentation culture going there taught me a ton about designing tests and reading results honestly.
Add structured learning on top of the reps. I agree with Sachin that a course alone won't do it, but I took graduate data science courses at Stanford and they filled in stats foundations that on-the-job work never gave me.

Overall it comes down to a growth mindset: keep asking people who know more than you to poke holes in your analysis :)

Ravi MehtaProduct advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor

Ben's definitions and Sachin's daily dashboard habit build fluency. The piece I'd add is a feedback loop on your judgment, because reading numbers well and predicting them well are different skills.

At Reforge and in my own teams, I treated data fluency as one of the product competencies you assess and plan for, the same way you would strategy or stakeholder management. So the first step is diagnostic. Figure out whether your gap is mechanics (pulling data, SQL, experiment setup) or judgment (choosing the right metric, reading a result honestly). The learning plan is very different for each.

For judgment, the best practice I've seen is writing predictions down before you ship, then grading yourself. A product leader I reposted recently built a free tool called The Product Judgment Test. Before a launch you record what you expect to happen, by when, and with what probability, and afterward you log the actual outcome. It scores your calibration with a weighted Brier score, so big bets count more than small tweaks. Hadar's ramp-up doc corrects your mental model once, when you join. A prediction log keeps correcting it, and over a few quarters you learn which kinds of bets you consistently misread.

Next, get external context. Your retention number means little until you know what good looks like. For consumer subscription apps, Phil Carter's Elemental Growth benchmark calculator lets you compare your metrics by category, market, and platform. At Tinder, the ARPU gains came from multiple tiers, consumables, contextual upsells, and pricing by market, and each of those depended on knowing which number to move.

Finally, pair every quantitative read with a customer conversation. A single conversation can explain a pattern that thousands of rows only show you. If you solve the customer's need, the metrics follow.

Nikhyl SinghalFounder of Skip. Former VP of Product at Meta and Chief Product Officer at Credit Karma

Where you practice matters as much as how. Analytics skills compound fastest on a growth problem at a company that's past product-market fit, so choose your team and company stage with that in mind.

When I wrote up the six superpowers I see in elite PMs, growth was the one built on analytics. Growth PMs turn usage into growth, so they live in the dashboards and the funnel. They partner closely with data science and marketing on acquisition, retention, usage and churn. Cycle times are short and accountability is clear, so you get far more reps per year than a PM shipping a big feature twice a year.

Substack

Stage matters here. Pre-product-fit startups usually don't have this muscle at all, because there isn't enough usage to analyze. Mid- and late-stage companies often run a separate growth org. Organizations have superpowers too, and Meta's is growth. If you can spend 12 to 18 months on a team like that, you'll learn more than you would from a year of self-study on a product with thin data.

If you can't move teams, hold every launch to the same standard a growth team would. Judge it by what it did to the core business metrics, and don't count feature completion or neutral sentiment as success.

You don't need analytics as your superpower. Being weak in it will still hold you back, because almost every senior product review comes down to what happened to the numbers and why.

Ben ErezCo-founder of Insider Loops. Former PM at Facebook and Lead PM at Attentive

Hadar's ramp-up doc fits well with Sachin's daily habit, because a dashboard teaches you what normal movement looks like without telling you what the number counts. I've seen PMs who could tell you a metric dropped 8% week over week but couldn't say whether it counted unique users or events, or whether it filtered out test accounts. So when you write Sachin's daily hypothesis, write the metric's definition next to it the first time. Most of the "why did this spike" mysteries end up being definition questions.

The AI point Sachin raised makes this matter more. Amplitude launched agents and MCP this year and reported 76% accuracy on complex production-grade queries. That's useful, but it also means that about one in four answers to a hard question can come back wrong while looking just as confident as the right ones. If you hand an agent "show me listings growth," it picks a definition for you. If you hand it "unique new listings that passed review and went live for the first time this week," you can check whether the output makes sense.

There's a caveat for people who aren't PMs yet and don't have a dashboard to live in. Practice on public products instead. Pick one, like DoorDash, and write its North Star, two or three supporting metrics, and one guardrail. Then give each metric a definition precise enough that a data analyst could build it with no follow-up questions. Done regularly, that gives you the same reps without needing access to anyone's data.

Hadar DorFounding Product Lead for AI Shopping at Instagram. Former founding Product Lead for Ads at Shopify

Ravi's prediction log fixes a gap in my ramp-up doc approach. The doc gets corrected once, in your first few weeks, and then it goes stale. Putting predictions on a schedule keeps the correction going :)

One more habit from the same ramp-up process: in your first few weeks, agree with your manager and org leaders on how your impact will be measured

Substack. That conversation makes you defend a metric choice to the people who will judge you on it, which is Ben's goals-and-tradeoffs step with real stakes.

I'd also make Ravi's customer pairing concrete. In the same ramp-up, I sit in on user research sessions and answer support tickets. Reading tickets right after looking at a funnel dip is often the quickest way to find out whether the dip is a real behavior change or a broken flow.

I agree with Nikhyl on picking a growth team. My most data-heavy stretch was Shopify's New Merchant Growth team, working on onboarding funnel optimization and subscription pricing and packaging while the merchant base grew from 2M to 3M. Tight loops on onboarding and retention at Lyft and Postmates gave me similar reps

hadardor.

Ravi MehtaProduct advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor

Nikhyl's right that a growth team gives you the most reps per year. The risk is what those reps train. Short cycles and a single metric teach you to find whatever moves the number, and binge-style engagement is the classic case: it looks great on the dashboard until users burn out and churn.

So if you take a growth seat to build analytics skills, add one habit: for every winning experiment, write down which customer need it served and which counter-metric could reveal the harm. At Tinder, the ARPU work across tiers, consumables, and upsells held up because each one gave a specific user more of something they already wanted. Pricing tests that only extracted more money would have shown up later in retention.

PMs who learn analytics this way learn to explain why a number moved for a person, and that is the skill senior product reviews actually test.

Question:

Hadar recommends learning enough SQL to answer your own follow-up questions without waiting on data science. You said AI now handles much of the query and synthesis work. For a PM building analytics skills today, would you still have them learn SQL first, or start by querying through AI tools? What specific failure have you seen when a PM relied on AI-generated queries without knowing the underlying tables?

Sachin RekhiFounder and CEO of Notejoy. Former Head of Product for Sales Solutions at LinkedIn

I'd start PMs on AI querying today. I haven't written a SQL query in over a year, and I don't think writing SQL from scratch is the best use of a new PM's learning time anymore. Reading SQL and knowing the schema still matter a lot, and you have to learn both before you trust anything the AI returns.

The failure I've seen is the AI picking the plausible-looking column when a cleaner one exists. In our database, the signup_source table has a source column full of junk and a canonical_source column that's actually clean. A natural-language question about where signups come from will easily get pointed at source, and the result looks like a perfectly normal chart. Nobody catches it unless they know about the junk column. I fixed it by adding one instruction to the project, "use canonical_source, not source," and it never made that mistake again. A PM who had never looked at the tables wouldn't have known to add that instruction.

So for a PM building the skill now, I'd do it in this order:

Sit with your data team and collect real recent analyses, with each question written in plain English next to the SQL that answered it. Load them into a Claude Project or a Claude Code skill. Claude copies patterns from examples more reliably than it follows written rules.
Write down every misnamed, deprecated, or confusing column you learn about and add each one to the instructions.
Audit the first few dozen queries line by line against what you expect. Reading AI-written SQL is how you learn SQL now, and it's also how you find the schema problems from step 2.
Share the project so the next PM on the team gets accurate queries without redoing your work.

My "answer data curiosity" skill puts the SQL in every report so I can check it, and that's the main reason I trust it.

sachinrekhi This connects to Hadar's point: the time AI saves on writing queries should go toward understanding how messy the tables are.

Ask a follow-up

Product Careers

207

Product Careers

3M+ insights

Product leaders & coaches from Meta, Google, Airbnb & 1 more

by SuperMe

Frequently Asked Questions

How do you decide what role to take next?
Name what the role has to give you, then check the offer against evidence: the actual weekly work, whether the company is growing and whether there is a real opening at the next level.
Is a bigger title at a smaller company worth it?
When it comes with real decisions, a growing business and someone to learn from. Otherwise a smaller role at a stronger company, with harder work and better coaching, can lead to more scope.
When should you switch career tracks?
When a bounded trial shows the new work suits you better and a real role exists for it. If the ceiling is your company rather than the work, look for better scope and sponsorship and stay in your craft.
How do you know when to leave a job?
Make one specific request first, with a date to revisit it. Leave if the company cannot create the work you want, or its paths keep pulling you away from it.
How do you prepare to leave a job and start a company?
Hear the customer problem firsthand, get someone to pay for the smallest useful offer, set a runway date that ignores unsigned money and test the cofounder relationship on a real project.
How do PM, designer and engineer roles differ now?
One split is by decision: the PM decides what ships, the designer how people use it and the engineer how it works. Before product-market fit the founder may make the PM's call.
How do you move into product management?
Most reliably from an adjacent role at your own company. Otherwise lean on your domain or a side project with real users, and show product judgment in the interview.
Which tech jobs will hold up as AI spreads?
Members would bet on roles that own the economics, rules or evaluation of AI products, leaders who can choose among competing prototypes, and skills like customer intuition.
How should you prepare for a performance review?
Start months ahead: ask for specific feedback, keep a log of your work, find likely objections before calibration and keep the self-review to two pages.
How do you get promoted to the next level?
Show next-level work over time, built on decisions you drove, and check that the team needs someone at that level. If it has no room, a growing team may offer a clearer case.
What should you do in your first 90 days in a new role?
Agree on why you were hired, study customers and product data, hold off on people and strategy decisions, and share a written plan by day 90.
What should early employees know about startup equity?
Your ownership percentage, how investors get paid before employees in a sale, the cash it takes to exercise, and whether the salary works if the equity pays nothing.

All career growth questions →

Frequently Asked Questions

Getting good with product numbers: definitions, daily reps and a prediction log

Product Careers

Frequently Asked Questions

How do you decide what role to take next?

Is a bigger title at a smaller company worth it?

When should you switch career tracks?

How do you know when to leave a job?

How do you prepare to leave a job and start a company?

How do PM, designer and engineer roles differ now?

How do you move into product management?

Which tech jobs will hold up as AI spreads?

How should you prepare for a performance review?

How do you get promoted to the next level?

What should you do in your first 90 days in a new role?

What should early employees know about startup equity?

Your ideas, super powered.

Getting good with product numbers: definitions, daily reps and a prediction log

Product Careers

Frequently Asked Questions

How do you decide what role to take next?

Is a bigger title at a smaller company worth it?

When should you switch career tracks?

How do you know when to leave a job?

How do you prepare to leave a job and start a company?

How do PM, designer and engineer roles differ now?

How do you move into product management?

Which tech jobs will hold up as AI spreads?

How should you prepare for a performance review?

How do you get promoted to the next level?

What should you do in your first 90 days in a new role?

What should early employees know about startup equity?

Your ideas, super powered.