I often get asked how to set success metrics as a PM and why is this important. With the pressure to move fast, it is unsurprising to see product teams ship work without clear success metrics. They'd either skip the process or come up with a laundry list of metrics that make it hard to evaluate if the team's work has been successful.
Setting success metrics is the single most important thing you can do as a PM. In this article, I want to share a few tools you can use to set success metrics so you don’t fall prey to skipping this process despite moving at full speed. This works particularly well at the inception of a project, but equally well even after the work is shipped.
Before diving into the details, it’s important to answer the following questions to understand your scope of work and why it matters:
Am I building or improving on a product or a feature? Setting the success metrics requires a different approach depending on the scope of your product work. This article covers the framework you can use to set success metrics for feature work. We will cover the framework for setting success metrics of a product in future writings.
How does this fit into the overarching strategy of the product/company at this point? It’s important to understand why your work matters, even if it’s hard to measure how much impact your work will have on the business. For example, your team may be working towards an ambitious goal of 10M MAU in the next quarter, and that is why you are working on this.
Tip 1: Flip the problem statement to define your success metrics
Upon completion of the discovery process, have you clearly define the crux of the problem? If so, congratulations! You can simply flip the problem statement and use that as your success metrics. Suppose your problem statement is as follows:
50% of Safari users create a new tab of an already opened tab more than twice everyday. Most of them have > 20 tabs opened in a single window, and having to locate previously opened tabs by hovering on each tab one by one is time consuming.
To measure success, simply flip the problem statement above:
Users can quickly locate previously opened tabs, and the same webpage is not opened more than once.
With this, you can now work with your data analysts and engineers to register events and track the followings:
users no longer open the tab that’s already opened
users no longer spend time locating previously opened tabs one by one
Tip 2: Use Google’s HEART framework
For some projects, you may be solving a product problem or building a new feature to delight users. In that case, you can almost always use Google's HEART framework to map your success metrics to the followings:
Happiness (e.g. customer satisfaction score)
Engagement (e.g. MAU)
Adoption (e.g. conversion rate)
Retention (e.g churn rate)
Task Success (e.g. checkout rate)
This is more of a guiding principle for you to start thinking about how you can go about measuring success. You don't have to come up with metrics under each category, but pick and choose a few that matters most. Suppose you are working on a product improvement on a user journey that's leading to a significant decrease in sales, task success is probably something you should consider. Alternatively, if you are working on a feature to help knowledge workers collaborate frequently, adoption and happiness are most probably the metrics you'd pick instead.
If this is your first time learning about the HEART framework, please refer to Google Research - Measuring the User Experience on a Large Scale to learn more.