It’s True, Most People Don’t Need To Know Your Product Timeline

We recently published “Why Release Dates Are Irrelevant To Product Managers” and it immediately became one of our most widely shared pieces. Was it something I said?

I hope so.

The worst kept secret of in the product management community is that we’re terrible with dates. We don’t like them. Working with them is bad for our products and bad for our careers. But for the sake of our teams, our bosses and our customers (who in a sense, are also our bosses), we continue to set timelines.

And we continue to miss them, change them or end up in a sweaty panic when we realize we’re moving forward on a project we’d rather axe altogether.

When I suggested that you can keep dates out of your job altogether, a lot of you were intrigued. And then you wanted to know what that looks like. How do you actually get away with ambiguous timelines?

The following is how I outlined it for one of our readers.

Q: How do 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. But not having a timeline is too ambiguous for a lot of organizations. Am I wrong?

A: Absolutely. You can’t abandon timelines altogether – that would never work.

The trick is to have two separate documents up your sleeve, with two different purposes: your roadmap and your release plan.

Your release plan outlines dates, dependencies and resources for the upcoming releases. Your roadmap broadly shows your current, short-term and long-term priorities.

Now, how you or your dev team manage this depends on your dev style.

If you’re following an agile methodology, 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 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 your thing, you might be mid-project and have a plan to release in a couple months. (Though this 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 why so many companies are moving to more agile approaches!)

So for the very short term, you should have a release plan of sorts. It can 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, and so on. It’s like a mini project plan for what’s already in the pipeline.

This works out great for you – they usually don’t need to know much beyond the next few weeks anyway.

Everything else sits on your product roadmap.

The Current column of your roadmap shows 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, analyzed, 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.

Just talk about them separately.

This keeps conversations around the release plan tactical (how do we get this out, what can we do to unblock this obstacle?), and conversations around the roadmap 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?). 

So when it comes to roadmap, you get to have that flexibility so you can react to changes in the market, competition, or how customers reacted to what you just made live in your last release.

What do you think? Did life just get a little easier or what?

Update: We’re developing an e-course to help you set up and introduce a theme-based roadmap at your organization. We’ll drop it in your inbox when it’s ready – sign up here.