AMA: Microsoft Principal Product Manager, Virgilia Kaur Pruthi on Product Management KPIs

This could really range based upon the company, your users, your target goals, where you are in your business lifecyle, etc. The most basic ones are: acquisition, activation, retention, revenue, referral You could also be measuring customer lifetime value. Again this will really depend upon what type of business you are in.

If you are lucky enough to have a PMM partner, then I would create a very transparent RACI chart which showcases who is: R - responsible A - accountable C - consulted I - informed about the various pieces of work. In my experience, depending upon the size of the team/company roles and responsibilies realy vary between product and PMM when it comes to product launches. Here is just one example of what could work: Product Management - Responsible for managing launch ready engineering and design work - Responsible for ensuring stakeholder buy in - Responsible for iterating on any user research or user feedback - Responsible for engaging product marketing early on and working backwards from their timelines - Responsible for the overall KPI Product Marketing - Responsible for creating launch material for end user purposes - Responsible for sales enablement - Responsible for training, communication plans and go to market strategy - Depending upon the specific product/feature area, could be responsible for activation, acquisition, # of eyeballs seen These two functions have to work hand in hand in order to succeed

Interestingly enough I see two trends in the types of KPIs product teams miss. 1) Aligning with the larger's organization or business goals - Ensuring that your product roadmap is actually impacting the success metrics (OKRs, KPIs) of the business itself is critical to knowing if you are investing in and prioritizing the right work. 2) Capturing "technical or engineering" metrics - Any work that your team spends time on should be impacting some metric. Even metrics that are technical (the most common one being latency) should be captured, reported on, and measured over time. 

Creating the right mechanisms to manage your stakeholders is critical to managing up and across. Allowing your stakeholders to stay on the pulse of your product while having access to updates really helps in building trust. Creating mechanisms like brownbag/learning sessions on a frequent basis (weekly or biweekly basis) also helps in creating an open forum. Then you can focus on protecting your engineering/design team and enabling yourself to scale.

I would recommend first building a relationship with your technical lead/engineering counterpart. Have them show you how your e-commerce platform (or product area) works end to end, from the backend perspective. Make sure that you first understand the end to end flow and specifically the systems design (which is critical in any e-comm platform). Once you understand how the customer's journey equates to the systems design, then start looking into each customer interaction with the site and make sure your team is tracking those metrics. You will end up at the checkout rates. If you have a good pulse on SQL or pulling and analyzing data, you could probably do the error rate comparison on your own. If you don't feel comfortable, work with your engineering lead (or data analyst) to dig into those numbers. Build out a report or dashboard that you can look at a regular basis. This will give you the background to ask or share opinions.

What a terrific question! This is one takes time and depending upon your organization will require patience. The best way I have learned, is to ask "why" a particular feature is being prioritized, and the "impact" it is bringing to the customer. The best way to create change is to start with your own product team (even if that consists of you as the PM, engineering, and UX/UI). For every epic/story, make sure to note down the KPI that it will impact, and why that is important to your target (end) customer. After a few cycles (e.g. sprints if you follow the agile approach), share the results of how your product work (launched features) impacted the KPI you were measuring, and why that is critical to your overall business. Evangelize this within your org, and see if there are one or two other teams who are interested in following suite. The more you share and report broadly, the easier it is to create change internally.

I'd love to learn more about what you mean by this. In reality they shouldn't change, your customers would just be internal that's all. You could still measure activation, activation, retention, engagement, resolution time, etc. On the other hand, you could measure self help vs. those who still asked for support or metrics lik elatency.

Wonderful, congrats! Get into a rhythm by understanding the business/company goals. Then understand how the tech works (look at the customer/user interface first and then make sure you understand how the system behind the UI works). Begin collecting data in a transparent way and share your learnings with your stakeholders and leadership. Conduct user research (both qualitative and quantitative) to help illustrate what product areas (epics/themes) you want to focus on and how these connect back to the business/company goals.

Such a great question! When you first set a KPI especially if you are in a new market and/or in a new product/customer space, it can feel uneasy. The best way I have learned is by setting something and tracking it over time, seeing if there is any measurable change. If not start by marking out the customer's journey (no matter who they are) and see if you can collect data on their interactions along the way. This may reveal some hidden trends you weren't yet measuring.

Don't think of it of what you should and should not own. Think about what makes sense to the customers you are focusing on. Then think about where you are in the customer/product lifecycle and product/market fit. What does the overall business care about at this time (e.g. retention vs. acquisition) and start seeing how your product area could contribute back to that overall goal.

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).

This could really range based upon the company, your users, your target goals, where you are in your business lifecyle, etc. The most basic ones are: acquisition, activation, retention, revenue, referral You could also be measuring customer lifetime value In regards to the worst KPIs, honestly those that cannot be discretely measured and tracked over a specific time period. Vanity metrics (e.g. the number of views from a marketing article or number of shares of a post) really add no value.

It really depends on what type of business it is. For instance, a product feature or product should be so frictionless that it allows users to onboard (adopt) easily once they are in the experience. Product marketing is responsible for bringing users to that experience. So it is almost eyeballs vs. activation. In reality these metrics should be shared, and over time broken up where the tech is meant to solve for the customer's need.

This is a hard one as I am sure there are a ton of layers to unpack here. Whenever there is a question around metrics, I would first look to the customer and understand what customer pain points your product area is solving for. Then see how those needs and your business goals align, and how your specific area can help solve for that. If it is a matter of stakeholder management that is a different story, but engineering, product and design should really have shared KPIs.