Forecast Model Template for Product Analytics

Run-rate forecasting extrapolates recent trends forward: "We grew 4% MoM for the last 6 months, so we will grow 4% MoM for the next 6 months." It is fast to build but fragile because it assumes the future looks like the past. Driver-based forecasting decomposes the metric into inputs (signups, activation, churn) and forecasts each input separately. It is more work to build but more resilient because you can update individual drivers when conditions change.

Review actuals monthly and update the forecast quarterly. Monthly updates add noise because individual months fluctuate. Quarterly reforecasts give you enough data to identify real trend changes versus random variation. The exception: if a major event occurs (competitor launch, pricing change, platform shift), update the forecast immediately.

Expect your base case to be within 15% of actual at 3 months and within 25% at 6 months. If your forecast is consistently within 10% at 6 months, either your market is unusually stable or your assumptions are too conservative (you are predicting what already happened, not what will happen). The goal is not precision. The goal is a useful range that informs resource allocation decisions.

Yes. Presenting only the base case implies certainty that does not exist. Share all three scenarios with the assumption changes that drive each one. This lets leadership ask "what would need to be true for the pessimistic case to happen?" and make contingency plans. The [impact analysis template](/templates/impact-analysis-template) can help quantify the consequences of each scenario on specific product decisions.

Use comparable analogs. Find similar products, features, or markets and borrow their growth rates. For example, if you are launching a new collaboration feature, look at adoption rates of similar features in competitor products or in your own product's history. Document that the forecast is analog-based and assign it low confidence. Reforecast after 4-6 weeks of actual data.