Why Release Dates Are Irrelevant To Product Managers
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.
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.