Such behavior of product teams might be overlooked for a while in a large company with a very successful product that is already a market leader and makes huge profits. However if you are a company trying to build a product for a new market or if you are a small company working hard to keep your customers, this sort of behavior could kill your company or at the very least your product managers our of work in a couple of years. Slowly but steadily, product managers who build features without knowledge of user journeys and without tracking usage will slowly lose investment and their value to the organization and eventually their job. In other words if one wants to succeed as a product manager of product leader in the long run, user focused and data driven roadmap planning is probably the only way to go.
Changing behavior of product teams is very hard. But there is a framework that might work. In my early experiments with a user journey driven framework for roadmap planning, I see acceptance from various teams and acknowledgment of value from product managers. This is the framework. Ask your product teams, including product managers who build features, product managers who are custodians of existing features, user marketing teams that promote your products and analytics teams that instrument your product for tracking and reporting to think about all their features, assignments and campaigns in the context of a user's journey. Here is an example of a user journey  where multiple teams contribute.
Ask them to build a collection of the top 5 users journeys that their features form a part of and estimate the impact of those user journeys on product objectives. To do this first, they have to think about the user. Second, they have to think about the other product managers and teams that they need to rely on and collaborate with. Third they need to focus on how much engagement does their feature bring today. Fourth, they need to collaborate with the analytics teams to estimate the potential impact of the user journey on product objectives. Fifth, they need to identify instrumentation gaps in their features and think about building just the right instrumentation for reporting purposes.
During this process product teams will realize that a feature cannot become successful on its own. It required some one such as a user marketing teams and other upstream features such as home page or mobile channel to promote it. User marketing teams will realize that there are good features that bring value for customers not being promoted. Product managers will recognize that their feature usage is not being tracked by the reporting teams. This will help them convince the reporting instrumentation teams to build just the necessary instrumentation. Product teams can communicate a collection of user stories to product leaders, product marketing and sales so that they sell what has been built. Not what they cooked up. Customer success teams will be happy because they will get accurate reporting on user journeys that matter without having to wrestle with the analytics team to dig up data every time they have to report progress to a customer.
I am not saying this is easy. However it has worked in the past for me and my new experiments are showing signs of more promise. If done right, this approach could be the difference between your small software company staying in business or going out of business.
If you don't have a framework for evaluating features, product teams will use phrases such as 'customer commits', 'table stakes' or 'strategic project' to justify the investment. While customer specific features are part of every product team's work, when you hear such phrases from more than 25% of your product managers, as a head of product, you should be very concerned because you will end up with a hodgepodge of features that bring no value for your users. If you are a CEO, and you hear phrases like these from your product team very often, you should be very concerned because your investment is being squandered by a team that is inexperienced and has no framework for execution towards your business goals.
 The user journey discussed above is for a business to business to consumer (B2B2C) product company. Many enterprise software companies fall into this category. I am making the assumption here that you are a cloud product company and your customers pay you if and only if you can prove to them that their employees are using your product to either stay compliant, save money or help you make money.