Aindra Misra

Your roadmap should have just enough details on the top level that will explain the below three things: * WHAT? * Summary of the problem, high level potential solution and the link to resources (documents, diagrams etc) * Why? * Value prop and mapping with the business goals and priorities * When? * Delivery time * It's great to break down the delivery time into smaller chunks and have clear milestones for the phases. The rest of the details and granularity should be out of the roadmap and into execution process/tools.

You should try to split your stakeholders into two categories: * Primary Stakeholders - The ones which will be directly benefit or impacted by your work. These should not just be your customers who will use the product, but also the teams who will help get this work to the finish line, upper management who need to report this work to higher above. Primary stakeholders can be of various functions - PMs, eng partners, user researchers, design, PMM, leadership * Secondary Stakeholders - These are the ones who will be indirectly impacted by your product. The teams who are at the tailend of the consumption pipeline of your product. How to decide if something should land on the roadmap - There are a few factors you should consider while building a roadmap: 1. Business impact - How much value it is delivering to the business. How does it map to the top level business objectives and key results 2. Level of effort - Sometime the feasibility and level of effort can help you make a decision 3. Tactical Vs Strategic - Sometimes tactical work is throwaway work in the long term, sometime it's not. You need to gauge that and decide accordingly If you want to use a framework for prioritization, I would recommend RICE - reach, impact, confidence and effort.

Here are the steps I take for end to end feature prioritization - 1. Talk to various stakeholders (sync and async) and collect a list of features from them with the following details - Impact, expected ETA of the request, mapping with business goals 2. Talk to the engineering team and get a list of the foundational/tech debt features which they want to implement to improve efficiency of the team and create a modern tech stack 3. Align the business with the capacity split between business features and foundational/platform/upgrade features (typically 80-20% split) 4. Get the level of effort from the teams 5. Stack rank them based on the RICE framework or similar and put a cut off line based on the capacity split identified in Step 3 6. Share it with the larger group of stakeholders via Miro/ Inception type of exercise and give an opportunity to stakeholders to make request to change and/or ask questions 7. Finalize it and broadcast it with larger group of stakeholders PS: I am a Platform PM so my process might be slightly different than the growth PMs or other types of PMs

This is a common case scenario. Here are the few things I would take into account when providing a reset of expectations: 1. For the items too far out in the roadmap should be provided with an asterix and tentative disclaimer 2. Ensure that as soon as you know that there is a possibility of a pivot, start communication informally with the primary stakeholders to avoid surprises and backlash 3. Once there is clarity on the pivot, come up with a plan to explain the following things in the communication - 1. Why did we pivot and the data behind it 2. Potential benefit with the new route or the pitfall with the old route 3. New plan

This depends on the type of product. Here are the examples of the scenarios - 1. Customer facing product - PMM (Product Marketing Managers) is highly involved as soon there is clarity on the product requirements and discovery phase is mid way. They start drafting press releases and/or company wide or eTeam readouts/approval docs and start collecting feedback from the PMs 2. Platform product/internal/technical - They are less involved depending on the downstream consumption of the technical product. If it is indirectly touching the customer facing functionality, then they get involved to understand some technical details that will help them draft their deliverables

1. Identify and decide on what kind of PM role you want to get into - Growth PM, Platform PM, Domain specific PM.. 2. Understand the details and day to day of a PM role and get clarity on the hard and soft skills needed to be a good PM 3. Start building your hard skills and follow the right PM influencers on social media and consume their content 4. Build your resume based on what you learn from 1 to 3 above and start applying

It should be an iterative process and start off with creating a product mindset before enforcing roadmapping process to your company/team. Here are the steps, I would recommend: 1. Create awareness about Product roadmapping and benefits - Hold awareness sessions and mandatory trainings for the PM team and build a product mindset 2. Create a lightweight and flexible roadmapping process to begin with as a phase 1. Enable PMs to drive the roadmap and share it widely. Guide them on how to do it 3. Start sharing roadmaps with wider stakeholders during all hands etc with XFN stakeholders and make it as a routine 4. Enforce a roadmapping tool like Productboard, as a part of Phase 2 of the roll out and create a stricter process and incorporate it in the PM evaluation process Roadmaps should be supplemented with measurable OKRs which is very critical to evangelize and show value of the roadmap and influence stakeholders to follow the process.

Ability to tell the story and connect the dots. As a PM, if you are not able to tell your story in a crisp and clear manner with the right amount of details, and tailored to the audience - then how much good you are at your other PM skills, it will be difficult for you to get recognition. I feel that this skill is quite underrated and as you get into more technical PM roles, this becomes harder and harder as the business leaders and the non tech stakeholders are further away from your world, and influencing them and telling the story without using tech jargons is where it becomes hard.

As you progress through the PM ladder, the TL:DR is that you will be less in the weeds with the day to day functioning of your squads but rather be working on long term planning and strategy on a larger scope to deliver business goals. Some examples: 1. PM 1,,2, Senior PM - Prioritization for 1+ squads, scrums, JIRA hygiene, align with team goals, quarterly planning 2. Group PM - 1-3 year strategy, people management of PMs, larger scope with 2-3 products in the portfolio, ideation, opportunity sizing and building proposals for future initiatives 3. Director, VP, Senior VP - As you climb up the ladder, scope increases tremendously and you are thinking on higher altitude and how you and your teams can impact the business needle

Engineering counterparts are not easy to influence as they come with some kind of bias that PMs are not there to help them but to add processes, hierarchy and more meetings to their day to day, without knowing their pain points and/or technical stuff. Based on my experience, here are some of the qualities you can develop to influence and impress your eng counterparts * Get hands on wherever you can - In the age of AI, there are a lot of nocode tools to build prototypes etc (Cursor being one). If the eng folks see you being hands on and trying out these tools, they tend to feel more confident with sharing technical stuff with you and trust you more with their decisions * Pitch your value as a PM to them and how you can help their day to day - I use two things to pitch my value - one is to broadcast and share the hard work they are doing and translate it into business imperatives, so that they can get more visibility and credit for their work. Second, tell them that you will act as a shield from the noise and you can create focus and prioritization based on value instead of doing low value work. These two ideas on elevator pitch has been working well for me during my career. Note: You can just pitch the above stuff and not implement or execute them. If you have to lead by action for eng to gain trust in you Explicitly mention to them that you are not here to introduce more processes and ask for level of effort