June 9, 2023

Roadmap vs. Forecast

In a previous email, I mentioned that a design system is a product and as such needs a clear roadmap that helps let users know what to expect. If you’ve had any experience with product roadmaps, though, you know they can be woefully unreliable.

Do you remember Dark Sky’s UI pattern for the hourly rain forecast? A blue line indicated how much rain you could expect over the next hour. The further right (into the future) the chart went, the more that blue line would wiggle. It was a clever way of communicating the increasing uncertainty that comes with long-term predictions.

In my experience, product roadmaps have the same kind of uncertainty. A month out, it’s relatively easy to paint a reliable picture of what needs to be built and how likely it is to happen. The further out you push that timeline, though, the fuzzier that forecast becomes.

The 37Signals team doesn't even have a roadmap. They like to think about future work in terms of options, not roadmaps.

Whenever I'd do quarterly planning, I'd position this as a handshake agreement of what we were all planning to work on. This was especially important for shared service teams that were building out features and services that were dependencies for other teams.

But building out any product, design systems included, requires a balance of outlining a clear direction and being aware that unforeseen circumstances may require the org to adapt and adjust.

During planning sessions, I would always remind people that, for the most part, our commitments needed to be held loosely. Those planning sessions let us define a clear sense of the scope of work we were taking on, and if that needed to change — for whatever reason — we could have a much more informed conversation about the impact those changes would have on existing priorities and team availability.

—
Cheers,

Up Next: Encouraging participation

← Full Archives