Ask Teresa: My Leaders Still Want Roadmaps with Timelines—What Should I Do?

Share this article

Many teams, like sales and marketing, have time-bound goals, like reaching $X in bookings or generating Y leads by a specific date.

Product teams are also held to time-bound goals. Empowered product teams, for example, are asked to deliver outcomes each quarter.

But sometimes companies take this too far. They ask product teams to deliver specific features by specific dates. This is like asking a sales rep to close a specific deal on a specific date. Or asking a marketing team to get a set number of leads from a specific campaign.

Our work is unpredictable. Sales reps can commit to quotas, but they can’t always tell you what sale will close when. Marketing teams commit to driving a certain number of qualified leads, but they can’t always tell you which campaigns will work and which won’t.

The same is true for product teams. Estimates are unreliable, problems grow in scope, and we don’t know what will work until we test it. This doesn’t mean we can’t commit to outcomes. We do. But it does mean we shouldn’t commit to specific features by specific dates.

This can create tension between product teams and your company leadership or stakeholders—some argue that they can’t coordinate work with the rest of the company without these dates.

This was a question that came up in the CDH community and I know it’s something a lot of product teams struggle with.

Question: How do you respond to requests for date-based roadmaps?

To provide a bit more context, one CDH community member was being drawn into theoretical debates about date-based roadmaps. They were encountering arguments like, “No one else in the org can set goals without date commitments, so product needs to be held to the same standard.” They turned to the CDH community to see how others have engaged in similar conversations and whether they’ve found a happy compromise.

Here’s my take on it.

The Problems with Date-Based Roadmaps

First, I’d like to address some of the shortcomings of date-based roadmaps. Most teams don’t usually end up releasing features on the dates indicated on their roadmaps. While roadmaps appear to create certainty—you’re showing what will happen when—they actually create chaos. They set unrealistic expectations and destroy trust when you can’t uphold them.

I’ve written before that date-based “roadmaps are exercises in futility.” The reason I say this is because teams put a lot of time and energy into a document that is immediately out of date and often ignored. For many teams, creating roadmaps is a political game that allows stakeholders to argue over their own interests rather than putting customers or users first.

At best, creating a date-based roadmap is a waste of time. At worst, it sets the wrong expectations and puts the product team in a position of having to always defend their deviations from the plan.

We need to let go of the idea that we can enumerate a list of features that represents what we’ll do in the future. This idea is absurd.

However, I want to clarify that my issue is not with roadmaps altogether. There are some types of roadmaps and some situations when roadmaps allow our stakeholders to know what we are working on now, what we’ll be working on next, and what we may be working on in the future.

This is why I’m a fan of Janna Bastow’s Now Next Later roadmaps—they allow you to communicate this essential information without overcommitting to exactly what you’re going to build when.

In fact, I use the Now Next Later format (although I use the language "Now Next Future") for my own Product Talk roadmaps. I shared an example a few years ago when I announced my plans for 2021.

You’ll see that as the roadmap moves further into the future, there’s much more uncertainty, especially when it comes to specific solutions and their timelines. If you’d like to dive more into the context around this roadmap, you can read the full article here.

The Biggest Lesson: Don’t Fight the Ideological War

Now that I’ve gotten my rant about date-based roadmaps out of the way, let’s look at some ways you can actually tackle this problem.

My most important lesson to impart is: Don’t fight the ideological war.

This is a point I emphasized during my Product at Heart keynote. The golden rule of organizational change is to meet people where they are. We don’t accomplish anything when we try to convince people we are right. Instead, we need to find ways of making small changes that they can agree with (more on that in the next section).

If your stakeholders are insisting you use date-based roadmaps, I wouldn’t engage in the ideological war about deadlines and predictable work (as the person who asked this question felt they were being drawn to do). Instead, start with a feature-based roadmap. Give your stakeholders what they are asking for, and over time, you can introduce opportunities and outcomes.

Start Small and Iterate

While you are giving your stakeholders what they’re asking for in the form of roadmaps with timelines, you can use the same artifact to start introducing opportunities and outcomes.

With a date-based roadmap, you’ll inevitably miss your deadlines. So when you learn that a given solution won’t work, or you need to reduce scope, or you need to ask for more time based on something you learned in discovery, couching the changes in the context of the opportunity and outcome on the roadmap will make it feel less like a miss.

It helps to introduce consistency when solutions need to change. For example, you can say something like, “We had to descope the solution to hit the deadline, but we are still confident it will address the opportunity.”

In my conversation with Ellen Juhlin about introducing continuous discovery at her organization, she shared a great example of taking this approach. What I really love about Ellen’s story is that she looked at where her organization was at to determine where she could introduce different pieces for the people who were receptive.

In her case, she started adding outcomes to her roadmap spreadsheet as a small first step. While leadership was used to dealing with a list of outputs, Ellen started to connect each output to the outcome it would drive, like winning a big customer or increasing engagement. This allowed the product team to introduce outcomes into their priority conversations.

Ellen’s story reminds us not to seek perfection or wholesale change—it’s really about finding the small changes you can make and iterating from there.

Communicate Your Vision and Your Process

Finally, you want to commit to communicating your vision and your process with your stakeholders. Instead of sharing feature lists, we should communicate how we will make decisions.

Everyone needs to know how much progress you have made towards your goal and what else you are doing to get there. These are the conversations we should be having with our teams.

What about your customers? Do they need to know what features are coming when? My answer is: It depends. Most teams err on the side of telling their customers way too much about what is coming and when.

You do need to tell your team and your customers what’s coming next. As in your next release. But you don’t need to tell them what’s coming next quarter or the quarter after that. Most of the time, they won’t care. And the times when they do, if you set wrong expectations, you’ll do far more harm than good.

You think about your product all day every day. Both your team and your customers only think about your product to the extent that it helps them get done what they need to get done. Their view of the future when it comes to your product is much shorter than yours. That’s a good thing. Use it to your advantage and stop setting expectations that you can’t keep.

We tackle questions like this one in the Continuous Discovery Habits community every day. If you’re looking for a place where you can discuss your own challenges and successes with like-minded peers, come join us!