Virgilia Kaur Pruthi (she/her)

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.

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.

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.

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.

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.

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

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

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.