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.

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

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

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.

This is a difficult question and generally depends on the guidance which comes from upper management and business. If the company is focussed heavily on growth, and your product is a part of the growth initiative then your roadmap chunk would be heavier on the prospects Vs the exiting customers. Whereas in other cases where the company is focussed on user retention and getting more value/customer then it might be heavy on the existing customers. Here are the two factors which primarily influence this decision - * Type of feature and product * Business goals and objectives

Based on the type of stakeholders you are communicating your roadmap, the level of detail will differ. Here are the different examples and scenarios: * Upper Management and Secondary Stakeholders - High level of the what and why and when * Teams involved directly to build features and/or direct consumers of the feature - Detailed requirements and dependency management You can use different delivery mechanisms for the roadmap. Async email/slack communication and/or Inception meetings