Didier Varlot

The most important is to first listen to their worries regarding your project and determine the core problem that could be tackled solving more than the worries of one of the stakeholder, but most of the worries of nearly all the stakeholder. The stakeholders are as the users giving feedback, they see the problems from their point of view and express the solution that they would like to be implemented. I usually use the following process: * Listen to all stakeholders * Analyze the information received in term of worries not in term of solution (detect what they want you to solve for them, don't consider the solution they may have given you) * Map all the information received from the stakeholders to see the trends and the common worries * Verify if the product or project you are presenting them solves these worries * if it doesn't, you need to find a strong data argument to sustain your project or pivot and adjust your project to better fit to the expectations and worries of the stakeholders. * if your project solve some of the worries of the stakeholders, then present it in those terms * as far as their worries will be addressed, the stakeholders will be naturally aligned But don't allow the stakeholders to tell you the solution, it would be biaised. In fact, this is not so far from what a product manager does with the user feedback.

This is the role of the product managers to bring up what the users want to see built. This is usually not good practice to have the executive giving too much guidance. The executive should give the vision, and the product managers should determine the features on the roadmap based on the prioritization they determined with the users to achieve the vision. It could be an advantage when the leadership doesn't provide guidance as it prevents the bad top-down approach of product management. The executives keep an open-minded approach and fairly evaluate the proposals made by the product management.

The Insight I gained from internal stakeholders helped me get a more precise idea of how to prioritize the projects. User feedback is really important, but it is also very important that you don't let the user drive your strategy. This is where the insight from the internal stakeholders becomes important. It ensures that your strategy is aligned with the company's global strategy. Be customer-centric, not customer-led As a product manager, you need to be customer-centric. You need to be obsessed with your users and find solutions to their problems. But this doesn't mean the users shall drive what you build through their feedback. Integrating user feedback and internal stakeholder insights allows the processing of the information to align your roadmap to the best mix of company strategy and customer needs. What kind of insight should you be looking for You may have some ARR or MRR information linked to Feature requests, but learning from Solution Engineers, Customer Success Managers, and Technical Support what the problems most encountered are allows you to use different input types to better prioritize your projects. Listening to sales to understand what lack of feature made one deal fail allows one to understand what lever is needed to close more deals. Finally, listening to the board allows you to understand the company's north star and strategy and align your project to better serve this strategy. Communication is two-way Communication is a two-way game. You also have valuable insight to share with the internal stakeholders to help them perform better. You should never hesitate to share with the internal stakeholders any insight that you gain from your different research. They will only appreciate you more and will be even more eager to retribute your inputs with more insights.

From my experience, a historically tense relationship comes from a conflict in the sense that both functions have two irreconcilable points of view or courses of actions as necessary to fulfill their objectives. Each one sees the other's point of view as preventing them from achieving their objectives. I would first advise listing the undesirable effects of such a tense relationship and then drawing a logic tree to find the root cause of this tension and identify the conflict. Several types of trees can be used, but one that I have seen as particularly efficient is the Current Reality Tree (https://en.wikipedia.org/wiki/Current_reality_tree_(theory_of_constraints). From that tree, one can deduct an "evaporating cloud" (https://en.wikipedia.org/wiki/Evaporating_Cloud) to illustrate the conflict. With this in hand, I would meet with all the parties and analyze the two graphs, and usually, this allows for finding which hypothesis was wrong and generated the conflict. Correcting the situation and improving the relationship between the two functions is then easy. This course of action may be difficult if you are perceived as not being an impartial party. if you have never used such tools, it is also advisable to get help from someone who has already created some.

I start working as a product manager from one unexpected opportunity from a career of 35 years of project management. The role of a product manager is one of those less well-defined I have ever encountered. It can mean very different kinds of jobs in different companies. I would first advise reading about the experience of actual product managers in various companies via their blogs or some articles. and I would then consider if this is what I want to do. I would try to reinforce some of the skills you will need: * Be data-driven: You need to sustain all your decision as much as possible with data * But have gut feeling: You also need intuition, and as soon as you have a strong intuition, launch experiments to confirm or contradict it. * No need to be too technical: there are people to be technical. Be technical enough to understand what is explained to you. * be passionate: be passionate about the product, and be passionate about the users. You will be their ambassador. * Sharpen your writing skills: You will write a lot, much more than you imagine, so train to write clearly to be understood. Speak with product managers whenever you can meet one and interview them as you would interview a user when you will be one of them. Try to find a mentor (someone with a product career) and have regular sessions with him to help you get into the flow of product management.

The main risk is constantly deprioritizing the Compliance and maintenance work and building a tech debt at such a level that it will take forever to pay it back. There are two kinds of situations: 1- you do not have a vast tech debt, and you can manage compliance and maintenance work by allocating a fraction (10 to 30%, depending on the amount of work)of your capacity to this work. The remaining capacity work on development-related work. Alternatively, whenever a developer touches a part of the code, you impose that he improves (or maintains) a part related to what he just changed. 2- You have let the tech debt grow out of control: you will have no more choice. You will need to allocate your capacity to pay the tech debt before you go "tech bankrupt." When the tech debt is back under control, you can apply the rules stated in 1st paragraph.

When departments have different opinions on prioritization, the product manager needs even more to have a transparent and data-driven prioritization method. Sales is a very important source of prioritization, and the art of product management is to find the right balance between supplying features that will unlock further sales, features that will please existing users, and resolving bugs and tech debt. The old say "it is less expensive to keep an existing user than to acquire a new one" remains true and needs to be embedded in the method. But a good product manager is one who knows how to stay firm with his prioritization in front of all stakeholders without confronting them.