Jacqueline Porter

Jacqueline PorterShare

Director, Product, GitLab
Strategic product management professional with eight years of product development leadership experience. Offers outstanding talents in SaaS lifecycle processes, change management, risk mitigation, ...more
Content
Jacqueline Porter
Jacqueline Porter
Director, Product, GitLabJuly 12

Objectives and Key Results are meant to encourage cross-functional alignment and collaboration. In product management, it is essential to think of OKRs as a method for prioritizing scope that will help drive the top business KPIs, so that your product roadmap has a built-in mechanism for considering how to help the business succeed. 

The below example is one I have seen work well: 

  • Top Level Business Objective: Increase enterprise ARR by 20%
  • Product Key Result: Deliver paid feature X to help compete and close 3 sales pipeline deals
  • Product Key Result: Implement use case documentation for paid features to support Field Team
Jacqueline Porter
Jacqueline Porter
Director, Product, GitLabJuly 12

Many product organizations focus on delivery, Net Promoter Score, and user counts. One metric that I think is important to always consider is your availability and consistency of user experience in the performance of the application (latency). Using Error Budgets and thinking about uptime critically as a Product Manager helps put into tangible terms the cost to the user when your offering does not meet a performance or uptime standard. If you are offering mission-critical software, it is essential to be responsive and reliable. Lack of responsiveness and reliability can erode your base over time. 

Jacqueline Porter
Jacqueline Porter
Director, Product, GitLabJuly 12

Engineering and Product are two sides of a smooth sailing R&D engine. I have seen a number of ways to split the accountability across these groups: 

  1. Say/Do ratios - which include hitting a certain percentage of items that are delivered in an iteration 
  2. Merge Request Rate - which is about throughput and encourages shipping small and fast 
  3. Cycle Time - which is the time it takes from ideation to production, or any other time spent in a certain workflow status 

These three are my three favorite metrics for ensuring you are delivering the right things. Some metrics that don't seem to work very well: 

- Number of tickets closed in a time period 

- Number of items in a release notes/change log 

Both of these can result in perverse incentives, where people are adding issues to close them or including irrelevant items in a changelog or release notes to get more credit for delivery. 

Jacqueline Porter
Jacqueline Porter
Director, Product, GitLabJuly 12

This is a great question. I am a fan of actually being ambitious and setting unrealistic targets or stretch goals and seeing where we end up in the first couple of reporting periods. To get a dose of realism, you can always reference analyst reports and right-size your total available market vs. serviceable market and current penetration into the new market. I don't advise setting realistic targets when entering new markets because that can lead to complacency instead of innovation. You can also leverage a range, and use a moderate case and best case target achievement. For example, if you are offering an existing product with 1M marketing analyst users to a new persona like project managers, you would want to evaluate what is the total presence of project managers in your customer base or industry. If you see that you only have 2K project managers in the current user base, but there are over 3M project managers in the industries you are serving, you can set an incremental goal somewhere between 2K and 3M, but you wouldn't want to set a 3M project manager user target right out of the gate since you have no idea how many of those users are actually servicable. 

Jacqueline Porter
Jacqueline Porter
Director, Product, GitLabJuly 12

The worst KPIs are vanity metrics that have no ties back to actual adoption or business metrics. I once had a product manager commit to hitting a number of emails a notification system was supposed to send in a 30-day period. Without context, this seems like a great metric to track for volume, except the total count of emails tells you nothing about how many people are getting value, if they are getting value, if they are recurring users, or if the emails are contributing to user satisfaction. This can certainly be a metric in the toolkit, but not a KPI for a product line. 

Jacqueline Porter
Jacqueline Porter
Director, Product, GitLabJuly 12

Oftentimes as a Product leader, I am tasked with cross-functional work across Go-to-market, R&D, and finance. One of the most critical aspects of cross-functional is to drive clarity. This can be done by following three practices: 

  1. Have a published single-source-of-truth charter where current status and archived information live. This repository can be a word document, google sheet, or even a static website. You will want to add "pins" to any relevant documents or links at the top for easy access. 
  2. Determine a regular cadence for team syncs 
  3. Provide continual async updates and link back to the SSOT (number 1) so people who are unable to attend syncs can reference the materials later 
  4. Overcommunicate and overshare the goals and results of the cross-functional work 

Point 4 is one to belabor. This overcommunication creates a sense of focus, collaboration, and clarity on purpose and intent. By using consistent communication, people feel like they understand how they can contribute and where they can support. 

Jacqueline Porter
Jacqueline Porter
Director, Product, GitLabApril 6

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. 

Jacqueline Porter
Jacqueline Porter
Director, Product, GitLabApril 6

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. 

Jacqueline Porter
Jacqueline Porter
Director, Product, GitLabMarch 31

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. 

Jacqueline Porter
Jacqueline Porter
Director, Product, GitLabMarch 31

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. 

Credentials & Highlights
Director, Product at GitLab