“It’s on the roadmap” was a common expression when I worked in customer-facing roles. That statement is a delightfully vague response to feature requests. It might mean “it will be in the next release.” More often, it was as close as I could get to saying “yeah, there’s no way in hell we’ll ever get around to implementing that” without getting myself in trouble. Cowardly? Probably. But at least it was tactful.

At a previous company, we did actually have a product roadmap. It looked forward through the next year, broken down by quarter. The first quarter was generally pretty accurate, even if some of the work slipped a bit. The second quarter was okay. The third and fourth quarters? Well they didn’t really reflect anything approaching reality.

I suspect we were not unique in that regard. Perhaps that’s why it’s so easy to find product managers breaking up with their roadmap. It’s why roadmaps became a metaphor for an Uber ride in a Denver blizzard. It’s why a two month project that ships three years later makes an instantly-relatable comic.

But for me, it’s all about how the road map is used. “Road map” is a pretty lousy term, when you think about it. I spent a lot of time looking at road maps as a kid (I’m so cool!) and they almost always gave an accurate representation of what was coming a mile or a hundred miles ahead. Product road maps, if taken that way, lead to lies and broken promises.

For me, a better framing is a product forecast. When the National Hurricane Center forecasts hurricane tracks, they don’t just draw a line and call it a day. The forecast graphic shows an area of uncertainty that expands with time. When a storm is a few hours offshore, you can generally be fairly certain where it will make landfall. When it is days away, the potential landfall area is much larger.

The analogy isn’t perfect, of course. Products can pivot much faster than hurricanes can. And storms are things that just happen to us, whereas the product is something we can consciously effect. But in general, I like this idea. In the short term, you know what you’re working on and what you’ll be able to deliver. Beyond that, you know where you’d like the product to go, but something may happen between now and then to change it.

I like the “Yes, No, Maybe” model that Ben Balter wrote about last year. In his post, Ben limits the roadmap to the next three months and categorizes work as “yes we’re doing that”, “no we’re not doing that”, and “maybe, but we need more information”.

The advantage of the three-month window is that it prevents the roadmap from becoming a giant lie. But extending a product roadmap (or forecast) beyond three months helps give some context to the work being done in the short term. People benefit from having a longer-term vision, even if they change direction before they ever reach it. Forecasts are wrong sometimes, but they represent the view of the future from the best information available at the time.