Farheen Noorie

That is a hard situation to be in. Here are some options to try * Communicate your roadmap to the executive team organized by segments, showcase what you can prioritize for a segment and what you cant with the latter focusing on multiple priorities across various segments being the primary reason why you can't create focus for your team * Create a focus segment for a given planning cycle, eg: Q1 on Segment 1, Q2, Segment 2, etc * Identifying common use cases across segments * Identifying platform features that enable multiple use cases across segments * Prioritizing features across all segments with the help of a framework (ICE: Impact, Confidence, Effort)

There are lots of frameworks available for prioritization. The key is to find the one that works the best for your product function and the needs of your stakeholders. Most frameworks are directional and product folks should use product sense and intuition to build a roadmap that makes the most sense for their customers and stakeholders. Some things that I consider * Business impact * Customer painpoint solved, not all customer pain points are equal * Investment to build * Cost savings for the business * Defensive feature a.k.a absolutely need this to be at par with competition * Offensive feature a.k.a sets us ahead of the competition * Company strategy A number of these are interconnected eg: if a feature solves a big customer pain point it most likely will return in a big business impact. How you weigh them against each other will depend on your product function, company strategy and your organization's role in it.

Prioritizing only for Sales teams can lead to traps where you are building Product one customer at a time and these products may not speak to each other. On the other hand by not including Sales you will be missing out on a core team that speaks to your customers every day. My recommendation would be to * Take Sales and other stakeholders along the journey * Conduct joint prioritization sessions with Sales, Customer Success, Strategy, Design and Engineering. * Get them up to speed on the strategies you are considering for your roadmap and any qualitative and quantitative insights for each strategy. These should include any feedback Sales or other stakeholders have provided in the past, what you have heard from your customers directly, and any new ideas that you want to test and iterate on * Brainstorm ideas against the strategies presented * Provide them with a framework for evaluating ideas eg: if an idea impacts more than 1 customer, it is a higher priority, high revenue impact leads to a high priority * Invite feedback and discussion In addition to the above encourage a feedback loop for all stakeholders eg: When Sales is proposing an idea, partner with them on revenue modeling and commitments. Use the performance of previous ideas as an insight for your next round of planning.

This is possibly a good application of the RACI framework to determine which of your stakeholders have influence vs Control * Responsible: Think of your product, engineering, and design leadership. They should have the same goals and priorities as you. Hence their feedback as well as endorsement is critical * Accountable: These are your working partners, your engineering, product designer, content strategist. You want to create confidence with this group because they are responsible for delivering your roadmap. They can give you ideas on solving a problem or feedback on the feasibility of a solution. * Consulted: This bucket is for teams and stakeholders that you engage with to create your roadmap. It could be Sales, Customer Success, Product Strategy, Voice of Customer etc. They definitely influence your roadmap but do not control it. Hence its critical to communicate your rubrik for prioritization and create a space for feedback. * Informed: This group is everyone else who may be interested in learning about your roadmap

How you communicate your roadmaps depends on who you are communicating it to plus the existing processes in your organization. Here are some examples * Executive Staff: I have had success in creating decks for E-staff members highlighting the specific items that they are interested in. I have presented these decks in a meeting setting to gather feedback and also setup clear expectations on the Anti Roadmap (What we are not going to do) * Stakeholder Teams outside of your group: My favorite is a readout deck that contains your roadmap and details about specific initiatives. This can be sent out in a product-all/company-wide slack channel * Your own team: This should be the most detailed version of your roadmap. Usually most teams prefer their roadmap to be directly reported out of their primary product dev tool eg: Jira. This version usually has a look ahead view/backlog, current execution progress eg gantt charts

My strategy would be to either * Give them enough context and try again for guidance * Change the question So how do you do either of those? Instead of asking for guidance on the roadmap, you can try one or more of the following * Is the roadmap too detailed for your C-team? Instead can you get feedback on strategy vs roadmap? * Setup sessions with the C Staff where you can present qualitative/quantitative data and the resulting strategy. Encourage discussion and feedback. Then go back to the C-team for an endorsement for your strategy * Do you need guidance on the roadmap or the tradeoffs that you have to consider? The C-team maybe new but they are usually excellent at pattern matching and can help with tradeoff decisions * Specifically talk about the tradeoffs you are weighing against and your recommendation as well as the rationale for it. Seek feedback and endorsement * Limit the discussion to "big rocks"

Product Management is a bit hard to list skills for because product managers wear so many different hats and each company has a different way on how they think of product management. But I do think there are some broad skills that PMs should have or build as they think of their career. 1. Hustle - This is the number 1 skill that I look for. If you have this everything else follows or can be built. 2. Empathy - Understanding your customer and being able to put yourselves in their shoes 3. Storytelling - Communication is key for product managers but I think its super important to be able to tell effective stories/narratives. 4. Prioritization - As a PM you need to make prioritization decisions everyday. Its key to have a good framework on how you are making those decisions and clearly socializing the framework as well as the decisions with your stakeholders and partners

Technical questions are usually asked in a few contexts within a PM Interview. * Understanding a PM's experience working with engineers: These questions are usually asked in rounds led by engineering stakeholders. A typical question concerns making a hard prioritization decision due to a technical constraint. A PM is expected to know enough technical details to understand the various choices, their pros and cons, and make prioritization decisions accordingly. * Data Analysis and SQL: Most PMs do some level of data analysis themselves. Especially for early startups or lean teams where there is either no or insufficient data support, PMs are expected to know the basics of SQL, understand and prioritize where they need instrumentation, and even create some reporting/dashboarding for themselves and the company. For such a role, it's quite common to have a round on data analysis and sometimes even SQL. * Platform, Infra PM roles: If you are applying for a role that is platform or infrastructure-specific, it's expected for PMs to have a degree of understanding of the same. Technical depth also depends on the role (early or mid-career). For eg: Dev API PMs, Authentication PMs etc.

Usually I would begin with understanding 1. What are the key customer pain points that I am trying to solve for your customer? Those are my metrics in 9 out of 10 cases 2. Why is my product team funded? What problems am I solving for the business? Once I have the initial list, just like all things product management I PRIORITIZE. What matters the most vs what is not as important. Now for every item in the list its also crucial to think through what are the counter metrics. A crude example would be, I want to have more paying customers but a counter metric will be revenue from these paying customers. Lets say, I discount my product enough that sky rockets the number of paying customers, a good check and balance would be the total revenue we are getting from these customers. 

1. Rates: To me without absolute numbers, rates may paint a false picture. Let me explain with an example. Lets say you have a trial experience for your product and you are responsible for the cart experience and thereby conversion rates which is measured by number of paid customers/number of trialers. I would suggest that instead of rates the north star metrics should be a combination of number of paid customers as well as Average Deal Size (ADS) per paid customer. A conversion rate is a good number to track but may lead to wrong hypothesis when you see not normal trends in either your numerator or demonimator. In this example, conversion rate will go down if the number of trials significantly increases or decreases. If you are responsible for rates make sure that you own both the denominator and the numerator of that equation in order to truly able to influence a positive change 2. Fuzzy metrics: As the say "What cant be measured, cant be managed". Metrics that are not explicit like Customer Happiness and NPS are not possible to measure. I'd go a step further to challenge why should one even measure those metrics and are there any core metrics that can be measure successfully. An example would be instead of measuring Customer Happiness, lets measure Customer Expansion because happy customers expand.