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.
They don't change that much. While most of your KPIs will be around conversion, efficiency and time to completion, you should also be focusing on customer enjoyment/delight/satisfaction. I recommend looking into CSAT or NPS to ensure people enjoy the experience of using your product and would recommend it to their friends. If people are effective on the platform but don't enjoy it, you could see a competitor come and eat your lunch.
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.
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.
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.
The worst KPIs to commit to are the ones you can’t commit to at all. We can set targets and metrics and make dashboards, but that’s exactly what they are - targets. I recommend looking at past performance and trends within the data and setting a realistic yet aspirational target to work towards. After that, begin iterating on your target. Revisit the KPI, analyze, adjust, and communicate your findings.
KPIs around delight unless this is your key product differentiator (which is proven to be compelling to customers). Focus on building an intuitive and effective product experience that users would want to recommend to their friends/colleagues. Focusing on the final pieces of polish such as interactions, delight, animations, etc are fluff until you're really providing value to your customers. This is why keeping your KPI or success metrics concise and essential will allow you to provide the most impact to customers.
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).
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.
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.