“It’s hard to make predictions, especially about the future.” — Danish proverb
What does “second quarter” mean to you?
For most technical teams, the second quarter is when they work on a project from April to June, hoping to deliver it by late June or early July.
For executives and marketing teams, second quarter means the project will be available on April 1 at 8:00am so they can start promoting it.
And for sales teams, the second quarter means availability in mid-February so they can close deals April-June.
And these different definitions can cause some serious confusions. The product roadmap has become one of the most popular forms of stakeholder communications. It’s shared with executives, sales, marketing, customers and others as a clear outline for projects. Though for most product teams, finding the right level of detail is difficult. You want to be clear, but you don’t want to force yourself into a box.
There are generally two different types of roadmaps: date-driven roadmaps and phase-driven roadmaps. Here are the differences between the two.
The disconnect between dates and definitions is one of the reasons many product teams have moved from date-driven roadmaps to phase-driven roadmaps. It buckets elements into understandable, but not date-defined, segments which allows teams to move forward when things are ready but aren’t nailed to a date.
(shown as Completed in the graphic above) is for the many things that are completed and are available to your sales teams and customers. With so many projects constantly looming, it’s easy to forget all the work that we’ve accomplished and focused solely on the future. These are the projects and features you should emphasize with your customers.
is for those items that your team is actively building. You’ve nailed the requirements and acceptance criteria, and you’ve probably already seen some prototypes and even some working demos. Barring any complications, SOON items will be available in a few iterations, and we can safely talk about them with sales teams and customers.
is used for requirements and stories that are fully documented but not yet begun. You know what they are but haven’t started working on them. They are part of the continually prioritized backlog of work to be done when resources become available.
is everything else. These are the products, options, features, requirements and stories that are in the queue to be defined. We don’t really know what they are yet. We don’t know their size, and we don’t know their acceptance criteria. FUTURE is for those “yeah, it’s on my list” items.
We know that NOW items are available today, and SOON items will likely be available in the next release. Assuming our resources free up as planned, we can take a guess at some of the high-priority NEXT items. We have no idea when the FUTURE items will be available and can’t make any guesses until we know more about the item.
The typical date-driven roadmap looks like this:
This roadmap shows the focus for product activities over the next 18 months, including themes, markets, personas and goals. What’s missing from this roadmap is a HUGE disclaimer that these are plans, not commitments. Many things can go wrong over the next 18 months to derail some or all of these plans.
What happens to your roadmap when a big sale requires an unplanned feature? What happens to your roadmap when your dev team is re-allocated to a new project? For that matter, what happens when a small story turns out to be a huge story—one that is a prerequisite for many others?
We’re not talking an exact science here. Product design and development is more of a craft than a science after all.
Here’s a simple way to communicate: stick to the truth. What do you know is true? “I know we will release this feature in the next two weeks. I’ve seen it.”
“I know we’re working on another feature that will ship in the next two months—because we’re working on it now and I’ve seen preliminary demos.” Tell that to your various audiences.
“But Steve, when will those items in the FUTURE column be delivered?”
“After we begin working on them.”
That is, we’re not working on them now, but we will work on them in the future. And we’ll know they will be likely to ship soon after we begin working.
Stick to the truth. It’s easier to remember.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.