AMA: Gainsight Director, Product Management, Pavan Kumar on Product Roadmap & Prioritization

Depending on the complexity of the product being built, and the investment needed initially to get to the MVP phase, I have used several different methods - each having its merits: 1. MoSCoW Method (Must-have, Should-have, Could-have, Won't-have): Break down features into categories: Must-have for MVP, Should-have for secondary versions, Could-have for nice-to-haves, and Won’t-have for now * Helps stakeholders see which features are truly essential for the MVP and manage expectations about what comes next 2. User Story Mapping: Create a visual map of user stories aligned with the user journey, organizing features based on the flow of usage * Clarifies the critical path for the MVP, focusing on core features necessary to support the user journey, while identifying later features to enrich the experience. 3. Impact vs. Effort Matrix: Plot features based on their impact on the user or business Vs. the effort required to implement. * High-impact, low-effort features become MVP candidates, while low-impact, high-effort features can be deferred to later versions. This approach balances value with feasibility. 4. Jobs to Be Done (JTBD) Framework: Focus on the specific “jobs” or tasks users need the product to accomplish. * Helps stakeholders prioritise features for MVP that directly address users’ core needs, postponing non-essential features that don’t directly serve these jobs. 5. Value vs. Complexity Quadrant: Assess each feature for value (how it helps meet objectives) and complexity (effort to implement). * High-value, low-complexity items are ideal for MVP, while high-complexity items can be earmarked for later versions. 6. Lean Canvas or Feature Canvas: Use a Lean Canvas or Feature Canvas to outline the problem, solution, unique value proposition, and required features. * This structured, concise format helps identify only essential features, separating MVP from enhancements for future releases. 7. Kano Model Analysis: (Similar to MoSCoW) Classify features as basic, performance, excitement, or indifferent. * Helps distinguish core MVP features (basic and performance) that are necessary for user satisfaction from features that delight but are not essential for MVP. 8. Rapid Prototyping and Feedback: Build quick prototypes of the proposed MVP to gather feedback from stakeholders and end-users. * This hands-on approach allows stakeholders to experience the MVP in action and focus on high-priority features, keeping less critical ones for later, especially useful in situations where the engineering team need to evaluate challenging concepts. Methods 3 and 5 are especially helpful when Board members / Senior leadership is trying to evaluate the merits of investing in a new area – this type of articulation helps in quickly visualising value.

A straightforward formal approach is better when recommending changes to the roadmap. Its important to cover both the urgency and the impact on previous priorities. To convey changes you may focus on following : * Provide Context: “We’ve identified a critical priority that requires immediate attention due to recent developments. Here’s why it necessitates a reordering.” * Link to Strategic Goals: “This shift aligns with our strategic objectives, supporting our growth targets and enhancing value delivery to our customers.” * Emphasise the Value: “Advancing this new item is expected to increase retention, revenue, and our competitive position—making it a timely addition.” * Acknowledge the Impact: “We recognise the effort invested in [original item] and appreciate your work. Although it’s being deprioritised temporarily, it remains a part of our roadmap.” * Outline Next Steps: “A revised timeline will follow. In the meantime, please reach out with any questions, and thank you for your adaptability as we work towards our shared goals.”

Using a quarterly roadmap format helps keep everyone aligned and focused on near-term goals, especially when sharing progress with stakeholders. It provides structure, helps with predictability, and is great for setting priorities over the next few months. However, for roadmap items more than six months out, detailed capacity planning can be tricky, as priorities or requirements often shift. For these longer-term items, it's usually better to keep estimates high-level and flexible, adjusting details as you get closer. Since our team is moving toward a more agile approach, we’re leaning toward a "rolling roadmap." This lets us update our plans regularly, maintaining flexibility to adapt as new information comes in.

At our company we are transitioning from a quarterly planning cycle to an 'agile' approach. With the advent of ChatGPT and accelerated product development cycles across the industry it has become challenging to meaningfully progress features when they need to be planned months in advance. Here is a short brief on why we choose to make this shift. * Shortfalls of Quarterly Planning: * Lacks flexibility and responsiveness to change. * Locks teams into rigid commitments, making it difficult to pivot as customer needs or market conditions shift. * Relies on long-term assumptions that may become outdated, leading to misaligned priorities. * Can result in wasted resources if original assumptions or priorities no longer hold true. * Challenges in addressing unforeseen issues promptly or capitalizing on new opportunities. * Reasons for Shifting to Agile: * Enables frequent reassessment of priorities and resource allocation. * Supports incremental delivery aligned with the latest customer feedback and market insights. * Allows for dynamic adjustments to near-term objectives as new information emerges. * Increases adaptability by focusing on shorter planning cycles, reducing the risks tied to long-term fixed commitments. * Capacity Planning in Agile: * Avoids detailed capacity planning for items more than six months out, as these priorities may shift. * Emphasises flexible resource allocation based on immediate and evolving needs. * Quarterly roadmaps can still provide high-level guidance, but agile enables fine-tuning and reprioritisation as needed.

To introduce roadmapping in a team new to product practices can be tricky especially when the team has not yet experienced the importance of iterative planning and value delivery. You can confidently take the following approach to align your team with the roadmap planning collaboratively while you transition the organisation to adopt a product first mindset. * Start with some training and explain why roadmapping is valuable, emphasising how it aligns teams and keeps everyone focused on common goals. Use examples or success stories to make it relatable. * Set up a simple, standardised roadmap framework—like a basic template that includes objectives and key milestones—but keep it flexible. Encourage teams to define outcomes over specific features, so they’re more focused on value, and ensure goals are tied to larger company objectives. * Allow some flexibility for teams to adapt the roadmap to their unique needs. Establish a regular review cycle (maybe quarterly) so roadmaps stay relevant and can shift as priorities change. Encourage teams to bring new ideas forward, fostering innovation within a consistent structure. * Then, look at adopting a centralised tool for roadmapping, making it easy for everyone to view, update, and stay aligned across the board. Transparency across teams will help avoid dependencies and keep everyone in sync. * Create a feedback loop (the most important step to keep everyone inclusive and motivated) so the roadmap process keeps improving. Regularly check in with teams to see what’s working and make adjustments based on their input. Retrospectives help refine the roadmap’s role in the organization. Gain executive support to highlight the roadmap’s value and share wins that come from good roadmapping to build momentum and show its impact. Encourage a roadmap-driven culture, where everyone contributes, and reinforce that roadmaps are guides—not rigid plans—so teams feel empowered to adapt and evolve.

Typically, several key stakeholders generally contribute to the roadmap, each bringing unique insights based on their functions, goals, and customer interactions. Broadly they include: 1. Executive Leadership (e.g., C-suite or senior management): They provide strategic direction and ensure alignment with high-level business goals. 2. Sales and Marketing Teams: They bring insights from the market, customer demands, and competition, helping to identify trends and refine positioning. 3. Customer Success and Support Teams: Their feedback often highlights specific user pain points, feature requests, and retention concerns. 4. Engineering and Design Teams: They assess technical feasibility, identify potential roadblocks, and contribute to prioritising based on resource constraints. 5. End Users or Customers: Direct feedback from users, whether through formal surveys or customer advisory boards, offers a real-world perspective on product needs and usability. Since each of these stakeholders are incentivised differently, its very important as a PM to be inclusive of all of them whiling balancing their asks. Here are a few methods I use to balance influence vs. control * First and foremost, it is important to set a clear roadmap governance process: Defining clear guidelines on how decisions are made and what factors are prioritised (e.g., revenue impact, customer satisfaction, strategic alignment) helps ensure that decisions remain balanced and that stakeholders know how their input fits into the bigger picture. * Use Data-Driven Prioritisation: Employ frameworks like RICE (Reach, Impact, Confidence, Effort) or weighted scoring that use quantifiable data to evaluate each feature or initiative. This approach shifts discussions from 'opinions to objective analysis', reducing the likelihood of any single party having disproportionate influence. * Conduct Regular Roadmap Review Sessions: Having recurring sessions with all stakeholders, you ensure alignment and transparency. Stakeholders can voice their priorities, but decisions are made collaboratively based on strategic importance and feasibility. * Set Boundaries on Stakeholder Roles: Define each stakeholder’s role in the decision-making process. For instance, executive leadership may set strategic goals, but prioritisation based on customer needs and feasibility lies with product management. Ensuring stakeholders feel heard and valued is essential for buy-in, even if their suggestions aren’t implemented immediately.

For a product pivot with unpredictable directions, aligning stakeholders' expectations around flexibility and frequent updates is key. Here’s how to approach this: 1. Adopt a Rolling Roadmap: Shift from a long-term fixed roadmap to a shorter, rolling roadmap that focuses on the immediate few months. Emphasise that the roadmap will be revisited and adjusted as insights from the pivot emerge. 2. Introduce Themes Over Features: Communicate high-level themes or objectives rather than specific features or timelines. This way, stakeholders understand the direction without expecting a concrete feature set or release date. 3. Increase Communication Cadence: Set up regular updates (e.g., monthly or bi-weekly) to share the latest insights and shifts in focus. This keeps everyone in the loop and shows responsiveness to the evolving strategy. 4. Educate on Agile Methodology: Reinforce an agile mindset, explaining that the pivot requires iterative learning and adaptation. This could mean frequent course corrections, and regular feedback will guide these changes. 5. Define Success Metrics at Each Stage: Instead of committing to feature delivery, focus on metrics that showcase learning and customer validation, which are crucial during a pivot.

Start with a good understanding each one of your audience. * For executive leadership, emphasise high-level goals and how key initiatives align with the company’s strategic objectives. * For sales and marketing, focus on the features, differentiators, and timelines that help set customer expectations. * Customer support and success teams benefit from knowing specific capabilities, potential customer impact, and key training dates. Tailor detail levels based on each group’s role. High-level themes are ideal for those not involved in development, while teams closer to the work (like Customer Success) need more specifics on features, timing, and value. Engineering teams require technical depth to manage dependencies. Monthly syncs keep everyone informed, while a centralised, accessible roadmap document on a platform like Confluence or SharePoint helps provide a reliable source for updates.

Making a roadmap publicly available can build transparency and trust with customers, stakeholders, and partners. However, it's essential to carefully decide when and what to share. Here’s when it makes sense and how to differentiate a public roadmap from an internal one: WHEN TO MAKE A ROADMAP PUBLIC 1. Customer-Centric Industries: If you're in an industry where customer feedback is essential for product success, sharing a roadmap can demonstrate commitment to user needs and align expectations. 2. Community Engagement: For products with active user communities (e.g., software as a service, developer tools), a public roadmap can inspire collaboration, solicit feedback, and help users plan their own roadmaps around your planned releases. 3. Competitive Advantage: In cases where transparency is a unique value proposition (such as open-source projects), sharing your roadmap can strengthen market differentiation. 4. Investor Relations: Public roadmaps are often helpful in cases where investors need visibility into the product vision and timeline. 5. Early-Stage or Beta Products: For beta versions or early-stage products, a public roadmap can help set realistic expectations about when features will be ready, especially when resources are limited, and iterative development is key. WHAT TO INCLUDE IN A PUBLIC ROADMAP A public roadmap typically focuses on high-level themes and goals, rather than specific dates or technical details. Here are the elements often included: * Major Features and Goals: Broad categories like "improve security," "enhance user experience," or "expand integrations" without too much detail on technical specifics. * Timelines in Quarters or Years: Avoid specific release dates, which can create pressure and expectations that are difficult to meet. Instead, use general time frames like "Q3 2024" or "Mid-2025." * User-Centric Benefits: Frame items in terms of customer benefits rather than internal milestones. For example, "simplified onboarding process" instead of "UI revamp." * Current Status Indicators: Some companies use labels like “Research,” “In Development,” and “Released” to give a sense of progress without specifying details. WHAT TO KEEP IN AN INTERNAL ROADMAP The internal roadmap is generally more detailed, with specifics that aren’t ready for public release. It often includes: * Specific Features and Technical Requirements: Full feature descriptions, technical specifications, and dependencies are better kept internal. * Dates and Deadlines: Include precise dates and expected completion times to ensure accountability within the team. * Risk Analysis and Contingency Plans: Internal roadmaps often contain risk assessments for certain initiatives, which help teams prepare for potential issues. * Cross-Functional Dependencies: Details on resource allocation, team responsibilities, and cross-functional dependencies are essential for internal planning but may overwhelm or confuse external audiences. * Strategic Initiatives and Experimentation: Include experimental or “nice-to-have” items in the internal roadmap but avoid creating external expectations for features that may be cut or changed.