The three shapes of randomness every PM should recognise
Normal, Poisson, and binomial with nine real examples across consumer, SaaS, and security.
As a PM in tech, you don't need to derive probability density functions from scratch. What you do need is pattern recognition. When a data scientist shows you a chart, or when you're staring at your own dashboard trying to decide if a spike is real, knowing which distribution is behind the numbers saves you from two common failures: over-reacting to noise, and under-reacting to signal.
Here's how to think about the three you'll run into most.
Normal distribution: the bell curve for continuous measurements
The normal distribution shows up whenever you're measuring something continuous that results from many small independent factors adding up. It's symmetric around a mean, most values cluster near the middle, and extreme values are rare on both sides.
Shorthand: if you're measuring something and asking "how much", reach for normal.
Consumer example: session duration in a mobile app. You're a PM on a consumer social app. Average session length is 6 minutes, with most sessions between 3 and 9 minutes. Sessions of 30 seconds or 30 minutes exist but are rare. When you ship a new feed ranking algorithm and want to know if it moved session length, you're comparing the means of two roughly normal distributions. This is why t-tests work for most A/B test metrics.
B2B SaaS example: API response latency. Your p50 is 120ms, p95 is 340ms. Latency across millions of requests, once you strip out timeouts and errors, tends to be approximately normal (often log-normal, but close enough for most PM decisions). When your SRE shows you a latency histogram and it looks like a bell, you can reason about percentiles, standard deviations, and whether a deploy actually regressed performance.
Cybersecurity example: time between legitimate user logins. For a given user, the gap between consecutive logins has a central tendency. Most users log in during working hours, with small variations day to day. Behavioural analytics systems fit a normal (or log-normal) baseline per user, then flag the tails. A user logging in at 3am from Dublin when their baseline is 9am on weekdays sits four standard deviations from the mean. That's the math powering "unusual login time" alerts.
When a PM reaches for it: A/B test effect sizes, latency and performance distributions, measurement of anything continuous where you care about "how much" and "how spread out."
Poisson distribution: counts of rare events over time or space
Poisson is what you want when you're counting discrete events that happen independently at some average rate, and most of the time the count is low but occasionally it spikes.
Shorthand: if you're counting "how many per hour" or "how many per user per day", reach for Poisson.
Consumer example: customer support tickets per hour. A consumer app with 10 million DAU averages 40 support tickets per hour. Some hours you get 35, some you get 48, occasionally you get 70. The shape is right-skewed because you can't have negative tickets and the floor is zero. If you're staffing a support team or setting a PagerDuty threshold, fitting a Poisson tells you that a 70-ticket hour isn't a crisis, it's the tail of your normal variation. A 150-ticket hour is a crisis.
B2B SaaS example: feature usage events per user per day. How many times does the average user trigger the "export to CSV" action per day? Most users never use it in a given day. Some use it once. A handful use it 10 or 20 times. Poisson (or its cousin, the negative binomial, when variance exceeds the mean) models this cleanly. Knowing this helps you avoid the classic PM mistake of averaging a right-skewed count and thinking "2.3 exports per user per day" is representative, when actually 95% of users do zero and your power users are doing 40.
Cybersecurity example: failed login attempts per account per hour. A normal account sees maybe 0.1 failed logins per hour on average. Most hours have zero. A Poisson model tells you that 3 failed logins in an hour is extraordinarily unlikely by chance alone, which is why "three failed attempts" is such a common lockout threshold. It's not arbitrary, it's calibrated to the tail of a Poisson.
When a PM reaches for it: Incident modelling, support volume forecasting, anomaly detection on event counts, capacity planning for rare-but-spiky workloads.
Binomial distribution: successes out of a fixed number of tries
Binomial is for when you have a fixed number of independent yes/no trials, each with the same probability of success, and you want to know how many successes you'll see.
Shorthand: if every user either did or didn't do the thing, and you want to know "how many out of N", reach for binomial.
Consumer example: onboarding conversion. You ship onboarding to 10,000 new users. Each user either completes it or they don't. Historical conversion is 42%. Will this cohort convert higher or lower? Binomial tells you the expected range. At n=10,000 and p=0.42, you expect about 4,200 conversions with a standard deviation of roughly 49. So 4,150 is boring, 4,400 is worth a closer look, 4,800 means your experiment is probably real. This is literally how every conversion-rate A/B test works under the hood.
B2B SaaS example: trial-to-paid conversion for a cohort. 500 accounts started a 14-day trial in October. Each one either converts or churns. Base rate is 18%. You're evaluating whether a new activation checklist moved the needle. Binomial gives you the distribution of outcomes under the null hypothesis, which is what your "statistical significance" calculation is actually computing.
Cybersecurity example: phishing simulation results. Your security team sends a simulated phishing email to all 2,000 employees. Each employee either clicks or doesn't. Last quarter's click rate was 12%. This quarter it's 8%. Is training working, or is that within the noise floor of a binomial with n=2,000 and p=0.12? Standard deviation here is about 14 clicks, so a drop from 240 to 160 is real. A drop from 240 to 225 is noise.
When a PM reaches for it: Conversion rate analysis, A/B tests on binary outcomes, pass/fail quality metrics, anything framed as "X out of N did the thing."
Quick decision table
Ask yourself what you're actually counting.
- If it's a continuous measurement like time, money, or distance, and it looks symmetric: normal.
- If it's a count of events over a window and most values are low with occasional spikes: Poisson.
- If each observation is a yes/no outcome and you have a fixed number of observations: binomial.
One subtle note: binomial and Poisson are siblings. When n is large and p is small, the binomial converges to a Poisson with λ = np. This is why "clicks per million impressions" can be modelled either way and you'll get similar answers. Normal, meanwhile, is the limiting case of both when sample sizes get large. This is the Central Limit Theorem, and it's why A/B test math on conversion rates still uses normal approximations even though the underlying process is binomial.
Why this matters for product decisions
The unifying lesson is this: every metric on your dashboard has an underlying generative process, and that process has a shape. If you don't know the shape, you can't tell noise from signal. You'll chase phantom regressions, miss real wins, and over-alert on things that are mathematically expected.
The data scientists on your team know this. The better you speak their language, the faster your decisions get.