How to break down ambiguous estimation questions for PM interviews
When faced with an ambiguous estimation question, immediately clarify scope, state key assumptions, and segment the user or use case before proposing numbers. Justifying each step and showing your reasoning is more valuable than the final estimate itself.
PMMockr.com Start by clarifying scope and intent
Ambiguous estimation questions often trip up candidates who jump straight to numbers without understanding what’s truly being asked. For example, if asked, “How many electric scooters are needed in a city like Boston?”, don’t assume you should estimate total vehicle count immediately.
First, clarify the question’s scope: Does 'needed' mean to meet peak demand, daily average use, or full market saturation? Is the focus on city limits, metro area, or a specific neighborhood? Asking for clarification or stating your assumptions ensures your answer is targeted and relevant. This initial step demonstrates that you’re thoughtful and methodical, not just quick with math.
Decompose the problem before estimating
Rather than jumping to a single number, break the question into smaller components that drive the total estimate. For the scooter example, consider: Who are the potential users? When and where might they ride? What factors constrain supply (e.g., charging, parking)?
Outlining these drivers helps you build a logical structure. It also gives you touchpoints to revisit if you realize partway through that an assumption may be flawed. This decomposition shows you’re not guessing blindly but building a model that could be tweaked as new information comes to light.
Segment users and use cases
Assuming all users are alike is a common mistake. Estimation accuracy improves if you segment users by behavior or need. In the scooter scenario, you might separate commuters from tourists, and further distinguish between daily riders and occasional users.
Suppose you assume Boston’s population is 700,000 (invented for this exercise). If 60% are adults, and you estimate 10% are likely scooter users, you now have a plausible user base to work with. Segmentation helps you avoid gross over- or underestimation and provides levers for adjusting your model if your assumptions are challenged.
Prioritize key drivers and avoid overcomplicating
With multiple variables at play, resist the urge to account for every possible factor. Focus on the 2-3 drivers that most impact your estimate. For scooters, these might be number of active users, average trips per user, and scooter turnover (how many rides a scooter can support per day).
If you spread your attention too thin, your answer bogs down in minor details. Instead, acknowledge what you’re choosing to ignore for simplicity, and explain why you think those omissions are reasonable for a first-pass estimate. This shows judgment, not just thoroughness.
Worked example: Estimating scooters needed in Boston
Let’s walk through the estimate for 'How many electric scooters are needed in Boston?'
First, clarify: Assume we want to provision enough scooters to serve Boston city proper during weekdays, targeting peak commuting hours, and focusing on adults (age 18+).
Assumptions: - Boston population: 700,000 (hypothetical) - Adults (18+): 60% ⇒ 420,000 - Percentage likely to use scooters: 10% ⇒ 42,000 - Of these, 50% are active commuters (ride 4x/week), 50% are occasional users (ride 1x/week)
Estimate total rides per week: - Commuters: 21,000 × 4 = 84,000 rides/week - Occasionals: 21,000 × 1 = 21,000 rides/week - Total: 105,000 rides/week - Daily (divide by 5 weekdays): 21,000 rides/day
Assume each scooter can handle 6 rides/day (charging, maintenance, distribution constraints). Needed scooters: 21,000 ÷ 6 ≈ 3,500
So, you’d recommend starting with 3,500 scooters. If you learn that most rides cluster within 2 hours, you might need to increase the fleet for peak demand—perhaps by 25%, bringing the estimate to 4,400 scooters.
If your assumption about ride frequency is challenged (e.g., data shows average is only 2 rides/scooter/day), you’d need to double the fleet to meet demand. This approach lets you easily revise your estimate as new evidence arises.
Compare a competing approach and weigh trade-offs
Some candidates might try to estimate scooter need by dividing the city’s area by coverage radius per scooter, or by benchmarking against a different city’s scooter density. While these methods can provide a quick check, they risk missing behavioral factors like actual demand or clustering of use in specific neighborhoods.
A city-area approach may yield a much higher or lower estimate, but lacks the flexibility to adjust for user adoption rates or peak demand patterns. The demand-driven segmentation method, as above, ties the estimate to real (if assumed) user behavior, which is more defensible and adaptable.
Spotting and correcting weak reasoning
A weak approach would be to assume 'everyone will use a scooter once per week' and multiply that by population. This would overstate demand and ignore competing transit options, weather, and user preferences.
A stronger approach, as in the worked example, segments users by likelihood and frequency, then uses realistic constraints (rides per scooter per day). The difference is that the strong approach makes explicit, adjustable assumptions and explains why each was chosen, making the estimate more credible and adaptable.
Validate with a practical experiment
To check your estimate, propose a pilot launch: Deploy 500 scooters in a few Boston neighborhoods and track utilization—rides per scooter per day, peak period demand, and user growth over a month.
If you observe that scooters average only 3 rides per day, your initial fleet size estimate is too low for citywide deployment. Conversely, if the pilot shows 8 rides per scooter daily with unmet demand, you can recommend a smaller fleet or target specific high-demand corridors. New evidence from actual user behavior should directly inform your next iteration.
Practice exercise and self-review checklist
Timed drill: Estimate the number of portable phone chargers needed at a typical airport on a weekday. Spend 8 minutes clarifying scope, segmenting users, stating assumptions, and justifying your steps. Prioritize main drivers over minor factors.
Checklist: - Did you clarify the scope and intent before estimating? - Did you segment users or use cases with explicit assumptions? - Did you prioritize key drivers and explain omissions? - Did you check for weak leaps in logic and revise? - Did you propose a way to validate or revise your estimate?
Practice 1-2 estimation questions per week, focusing on clarity and reasoning. PMMockr can provide realistic prompts, but consistency and structured self-review matter most.
FAQ
How should I handle an estimation question if the interviewer won’t clarify the scope?
State your best interpretation of the question, clearly outline your assumptions, and explain how your answer would change if those assumptions are incorrect. This demonstrates structured thinking even without external guidance.
Is it better to use top-down or bottom-up estimation methods?
Choose the method that best fits the question and your assumptions. Bottom-up (segmenting and building up) is often more defensible for ambiguous cases, but a top-down method can provide a useful cross-check.
What’s the most common mistake candidates make on ambiguous estimation questions?
Rushing to a number without clarifying scope, segmenting users, or justifying key assumptions. This leads to oversimplified and less credible answers.