Should Product Roadmaps Have Dates?
Whether product roadmaps should have dates has attracted much debate in product management. Some people passionately argue that dates should be banned from roadmaps. Others claim that they are useful.
In the video below, I share my advice so you can decide which option is right for you. I’ve also included a transcript in this article so you can read my recommendations if you prefer.
The Product Roadmap in a Nutshell
To start with, let’s briefly recap what a product roadmap is. A roadmap is a high-level plan that states how a product is likely to evolve over the next, say, 12 months and that shows the specific benefits it should offer.
If you want to learn more about what a product roadmap is and how you effectively use the tool, then watch my video Supercharge Your Product Roadmap.
Should You Put Dates on Your Roadmap?
Now, can it be helpful to state dates and specific time frames on a product roadmap? The answer to this question largely depends on the audience.
If you use a roadmap to communicate with customers — possibly to demonstrate that you are committed to the product and have some great ideas in the pipeline, I recommend that you do NOT state any dates. Instead, use big, coarse-grained time frames like “in the first half of the year and the second half of the year.” Or you might apply Janna Bastow’s now-next-later approach.
In both cases, you still capture temporal information. But it is vague enough so that you don’t commit to specific dates or narrow time frames. This avoids the risk of putting yourself and your development teams under pressure and disappointing customers.
However, if you use an internal product roadmap that guides the work of stakeholders and development teams, I recommend using specific time frames or dates. Why? There are two reasons:
- It helps you understand if your plan is realistic — if the contents can be delivered as expected.
- As you implement the roadmap, unforeseen things can happen. For example, the development progress is slower than anticipated, a technology chosen is more difficult to use, or the user feedback on an early product increment suggests that the effort is higher than you thought.
In such a situation, you’ll want to make the right trade-off decision: Should you aim to fully realise the desired benefits stated on the roadmap but take more time to provide them? Or should you be less ambitious but stick to the date or time frame? This trade-off assumes, of course, that you’ve thought about a specific time frame or a date in the first place. To put it differently, date can help you guide the delivery work and maximise the value your product creates.
Are You Still Unsure about Using Dates?
If you are still uncomfortable about having dates on an internal product roadmap, then ask yourself why this is. A common cause is that stakeholders want specific features delivered at a certain date. If that’s the case for you, then apply the following two measures:
First, use an outcome-based, goal-oriented roadmap — like my GO Product Roadmap — instead of a traditional, feature-based roadmap. An outcome-based plan focuses first and foremost on the benefits a product should provide. This allows you to reframe your conversation with stakeholders.
Rather than haggling over individual features, seek agreement on the impact you want to achieve, for example, acquiring new users, increasing engagement, and reducing cost. Then consider if a feature request helps you achieve the outcomes within the desired timeframes. If that’s the case, add it to the roadmap. Otherwise, adapt or decline it.
This brings me to the second measure: Learn to effectively say no to stakeholders. I’ve recorded a whole video on this topic, so I’ll summarise my three top recommendations for saying no.
- Actively listen to the person to understand their needs and goals.
- Explore if you can come up with a solution that works for everyone — but don’t agree to a weak compromise and don’t let the stakeholder put you under pressure. Your job is not to please stakeholders but to maximise the value your product creates for the users and the business as a whole.
- Don’t feel bad about having to decline a request. “Innovation is saying ‘no’ to 1,000 things. You have to pick carefully,” as Steve Jobs once said.
Do You Lack Empowerment?
If you cannot decline a request, then you are probably facing an empowerment issue: You don’t have the authority required to effectively manage the product. In this case, engage with the decision-makers in the organisation and help them understand the level of empowerment you need to succeed in your job and maximise the value your product creates.
Learn More
I hope that you found my advice helpful. You can learn more about product roadmaps by:
- Attending my Product Strategy and Roadmap training course and
- Reading my book Strategize.
