Product roadmaps are inferior to product forecasts

“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.

Example hurricane forecast graphic from the National Hurricane Center

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.

Twitter’s public roadmap: I’ll believe it when I see it

Full disclosure: I own a small number of shares in Twitter.

Trello is a very important tool in my workflow, so I read their blog for tips and news. I started reading a recent post by Leah Rider and everything was fine until I saw this:

As one of the most dialed-in companies to the pulse of the people, Twitter…

I’m sorry, what? Twitter is notoriously bad at knowing what people want, be they users (an edit button and less harassment), developers (the ability to develop apps), or investors (I’d settle for breaking even at this point). Twitter may be where the pulse of the people is expressed, but that doesn’t mean the company has a clue.

The post goes on to say

Through a simpleĀ public Trello board, Twitter is redefining their relationship with the developer community and setting a precedent for other platforms.

If Twitter wants to define a relationship with the developer community, they could start by having one. The only reason I maintain a Twitter client is because Twitter drove away the original developer. Twitter’s rise was due in part to the ecosystem of great (and not-so-great) third-party applications. Twitter was a platform that people could build off of.

That’s no longer the case. Many features are not available via the API. Polls and GIF searches are two that come right to mind. It takes more than a public Trello board to have a community. And the Trello board isn’t even impressive. It is publicly visible, but not editable. What’s worse, the last update was almost a month ago. The last activity before that was over two months ago.

So if Twitter is ready to develop a robust third-party app ecosystem again, that’s great. It can only benefit the platform. But you’ll forgive me if I wait to see some evidence before I believe it.