How to Answer Estimation Questions as a PM (In English)

The three things being scored

• Structure — do you break the problem into logical components, or do you guess at the whole thing at once?
• Quantitative reasoning — can you build a chain of estimates that multiplies or adds to a sensible result?
• Communication — can an interviewer follow your logic in real time, in English, without having to ask 'what do you mean?'

Step 1 — Clarify the question (say this out loud)

• Repeat the question back before doing anything else: 'Just to make sure I understood — you're asking me to estimate Gmail's annual ad revenue in the US, is that right?'
• Then surface the ambiguities: 'When you say revenue, do you mean gross revenue or profit? And are we including business accounts on Google Workspace, or just personal Gmail users?'
• This step is not stalling — it is the first signal that you think carefully before acting. For non-native speakers, it also ensures you actually heard the question correctly, which matters more than it might seem.

Step 2 — Catalogue what you know (and what you need)

• Say aloud what data you have and what you are missing: 'I know the US population is roughly 330 million. I don't know the exact Gmail market share, but I can estimate it.'
• You can ask your interviewer for one or two facts — but choose carefully. If it is something most candidates would know (like approximate US population), asking for it signals a gap. If it is genuinely specialised (like a specific click-through rate), asking is fine.
• A safe way to ask: 'Could you give me the average cost-per-click for a Gmail ad, or would you prefer I estimate that myself?' If the interviewer says 'what do you think?', that is a signal to stop asking and start estimating.

Step 3 — Build your equation (the most important step)

• State the equation before you start calculating: 'My approach will be: number of Gmail users in the US, multiplied by average annual ad clicks per user, multiplied by average revenue per click.'
• Consider two or three possible equations before committing. Pick the one whose components you can actually estimate — not the most elegant one in theory.
• For Gmail revenue, an alternative equation is: 'Google's total US revenue, multiplied by the share that comes from embedded ads, multiplied by Gmail's share of that.' Both are valid. Choose the path you can walk.

Step 4 — Name the edge cases

• Pause and say: 'Before I calculate, let me think about what my equation might be missing.'
• For a pizza question: 'I should consider whether college towns skew the density of pizza places upward.' For Gmail: 'I haven't accounted for users who have Gmail accounts but rarely open them — that would reduce the click rate.'
• Naming a flaw before the interviewer does is a strength, not a weakness. It shows you are detail-oriented and intellectually honest.

Step 5 — Break each component into a sub-equation

• Do not try to estimate 'number of Gmail users' in one leap. Build it: 'US population is 330 million. About 75% have email. Of email users, I'd estimate Gmail has roughly 40% market share. That gives me about 100 million Gmail users.'
• Keep each component's calculation physically separate — on the whiteboard, on paper, or stated clearly as a distinct block in your spoken answer.
• If you get stuck on one component, say so and move on: 'I'm not confident in this number, so I'll flag it as a weak point and continue — I'll come back to sanity-check it at the end.'

Step 6 — State your assumptions explicitly

• Every number you estimate is an assumption. Name it: 'I'm assuming the average Gmail user sees about 5 ads per day and clicks on roughly 1% of them — so about 18 clicks per year.'
• Round to clean numbers on purpose: 'I'll use 300 million for the US population rather than 331 million — it makes the arithmetic cleaner and the precision isn't meaningful here.'
• Your reasoning for each assumption matters more than the number itself. 'I'm using 40% Gmail market share because I recall it being the leading email client globally, and I'd expect similar penetration in the US' is far stronger than just saying '40%'.

Step 7 — Do the math, out loud, with round numbers

• Narrate the arithmetic as you go: '100 million users, times 18 clicks per year, gives me 1.8 billion clicks. At roughly $0.10 per click, that's $180 million in annual revenue.'
• Use round numbers deliberately — this is not laziness, it is correct technique. You are estimating, not auditing.
• If you make an arithmetic error mid-calculation, correct it calmly: 'Actually, let me redo that — 100 million times 18 is 1.8 billion, not 18 billion. My mistake.' Catching your own errors is a positive signal.

Step 8 — Sanity-check your answer

• After giving the number, immediately check it against something you know: 'That gives me $180 million. Google's total annual revenue is in the hundreds of billions, so Gmail's ad revenue being a small fraction of that seems plausible. I'm comfortable with this estimate.'
• If the number looks wrong, say so: 'That seems high to me — $5 billion would mean Gmail is generating $16 per US person per year, which feels off. Let me check my click-through assumption.'
• Catching your own implausible result and correcting it is one of the highest-scoring moves in an estimation interview. It shows the intellectual honesty that PMs need when they are working with real product data.

Model answer — Associate PM level

• 'Before I calculate, let me make sure I understand the question. You're asking about a typical weekday — not a weekend or a public holiday. And you mean rides that complete, not just requests, right?'
• 'My approach: I'll estimate the number of people in London who use Uber regularly, then estimate how often they ride on a weekday. London's population is about 9 million. I'd guess around 20% are regular Uber users — that's 1.8 million people. Of those, maybe 15% take an Uber on any given weekday, which gives me about 270,000 rides.'
• 'One thing I haven't accounted for is business accounts — corporate Uber usage could add a significant number of rides. I'd probably add 20% to account for that, bringing my estimate to around 320,000 rides per weekday.'
• 'Sanity check: London has a population similar to New York City. Reports I've seen suggest Uber does a few hundred thousand rides per day in major cities, so 300,000 to 350,000 feels like the right ballpark for London.'

Model answer — Mid-level PM

• 'I'll approach this in two ways and see if they converge. First, a top-down approach: Spotify's total revenue is roughly $14 billion annually. Their advertising revenue is about 10–12% of that — call it $1.4 billion. Podcast advertising is a growing but still minority share of that; I'd estimate 20–25%, so around $300 million.'
• 'Second, a bottom-up check: Spotify has about 100 million podcast listeners globally. Advertisers typically pay $20 to $30 per thousand listens for mid-roll podcast ads — call it $25 CPM. If the average listener hears 2 hours of podcasts per week, and ads run at roughly 3 per hour, that's 6 ad impressions per week per user. Over a year: 100 million users times 6 impressions times 52 weeks is 31 billion impressions. At $25 per thousand, that's $775 million.'
• 'The two approaches give me $300 million and $775 million — a meaningful gap. The difference is probably because not all podcast listeners are monetised equally, and Spotify doesn't sell ads against all content. I'd weight the top-down estimate more heavily and land at around $350–400 million, with the caveat that this is growing fast and the number could be significantly higher now.'
• 'The assumption I'm least confident about is the CPM rate — podcast ad rates vary enormously by genre and audience size. That's the variable I'd want to verify first if this were a real business decision.'

Model answer — Senior PM

• 'I want to frame this as an incremental revenue question — what revenue would we gain that we would not have had without BNPL, rather than total revenue through the feature.'
• 'There are three levers: conversion lift, basket size increase, and new user acquisition. Let me take each in turn.'
• 'On conversion: BNPL typically lifts checkout conversion by 20–30% for high-ticket items. If 10% of our 50 million users are in the high-ticket segment — that's 5 million users — and their current conversion rate is 30%, a 25% lift means an additional 375,000 completed purchases. At an average order value of $150, that's $56 million in incremental GMV. If our take rate is 15%, that's about $8.4 million in incremental revenue from conversion alone.'
• 'On basket size: BNPL users tend to spend 30–40% more per order because the payment feels smaller. Applying that to the same 5 million high-ticket users who already convert — 1.5 million purchases at $150 average, with a 35% basket increase, is an extra $53 per order, or $79 million in additional GMV. At 15% take rate, that's $12 million.'
• 'On new users: harder to estimate without acquisition cost data. I'll note it as a positive externality but exclude it from the core calculation to keep the estimate conservative.'
• 'Combined: roughly $20 million in incremental annual revenue. I'd want to stress-test the take-rate assumption and the basket-size lift — both of those are industry averages and our platform's category mix could make them quite different. I'd also want to net out the BNPL provider's fee, which is typically 2–6% of transaction value and would reduce that number meaningfully.'

The four specific failure patterns interviewers see most often

• Jumping to a number — skipping the equation and stating a guess, then defending it when challenged instead of acknowledging the uncertainty.
• Over-asking for facts — requesting so many inputs from the interviewer that the candidate's own reasoning never appears. If the interviewer has to supply every variable, there is nothing left to evaluate.
• Hiding assumptions — doing mental arithmetic and announcing a result without explaining how you got there. The interviewer cannot assess reasoning they cannot see.
• Refusing to commit — giving a range of '$100 million to $10 billion' and presenting that as the answer. Ranges are fine as a confidence interval around a specific estimate; they are not a substitute for one.

Opening the problem

• 'Just to confirm I understood the question — you're asking me to estimate [X], right?'
• 'Before I start calculating, let me make sure I know what we're measuring. Does [term] mean [interpretation A] or [interpretation B]?'
• 'I want to flag a few things that are ambiguous here — specifically [X] and [Y]. Should I make assumptions on those, or can you give me those values?'

Announcing your approach

• 'My approach will be to break this into three components: [A], [B], and [C], then multiply them together.'
• 'I can see two ways to approach this. I'll go with [approach] because I'm more confident in the inputs I'd need for that path.'
• 'Let me build an equation first, then work through each part separately.'

Stating assumptions (the most important language skill in this question type)

• 'I'm going to assume [X] — my reasoning is [brief explanation].'
• 'I'll use [number] here. That's an estimate — I'm basing it on [anchor].'
• 'I don't have a precise figure for this, so I'll estimate [X] and flag it as a weak point in my calculation.'
• 'I'm rounding to [number] to keep the arithmetic clean — the precision isn't meaningful at this stage.'

Narrating the arithmetic

• 'So that gives me [A] times [B], which is [result].'
• 'Let me keep these calculations separate so I don't lose track.'
• 'I'll round that to [number] — it's close enough for our purposes.'
• 'Actually, let me recalculate that — I think I made an arithmetic error. [X] times [Y] is [correct result], not [wrong result].'

The sanity check

• 'My final estimate is [number]. Let me check whether that makes sense.'
• 'That would imply [derived fact]. Does that feel reasonable?'
• 'That number seems [high/low] to me. Let me check where the error might be — it's probably in my assumption about [X].'
• 'I'm comfortable with this as a ballpark. The assumption I'm least confident in is [X], which I'd want to verify first if this were a real decision.'