AMA: GitLab Director of Product Management, Jacqueline Porter on Product Management KPIs

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

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. 

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. 

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. 

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. 

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.