Estimation
Turn "how many" and "what does this feature cost a month" into a rounded figure: assumptions first, a check against a known number, a consequence.
On this page
An estimation round asks for a number nobody in the room knows. The classic is a count — tickets, agents, orders in a city — and the AI version is "what does this feature cost a month". Both run the same back-of-the-envelope chain the system-design course teaches, and the interviewer scores the same three habits: assumptions said before the arithmetic, hard rounding, and a check against one number you already know. The figure itself is the least scored part of the answer.
The classic count
"How many support tickets does a food-delivery app open in one city on a weekday?" The weak answers sit at two ends. One names a figure — "about 50,000" — with nothing under it to correct. The other spends four minutes on population tables and runs out of round before the multiplication ends.
The strong answer says its assumptions first, as a short list, and invites correction:
- 10 million people in the city, 1 in 10 of them ordering once a week: 1 million orders a week, about 143,000 a day, rounded to 150,000.
- 1 order in 20 raises a ticket — a late rider, a missing item, a refund.
150,000 ÷ 20 = 7,500 tickets a day. Then the check, against a number from outside the chain: at the 40 tickets a day an agent clears — the figure this course has used since jobs to be done — that is about 190 agents for one city. A floor of 190 is something you can picture. Had the chain produced 75,000 tickets, it would mean 1,900 agents for one city, and the input to re-examine would be the contact rate, the softest of the three.
Then land it, because the next question is always "so what". A drafting feature that saves one minute a reply returns 7,500 agent-minutes a day, 125 hours, about 16 eight-hour shifts. The back-of-the-envelope lesson calls this the sentence after the number: the consequence that makes the arithmetic worth doing.
The estimation chapter of McDowell and Bavaro's Cracking the PM Interview works counts of this kind, and what it drills is the habit the sheet records: the assumptions said out loud before the multiplication starts.
Round hard, toward the decision
Round every intermediate to a figure you can multiply in your head: 143,000 becomes 150,000, 1,300 tokens becomes 2,000 once a system prompt sits beside them. Round in the direction that makes the decision harder — a cost up, a saving down — so the error collects as headroom rather than a surprise. If the decision flips inside the rounding, that is the finding: "$29,000 against a $30,000 budget is inside the noise, so I would treat it as over."
Averages hide peaks, and a floor is staffed for the peak. Assume half the 7,500 tickets arrive in the three dinner hours: 1,250 an hour. An agent clearing 40 tickets in an 8-hour shift spends 12 minutes, 0.2 hours, on each. Little's Law gives the agents busy at once: 1,250 × 0.2 = 250, against the 190 the daily average suggested. The same law sizes a connection pool in the system-design course; here it sizes a shift.
The AI version: what does this feature cost a month
A model feature adds one assumption the classic lacks. The chain is users × uses a day × calls per use × cost per call, and calls per use is the term candidates skip: a regenerate button, a retry on timeout, an agent loop that calls the model six times per task. Tokens as a cost model has the bill's three lines; the round adds the order and the check.
Worked: "What would ticket summaries cost a month?" — candidate C from the prioritisation module, reach 8,000 agents. Assumptions, said first:
- 8,000 agents each open 40 tickets a day, half long enough to summarise, one call each: 160,000 calls a day.
- A long thread of about 1,000 words is 1,300 tokens at 1.3 tokens a word; with the system prompt, round up to 2,000 tokens in. A summary of about 100 words is 130 tokens; round up to 150 out.
- Assume $3 per million input tokens and $15 per million output.
Input: 160,000 × 2,000 = 320 million tokens a day, $960. Output: 160,000 × 150 = 24 million tokens, $360. That is $1,320 a day, $39,600 over 30 days: about $40,000 a month.
Check against one known number: the drafting feature runs 200,000 calls a day for $54,000 a month, $0.009 a call. A summary call is $1,320 ÷ 160,000, about $0.008: more input, less output, slightly cheaper. Same order, so the chain holds. Had it come out at $0.0008, a factor of ten would be hiding in the chain, and the usual culprit is a dropped zero: 2,000 tokens written as 200.
Then land it. $40,000 a month is more than the drafting feature's whole $30,000 budget, for a feature with no revenue line of its own, and $40,000 ÷ 8,000 agents is $5 a seat a month — the entire add-on price. Name the assumption the answer is most sensitive to: calls per use. If a long ticket is opened by two agents on average and the summary is cached per ticket, regenerated only when a new message arrives, calls halve and the bill falls to about $20,000.
What the AI version adds to the sheet
Three habits mark an AI estimate beyond the classic. The calls-per-use term, said as an assumption rather than left at one. Output priced at five times input, so a longer reply moves the bill more than a longer prompt, as model selection sets out. And a per-unit figure beside the monthly one: per call for the PRD, per seat for pricing. A monthly figure alone cannot be compared with anything the business sells.
In an interview
What is being tested is whether your number arrives with its assumptions and its consequence. Say the assumptions as a list before multiplying and invite correction — "tell me if 40 tickets an agent is off for this customer" — round out loud, check against one number you know, and say what the figure decides. The latency numbers lesson makes the same demand of a design: name the number, then the change it forces in the drawing.
The mistake that loses points is an estimate with no check — a confident figure built from five guesses and never compared with anything the candidate already knew. The second is leaving calls per use at one, which makes every estimate for an agent loop or a regenerate button low by the loop's length.
Check yourself
1. An agent feature resolves a ticket in 6 model calls of 3,000 tokens in and 200 out, on 10,000 tickets a day. Assume $3 per million input and $15 per million output. Does it fit a $30,000 monthly budget?
A call is 3,000 × $3 ÷ 1,000,000 + 200 × $15 ÷ 1,000,000 = $0.009 + $0.003 = $0.012; a ticket is 6 × $0.012 = $0.072; a day is $720; a month $21,600. It fits with $8,400 of room, and the figure is most sensitive to calls per ticket: at 9 calls it is $32,400 and over. Ask for the loop's p95 length, not its mean.
2. Your chain says summaries cost $4,000 a month against drafting's $54,000. Which do you re-check first?
The units. $4,000 ÷ (160,000 × 30) is about $0.0008 a call, a tenth of drafting's $0.009 for a call with more input. A clean factor of ten is almost always a dropped zero — 2,000 tokens written as 200, or 160,000 calls as 16,000. Find it before saying the number.
3. The food-delivery city doubles its orders on Saturday. How many agents does the dinner peak need?
Tickets double to 15,000 and the three dinner hours carry 7,500, so 2,500 an hour. At 0.2 hours a ticket, Little's Law gives 2,500 × 0.2 = 500 agents at once. The daily average says 15,000 ÷ 40 = 375, and the gap of 125 is the scheduling question to ask next.