AMA: GitLab Group Manager, Product, Jacqueline Porter on Product Roadmap & Prioritization

I typically start from what are the annual business targets set by the company to answer this question. Oftentimes, the sales organization, CEO, and professional services organizations have targets around expansion, new logo acquisition, and win rate which will help portion out what the backlog needs to be to support the business goals. In absence of these targets set by leadership, I would use a RICE framework (https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/) to establish what is the highest value driver for the business. That way I am not really focused on driving whitespace or greenfield, rather on what will drive the most business results in total. 

Since I have joined GitLab, where our product roadmaps are publicly accessible (https://about.gitlab.com/direction/), I don't think I will ever go back to internal roadmaps. A public roadmap as a number of benefits: 1. You keep everyone internal to the company aligned and up to date on what the product organization is building 2. You can encourage contribution (if you use open source) from the community or customers to help build your roadmap - delivering on a dual fly wheel mechanism 3. Reduces external and field team confusion on what the business is delivering. If you use disclaimers and set expectations that planning is ambitious and can change, then public roadmaps really have minimal negative consequences. Keep in mind, security fixes or issues that contain sensitive data are confidential and have regulatory/meaningful business risks, so these types of planned work should be discussed in general terms without compromising the safety of the company. 

Wow, what a great question! I like to think that product marketing offers a different lens to the market landscape, competitive positioning, and product launches. As a result, I typically rely on four main activities: 1. Include product marketing in the annual product theme and road-mapping processes 2. Have a set sync with the product marketing to review shared performance indicators such as the top of funnel leads, website performance, and release post/notes engagement 3. Assign tasks and responsibilities to Product Marketers in the Release Post/Notes process where they can contribute to the positioning of value before the content is released to the public 4. Have a defined set of launch processes for different categories of release features. These can be organized by impact, by pricing changes, or by a predefined cadence around a major industry event. Either way, coordinate with product marketing around the content, marketing campaigns, and sales enablement that will be required to support the product post launch. 

This is certainly a tricky one! I like to think of a roadmap being made up of four sensing mechanisms: 1. External stakeholders - investors, board members 2. Market landscape - competitors, analyst reviews or reports, and prospects 3. Internal stakeholders - CEO, leadership, cross-functional teams 4. Customers - install base or existing paying and free users When you are able to attribute the sources of your roadmap features transparently, it becomes a trade-off conversation with executives - rather than a top-down mandate. Being able to show that certain bodies of work have been sourced from competitors or analyst reports which show that you may be lagging behind, for example, is a great dialogue to have when it comes to prioritizing the input from the executives. If the feature request should get done because you have applied a RICE score or some other type of validation, sequencing behind the most impactful items will be a great way to accommodate the request while delivering the most impact. 

I love this question - the audience is everything! I typically have 3 pre-prepared altitudes for my product roadmap which correspond to a specific persona and time horizon 1. Annual Thematic Roadmap with Big Boulder Features - Executives and Buyers of Product: This roadmap has a conceptual, initiative-based view. So, it features connected narratives of multiple features for what the themes of the roadmap will deliver for a buyer or an executive interested in the ROI of the roadmap. 2. Quarterly Feature Review - Field Teams/End users: For internal teams that sell the solution and are working with technical personas, I have a quarter by a quarter snapshot of the features that are most relevant for the day-to-day work of the end-user. So, I like to think of these as Rocks - smaller more tangible features that can be used. 3. Community contributor monthly roadmap - Internal technical teams/Community members that will contribute to the roadmap: This is the most granular and technically informed roadmap that shows what the team is working on in the current month and how users can potentially contribute to the roadmap. This is what typically is considered a sprint review and has minor, iterative deliverables to enable adjacent product teams to the core features being delivered that month. I will use a community page, release notes, and internal handbooks to publish these different POVs for the organization and others to consume readily. 

Well, I often incorporate multiple sensing mechanisms into the roadmap - the field and sales team are definitely an important lever to drive revenue, which really is why product managers exist. So, a tactic I use is to show how much of my engineering capacity is dedicated to enabling revenue, technical debt, and long-term vision. The long-term vision is often a "big bet" that is about making a splash in the market or analyst review. Oftentimes, sales and the field are supportive of carving out time for long-term bets because analyst ratings, whitepapers, and affirmations of the product in the market are great supports for the sales cycle.