[polote]

I'm really wondering in which world the product managers are living in.

What is the goal of a roadmap ? This article doesn't even touch a point on it.

The goal is : In any company there are people who want to have an answer to the question "what comes next on your product?". Those people can be any of: CSM to prepare a presentation for customers, bored customer who want to talk to CSM, Sales people who want to impress their prospect, Execs to tell the public and investors that things are moving. Do those people care that the roadmap is going to be respected ? Not really.

The roadmap is not a product management tool, it is a communication tool. So my advice to PM, you are asked to create a roadmap ? Put all the things in the roadmap that people want to hear, forget about it, and continue working on what you were working on.

[alexpetralia]

This is directionally right but practically wrong.

You will be a disliked product manager if you continually tell people what they want to hear, but never deliver on it.

Rather, tell (read: persuade) people what they need to hear. Your job as a product manager is to negotiate and reconcile high-level plans and low-level execution.

[penguinsonmars]

Hi, author of the article here.

Really interesting points, thanks. Your comment made me realise that I failed to point out an important underlying argument of the article: Product Roadmaps ≠ Release Plans.

Goal of a roadmap = Communicate the most important objectives for the product team (therefore should be based on and closely tied to the company’s strategy)

Goal of a release plan = Communicate what features are being release next and when, so that other functions can plan accordingly

Only both of them together provide a comprehensive view over what the product team is working on. What most stakeholders need to know is “What comes next” and “when”, so they can plan their work accordingly. So the mistake we (Product Managers) make is to start putting feature requests and due dates on our strategic roadmap. And this is exactly where the problems with roadmaps are created, as described in the first part of the article.

With regards to putting “all the things in the roadmap that people want to hear, forget about it, and continue working on what you were working on.”, I would strongly advise against that for three reasons: (1) It encourages Design by Committee (2) The other teams will have a hard time trusting a product team that puts their requests on the roadmap but consistently fails to deliver on them. It’s better to create a shared understanding of where their requests fit in the overall strategy. (3) And, as redwood pointed it, it poses the risk that sales will sell roadmap commitments that you can never deliver on, which decreases trust with customers.

Curious to hear: How would you expect the product team to communicate their objectives and progress to the rest of the organisation?

[polote]

You have to understand why the rest of the organization wants to know what the product team is working on. There is a different needs depending on the type of company you are working at:

- If you are working in a saas b2b smb or b2c, usually as a product team you don't want to commit on anything, so the rest of the organization (except leadership) wants to know if a feature, is on the list of things the product team is thinking of or if they don't plan at all to work on a feature. And if you are very good you can split features in 3 buckets : things you are working on, things you are thinking about, all others. And for leadership, basically they don't really have to know what the product team is working on, it is on them to decide the vision of the company. The product vision will just represent the company vision in another angle

- If you are working on saas b2b enterprise. Things are different. There need to be visibility on what the product team is going to work on during the next 3 years. That doesn't need to be really accurate, but needs to reflect more or less what customers want to hear. There is also a need to know for users facing teams (support, CSM, ...) if a bug is, being worked on, will be at some point, dont care.

In any way, one thing you never want to communicate is a date of release of anything.

A release plan is only needed internally between the close collaborators of the PM: eng lead, product marketing, knowledge managers so that they can plan beforehand things that they need to produce on top of your product

[redwood]

As much as I agree with you, it's better to put on the roadmap for things that you've done recently than what your employees want to hear... After all you don't want your employees telling customers something's coming promising a future that may not come. We all forget that our customers don't even know what we've already done and we can always sell we've already built

[polote]

> After all you don't want your employees telling customers something's coming promising a future that may not come.

Every companies do that all the time. And there is no way to prevent that. It is impossible to predict 100% accurately things that you are going to build in 6 month