How do you think about shared KPI’s with your engineering team? And what are ones that product teams often miss?

I'm a huge fan of all success metrics and OKRs (objectives and key results) being shared between the core cross functional working group.

Of course there will always be some that don't match up; I'm thinking about some SLAs, uptime, latency type KPI's that your engineering team tracks. But by taking them as shared and getting your buy in on those you'll much better understand the deployment of the engineering resources and how best to support that team.

All cross functional teams are critical, but the engineering team is the most critical :)

Product teams in my opinion consist of product, engineering, and design (at a minimum). With that said, product KPIs should always be shared with engineering since what they are building essentially impacts the KPIs of the product in question. All the work that product teams do should always build up back to the overall company/business unit objectives (even if those metrics are more technical).

• Shared KPI's between engineering and Product Management is a great way to build high quality, scalable products that are delivered on-time that bring customer delight. This also builds camaraderie and encourages teamwork towards a common goal.
• There are different ways of achieving this. e.g. PM's and Engineering can own certain KPI's. While both teams can also individually own their own KPI's. Not all have to be shared
• Generally PM's would own Company, Business, Acquisition, User Engagement and User Satisfaction KPI's. Examples are: MRR, Churn rate, Number of users, DAU/WAU/MAU, Number of sessions, Session duration, Churn rate, NPS or CSAT etc.
• While Engineering may own Product Development and Product Quality KPI's. Examples are: On-time delivery, Cost incurred, Team velocity, Defect rate and Support ticket count etc.
• So although they are distinct, some common KPI's can be devised to ensure the customer delivery and quality goals are met. It really depends upon specific needs of the business and outcomes desired. Examples are: On-time delivery, Scalability and Reliability of systems, Support ticket count and User engagement/satisfaction metrics like Sessions, NPS/CSAT.
• The one example of a KPI product teams often miss is: Cohort Retention rate. It is not only important to track overall retention but also retention as it pertains to specific cohorts of customers you are interested in. Not doing this might give a skewed view of your business.
• In terms of KPI's shared between product and engineering, I would say "Effective Resource Utilization" can be missed primarily because it can be hard to track and measure across projects/teams.

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. 

Product, Engineering (and even design!) should ensure the majority of the user's experience is measured (engagement, conversion), the platform is functional (speed, etc), and that the company's key metrics are preserved. 

A big miss that comes up between product and engineering is when there is confusion around a product experience.

Product Perspective: "This is not working as expected. This is a bug"
Engineering: "This is what I was asked to build. It's working as specified"

This will happen from time to time based on how mocks, specifications, or flows are interpreted. The best KPI here is to ensure that all user stories are covered by the experience, the experience is fully tracked (to catch bugs or unintuitive experiences) and that all members of the team test the experience. Shared ownership of the customer experience saves people from the blame game and instead focuses on how to solve for how things should be without judgement.