|
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 |