Skip to main content

Why Release Dates Are Irrelevant To Product Managers

November 24, 2015

4 minute read

What’s a product roadmap with dates? A release plan. Or at least it might as well be.

I’m going to say this again and again until my voice is hoarse and my fingers run out of steam. I’ll be a crotchety old lady waving a cane at you saying the same old thing, if I have to:

“Stop putting dates on your roadmaps!”

This is my one and only mantra for a reason. Product managers who refuse to put dates on their product roadmaps do a better job than product managers who do.

They adapt faster when plans derail. They drag-and-drop priorities so product teams don’t find themselves stalled. They run a tighter ship – and speaking of ships, that’s exactly what they do. They ship better products faster.

And though this is controversial, I stand by this: PMs that refuse to work with dates also end up with more successful careers. Or at least the opposite of what Jeff Gothelf outlines here:  

Why? Because they’re doing their job, not a project manager’s. They’re focusing on the KPIs a product manager is actually responsible for: churn, retention and usage.

They do something even bigger than that though. They shift their entire organization’s mindset away from the intuitive, near-manic desire to meet a series of release dates, with something far more sustainable for their business.  

Marty Cagan, a partner at Silicon Valley Product Group (previously at companies like Netscape, eBay and Hewlett-Packard) talks about how product managers help set a new pace at their companies by replacing that obsessive focus on release dates with themes and goals instead:

“The idea is that rather than have a somewhat random collection of features on your conventional roadmap each quarter, why not introduce a focus to the work and have a theme for the quarter.  An example would be to have a big focus on ease of use in Q1, and then a big focus on on-boarding in Q2, etc.“

With a theme at the heart of their work,  these product managers don’t need to rely on dates. They have the flexibility to pursue that quarter’s goal in different ways.

As Cagan suggests above, once you get everyone to start thinking in terms of themes, you free up the way your team thinks about priorities too.

Operate in terms of time horizons, not dates

When you approach your roadmap in terms of themes, you suddenly have a lot more flexibility in the way you set and approach goals. You also don’t really need to deal with delivery dates anymore.

That’s because on this kind of roadmap, product priorities are like movable blocks. You can move one thing up the list because you believe it’ll have an immediate impact on the conversion. You can move another thing down because it’s no longer important.

product roadmap template

Related: How To Build A Product Roadmap Everyone Understands

This is in stark contrast to roadmaps with deadlines stamped on them that look like Gantt charts. When these dates aren’t met (they almost never are), they cause internal delays, stalling and a perpetual company-wide feeling of being behind schedule.

Time horizons – an intentionally vague representation of time – are much more useful to a product manager because they free you up to move your priorities around as circumstances around you change.

That’s why themes pair really well with time horizons. Both are flexible. Both allow you to plan your product and give you space to revise when you face a sudden resource gap, a budget shortfall, or any of the other banal roadblocks that come up between planning and production.

At ProdPad, we call our time horizons “Current”, “Near-Term” and “Long-Term.” At FourSquare, they go with “#now” “#next” and “#later”. Whatever works for you.

After all, time is a somewhat more abstract concept when you’re a product manager.

Update: We developed a 5-part e-course to help you set up and introduce a theme-based roadmap at your organization. Sign up here.



Sign up to our monthly newsletter, The Outcome.

You’ll get all our exclusive tips, tricks and handy resources sent straight to your inbox.

How we use your information

Inline Feedbacks
View all comments
November 27, 2015 8:35 am

Any thoughts on how to work with cases where other people in the organisation want to know if a feature will be ready by a fixed date? For example: a new ‘gifting’ feature that the marketing department would like to prepare a campaign around if it will be ready in time for Valentine’s Day?

December 4, 2015 11:36 am

I would have loved to omit dates from roadmaps throughout my career. However, shortsighted stakeholders like executive leadership, other product teams and enterprise customers conspired against me. BTW, the Gantt-chart representation is inward-facing. Unfortunately, I was regularly expected to show what features or capabilities I would actually ship and when (and customers made huge bets on my ability to deliver over multiple releases without caring at all about the duration of development tasks “behind the curtain”). My advice? Share as little detail on roadmaps as your stakeholders will let you get away with. The corollary? Sometimes your stakeholders will demand… Read more »

Ross Weems
December 7, 2015 9:03 pm

I like this idea, but I think my issue is around timing still. If you dont have a timeline (whether good or bad) a product idea can take on a life of itself. How can I promise the company and customers that we will continue to deliver value if I am ambiguous on the timing? Granted I realize I cannot say “On January 23 @ 4pm” this feature will be implemented. It seems current is too ambigous for alot of organizations? Am I wrong??

Ross Weems
April 8, 2016 3:37 pm

I just saw you responded. thanks for the feedback Janna!

[…] Why Release Dates Are Irrelevant To Product Managers […]