📏Impact Sizing
Before you commit a quarter to a project, size the upside. The single most-skipped step in PM prioritization.
Most teams pick projects based on excitement, not expected impact. Disciplined impact sizing — even rough numbers — prevents quarters wasted on bets that couldn't have moved the needle even if perfectly executed.
Impact sizing estimates the expected value of a project: how many users it'll reach × how much it'll change behavior × confidence. Even a rough estimate (with a 3x error bar) is far better than no estimate. The discipline is using it to *kill* projects whose ceiling is too low to matter.
The basic formula
Expected impact = Reach × Magnitude × Confidence
- Reach. How many users are affected. Annual users × % in the relevant segment × % who'd hit this feature.
- Magnitude. How much the metric moves per affected user. Often 1-5%.
- Confidence. Your probability that the magnitude estimate is right. 0.1 (lottery ticket) to 0.9 (proven mechanic).
Walking through an example
You're considering adding a 'save for later' feature.
- Reach: 1M monthly active users × 30% in target segment × 40% who'd hit this = 120K affected users.
- Magnitude: 5% lift in week-over-week retention (rough estimate based on competitor data).
- Confidence: 0.4 (some evidence from interviews, no direct test yet).
Expected impact = 120K × 0.05 × 0.4 = 2,400 incremental retained users per week.
Now compare to other bets. If another project has expected impact of 10,000, you're sizing the 'save for later' as much smaller. That's the call to make.
The trap of false precision
Impact estimates are inherently uncertain. A senior PM uses them as a relative ranking tool, not absolute numbers. "Bet A is 3x bigger than Bet B" is useful. "Bet A is exactly 7,432 retained users" is theater.
When to size
- Quarterly planning. Size every candidate bet.
- Big-ish features (>2-week build).
- Whenever someone says 'this would be huge' — force them to size it.
When NOT to size:
- Tiny features (size of the analysis > size of the feature).
- Strategic bets where impact is unmeasurable in 90 days.
- Bug fixes.
The cultural shift
Adopting impact sizing as a team practice usually takes 2 quarters. The first quarter, sizes are wildly wrong. The second, they get calibrated against actual results and the team learns to estimate better. By quarter 3, the team's prioritization is materially sharper.
Real-world examples
Meta's PMs are required to size impact before every major launch and during quarterly planning. The discipline forces honest conversation about what could actually move metrics at Meta's scale — most things can't, which sharpens what's worth doing.
Go deeper — recommended reading
Interview questions (1)
Q1Walk me through how you'd size the impact of adding a referral program to a SaaS product.metricssenior▼
Three components.
Reach. Active paying customers × % who'd refer in any given month. Industry benchmark: 10-20% of happy customers refer when prompted. So if you have 50K paying customers, reach is 5K-10K per month.
Magnitude. Conversion of referred prospects × ARPU. Referrals typically convert at 25-40% (much higher than other channels). So 5K refers × 30% conversion = 1.5K new customers/month, at say $100 ARPU = $150K MRR added.
Confidence. First-time referral program in a SaaS context: 0.4-0.6 — there's good precedent but execution varies wildly.
Expected impact: ~$60K-$90K MRR uplift after applying confidence factor. At $1M ARR contribution per year, the bet is worth ~6-9 person-weeks of engineering.
Compare to other bets. If the team has options that size to $500K+, this might not win prioritization. If everything else is $50K, referrals win.
The discipline isn't the precision — it's the act of forcing the conversation.