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.
Sign up to our monthly newsletter, The Outcome.
You’ll get all our exclusive tips, tricks and handy resources sent straight to your inbox.
8 thoughts on "Why Release Dates Are Irrelevant To Product Managers"
Comments are closed.
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?
This is always a tricky one, but it comes down to a couple key facts: If you’re given a fixed date to release something, you either have to be flexible on scope (and potentially deliver a lighter version of the new ‘gifting’ feature), or start planning and preparing for the launch well in advance, with plenty of buffer. If the project launch is mission critical, then your company will have to invest more in the resources and time to plan the delivery…. this, as you probably can imagine, gets costly, and slows down a company enourmously (not least because of all of the excess buffer that’s having to be added in, just to be sure you start on time to finish by Launch Day). However, a company that’s spending all of their time trying to make sure something critical and complex is delivered on time is almost certainly not moving as fast and solving problems through quick iterations in the same way a startup would. This is how big companies get disrupted 😉
If you do neither of these (being flexible on scope but not putting in the required planning), then the other side of the ‘Iron Triangle’ is at risk: Quality. When Launch Day arrives, your rushed project is a mishmash of half-tested features which just might fall apart when pushed live.
Now in your case, it’s likely that this ‘gifting’ feature isn’t as mission critical to the company so as to require an army of planners, or isn’t so fixed in scope due to the complexity of the problem your solving so as to prevent you from creating a simplified version that could still be released in time if the delivery falls behind schedule.
The reality is that estimating and planning for software is inherently very difficult, as the end product is usually loosely defined and the process of coding, designing and launching a product (or even just a feature) is not an exact science. The unknowns in the process result in uncertainty in timings, and so your best defense against this, if you want to remain agile, is to be flexible on scope and aim to deliver in small, usable parts rather than big-bang launches.
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 a lot of detail (or will buy from someone who is willing to commit). Multiple roadmap versions are critical in these situations.
You’ve got the right tactic in place here, I would think. If you are being forced on a timed delivery, you need to be flexible with the level of detail that’s going into each initiative. Over the course of your career, you might actually be seeing the same trend we are, where companies are realising that they need to move faster and therefore have to embrace a more agile approach. Enter ‘Lean Enterprise’ or ‘Lean Startup’ methodologies, which aim to give companies a framework for doing so.
And yes, don’t be afraid to have multiple versions of your roadmap! Different stakeholders have different needs and should be communicated to in a different way. Your internal roadmap (for your inner circle, like the product team, devs, ops, support, etc) might have a lot more detail and show internal-only initiatives, whereas the roadmap you share with execs or customers will be higher-level in detail and will likely hide a bunch of initiatives that are internal-only.
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??
Hi Ross, it’s a fair question and definitely a common one! Keep in mind that we’re not suggestion you don’t have dates on anything, just not on your roadmap. You should also have a release plan, which outlines the dates, dependencies, resources, etc. for the upcoming releases. It’s like a mini project plan for what’s immediately in the pipeline.
Now how you (or your development team) manage this will depend on your chosen development style. If you’re following agile methodologies, you might have a backlog of stories that are approved, estimated, and ready to be picked up for development in the next 2-3 sprints. If each sprint is 2 weeks and is followed by a release, then you would have a working plan for what’s going to be released over the next 4-6 weeks. If your team is using a Kanban board with releases every few days, you might have a release plan of just a couple weeks. If waterfall is more of your thing, you might be mid-project and have a plan to release in a couple months (though this latter one gets harder and harder to manage, especially if you’re not putting in the upfront time to do the project management work of estimating, buffering, and planning in detail to get it out…. it’s the reason so many companies are moving to more agile approaches!)
So for the very short term, you should have a release plan of sorts (it could be as simple as a ‘To Release’ pile that gets stacked up in your Trello board, or something more structured in JIRA). The release plan is essential as you still need your marketing team to be prepped for a launch, your support team to be trained on how to support, your sales team ready to start selling, etc. However, they usually don’t need to see _beyond_ those initial few weeks where you can provide (at least some!) certainty on dates.
Beyond the release plan, and in a different document altogether, is your roadmap. The Current term column of your roadmap will show broadly what’s in development and coming up to be released (we even pull through the exact status of each ticket so you can see the progress in real-time). But the Current column, which might be anywhere from 2-4 months of overview, will include a broader picture of what’s coming up: It doesn’t just show what’s in development at that moment, but also looks at everything that’s being planned, analysed, designed, and prepped for development too.
So don’t do away with dates altogether – these are essential to knowing when something’s going to go live. But until it’s really gone into development, you won’t have a clear picture of when it’ll come out, so when it comes to roadmap, give yourself that flexibility in your product so you can react to changes in the market, competition, or based on how customers reacted to what you just made live in your last release! It means that the conversations around the release plan are tactical (how do we get this out, what can we do to unblock this obstacle?), while conversations around the roadmap are strategic (are these initiatives going to move the needle, are they in the right order based on what we’ve seen in the last 6 months?)
Two documents, with two different purposes.
I just saw you responded. thanks for the feedback Janna!